Bridging the Gap to Ensure Business Alignment Between Product and Dev

Sudev Balakrishnan: All right. Welcome everyone to our panel, Bridging the Gap. We are following John, I followed Gremlins in the Machine taking shoes off, and there were quite a few things in there. So, it's going to be a tough act to follow, but let's do it. I think we can do it. So, I have two rules for this panel. The first rule is people are still skeptical between physical worlds and virtual worlds. So, I'm going to ask all of you. Flavio, Mihaela, Cian, let's break the internet today. Rule one, this panel. Rule number two is as a moderator. I'm going to ask you to not make my hard ass job as the moderator as the US presidential debates. That's my rule number two. So, I don't want to beeping, stopping anyone. So, welcome to everyone and thank you. Collectively, our three amazing panelists have so much of experience to share with us, and I thank them for coming here to share those experiences so we can all learn. This panel Bridging the Gap, it's a very fundamental question. It's a question about how do we structure work and 100 years ago there was a French pilot and writer and Antoine who said, "If you want to build a ship, don't tell people to cut wood and divvy up the work and give them marching orders. Instead ask them to yearn for the vast seat." And that talks to how you want people to be inspired and aspire rather than be prescriptive and what's Antoine. Right? What was he wrong? We don't know. Let's find out. So, I'm going to get into first grounding us into where the panelists are so can we just start off very quickly finding out where are all of you and your teams today in your journey? Are your current team, outcome oriented? If so, what drove the choice? Let's start with you, Cian.
Cian Mac Mahon: Sure. Yeah. I'm an Admin Tech Lead on one of our growth teams at HubSpot. And I focused mostly on onboarding for our new users. I think we're pretty outcome oriented on my team. We are a given a goal or a metric to chase. And then it's up to us in terms of engineers, product managers, designers, we have researchers. It's up to us how we chase that goal and try and make an impact on that metric.
Sudev Balakrishnan: Great. Sounds like you have crossed the (inaudible) so to speak and gone to outcome-oriented. Flavia, how's your team?
Flavia Neves: Good afternoon, everybody. I'm Flavia. I am currently VP of Product at FREENOW. And we have a weird setup in that half of our teams are outcome driven after a very, very lengthy process. And then there's a portion of the organization that is still very much feature driven. So, we have a balance of both and we're trying to cross the chasms altogether to the other side, the right side.
Sudev Balakrishnan: Fascinating. So, you have a right analyst bring going on right there. Mihaela, how is it in your own space?
Mihaela Draghici: Hi. As everyone knows already, I am a Product Manager at Volkswagen Digital Solutions as a software development center here in Lisbon, Portugal. Throughout our software development centers, we actually work on outcome-based product development. However, it’s quite challenging because across the rest of the, the group many of the departments and divisions still work on feature-oriented roadmaps. And Flavia said, in our cases is similar, we're trying to push towards more adoption of an outcome-oriented approach in our software development. It's a challenge.
Sudev Balakrishnan: Got it. It's fascinating because the three of you, it sounds like you have a good mix of range which would make very good discussion happen. So, if you all are aspiring towards outcome and outcomes are like the keys to the car, it's no longer the software development document. Then the key question I had in my mind is, who determines the outcomes? How do these outcomes get assigned to your teams or other teams do it themselves? Are they really outcomes? Are they just wrapped up like lipstick on a peg? Let's start with you Mihaela, you want to talk to that?
Mihaela Draghici: Yeah, sure. That's actually quite interesting because I think it's never quite straightforward. There's always a lot of conversations happening with our stakeholders. Usually they come to us with a problem and also with a solution. So, what we usually do is push back and keep asking what the actual problem is and try and focus the conversation on the problem itself. And then we move a lot of extensive discovery, a lot of user research interviews, and so on and then identify more problems to solve and then decide how we can find the best solutions and apply the best solutions to those problems. So, we usually like to push the conversation towards you come to us with the problem, we own the solution and we decide how we're going to build things. So, we're actually taking as product teams, we're taking ownership of of these outcomes and how we measure them and how we work towards them.
Sudev Balakrishnan: That's great. I'm just imagining that you have a little bit of arm wrestling going on.
Mihaela Draghici: We stick to conversation.
Sudev Balakrishnan: Cian, how does it look like in your space? Like when you have this, where do the outcomes come from? Do you have this word called stakeholders? It's a popular word, stakeholders and clients. What do you guys do?
Cian Mac Mahon: Sure. I think right now we're pretty outcome focused that hasn't always been the case. We made the transition as well. So, we have this like this goal, this outcome metrics that we target, and that was chosen about a year and a half ago working with a few of the product managers, as well as some data analysis, data analysts to figure out so we know that we would like more users to be more successful with our products and we certainly defined what more successful meant to us. And then we backtracked from that to say, "Okay, what then, what stats, what metrics can we try and increase where we have good evidence or which we have good evidence will improve our, I guess, defined success. So, that's where it came from there. Now, metrics it's not like we have this one metric that set-in stone. We're actually currently having a pretty long debate as to maybe for my team specifically, we should change that metric, which I think is a really important part of being not com driven. You don't want to set an outcome and then just say, "That's it. That's what we're working towards." And then just sprinting towards it. Maybe there's a slightly better outcome. You can work towards that. That's how we set it as an ongoing conversation between data analysis, product managers, designers, and then engineering majors as well. We do, of course, also have to take into account where the business plans on going over the next roughly three years or so too.
Sudev Balakrishnan: Got it. Flavia. you had an interesting, you had both a hybrid situation. Could you talk to like both sides? Like why does one pick one? Why this one pick another and when they pick it, why do they like picking the outcome oriented one?
Flavia Neves: Last year or two years ago, when I joined the company, everybody was a feature driven. So, everything would come from the executive team or a mix of executive team and operations, the markets, because we are in several different markets. Everybody has different requirements. So, they're essentially a part of our users or at least the voice of our users. And then we transitioned the tech hub in Barcelona to outcome-driven. So, what we had in this transition process was a lipstick on a peg, right? So, we are transitioning to this new world and we're using all of these new frameworks and dual track. We're doing discovery, et cetera. Let's still keep doing what we were doing but put a new layer on top. So, pretend that we do discovery, pretend that we do things the right way but we're still being dictated or the outcomes, sorry, the objectives are still being dictated by somebody. Now, I think we got to a point where we overcame most of these barriers. And now the teams are actually the ones pushing things forward. The part where we were outcome driven that said, I think it was essential to have company strategy, company goals, something setting the direction because what happened throughout the process was, "Okay, we're going to let go." You guys come up with whatever you want, but because there was no direction, they actually couldn't come up with much or what they were coming up with was not necessarily connected or it wasn't aligned. The other part of the business is still very much looking for direction in terms of what do you want us to build next? Which is a little bit weird. And I think the difference is that people that work on an outcome driven setup, they're really our product managers. Their background is in product management. They know how to build products. They know what the process should look like they're very focused on users, very data-driven, et cetera. The other side of the business seems to be more project management oriented. So, they're more used to, they come from consultancies from financial services, more traditional industries or companies and so they're a little bit insecure. I feel sometimes regarding, "Okay. I'm supposed to run this but I don't know how to do this. You tell me what to build and I'm going to push forward." But then the difference is outstanding because those that are working in an outcome driven setup, they actually see things moving forward whereas the project managers. They're not project managers, but this mindset kind of, I guess the outcome is the same for every single company. You deliver things without an actual purpose without being driven by impact. And therefore, you have a million different features, a million different things implemented that simply don't move the needle. So, that's the difference between both.
Sudev Balakrishnan: Fascinating. I picked up a few threads in it sounded like there's a journey that we should typically expect on this. It doesn't happen overnight is probably a cultural difference to this and there's probably inherit learning that needs to happen to organization. Fascinating. And we've been talking about this as a black and white world while Flavia is probably great and when you think about this and say can you talk about changing outcomes being a good thing? Does it ever happen that as you try this new method, this outcome-oriented method, that there is a sense from stakeholders or who happens to define these things and do suddenly come back and say, "Guys, I'm tired of dreaming up the aspirational way to package all of this for you guys. Why don't you just build this thing?" That's it. The tactic is clear. What more do you want and what do you think causes them to do this? What do you tend to do as a consequence to keep that journey alive? And let's start with Flavia, you go ahead.
Flavia Neves: Sorry. Do you mind repeating the questions? Because I got cut off a little bit.
Sudev Balakrishnan: If the journey, for whatever reason. And I'm giving us high particularly maybe that a particular outcome metric did not hit a target. Someone comes to you and says, "I can't package this as aspirational outcomes. I want to determine the tactics. I'm just going to go back to why didn't just build this thing. Why do you keep asking me all these crazy questions about what is the larger why. I keep having a research background. So, there's that you ask a why and a why behind it, the why behind the pushback." Do they ever push back on the pushback and say too much guys? And I think we heard earlier today about democratization for teams has gone too far. So, I would love to understand what do you do? Does this happen? If so, what typically tends to make this happen? And what do you do as a consequence to continue the journey?
Flavia Neves: That happens almost daily. I'm known for asking those why's and I've heard several times, why are you so complicated? We just know that this is going to work. We're telling you to build this. Why do you want to experiment? Why do you want to look at them? Why are you so obsessed with data? So, that's something that happens almost daily in every single meeting but at the end of the day, I think it's about going back to the basics and explaining exactly what we're trying to achieve and why building certain things without having a criteria without having proper either data or research, or it's something that gives us more or less the direction will not yield the results that people want. And it's very easy to go to look back and pick certain things because we have this. We're doing this transition and therefore, I was the first person to start this change. So, I saw many things that were built that made absolutely no sense. It's very easy to go pick those examples and say, "This happened in the past. Here's what you asked me to build you didn't want to know why, you didn't want to know what was the reasoning for building this versus something else. This was the result. Is this what you want going forward?" It's not, they're backed up when they're backed in a corner with real life examples, they tend to, "Okay. You were still annoying me incredibly, but there's against facts." There's not much thing that they can say.
Sudev Balakrishnan: Got it. I am hearing some sense of retraining the trainers with real data in the world. Cian, you mentioned this too. You will change the outcome. How does the organization or the stakeholders, or who does this get buy in to something major like that? Why would they not question the tactics and say, "Why are you changing the outcome? Why don't you change your tactical moves? Could you talk a bit about how you manage this?
Cian Mac Mahon: Sure. Yeah, it's a really good question. I think it always comes back to having evidence that the direction that you're chaining or the direction you're changing to is better than the one you were previously on. So, when we're changing the metric that my team has focused on, which I'm not going to get super deep into, but effectively our metric is the number of users active in a single HubSpot account. Right? So, if we're going to change that metric to maybe instead of number of users active in a single account to the number of different parts of the app to use in a specific account. We might be able to tie that change. We can say, "Hey, if we take a look at like the percentage of users from outcome; A, who ended up monetizing versus the percentage of views from outcome; B, who and monetizing and we take our current user cohorts, we can see that a user who does think B or a part of it's just paying B is more likely to monetize later than someone who does outcome and if we can make that relatively direct connection, it's fairly hard for somebody to push back and say, "We think you're doing the wrong thing." We also like we do a lot of prompts experimentation, which is what my on-demand talk is about. And we'll pretty frequently have like a ghost outcome, right? We'll have like, this is our primary metric that we're going to judge success on but we're also keeping an eye on this one too. And pretty frequently that the reason we're now having these discussions about changing our outcome metric as we started to notice that there was a higher correlation in can be, we'll call it then our primary metric that we were being judged on across the org. So, that's where that conversation happened. Everything does need to be rooted in data, but I think if you're in an organization, which is doing really good outcome driven development and product development, and I think that data will win the argument every time.
Sudev Balakrishnan: Got it. Mihaela, are you good? Cian and Flavia had talked about this, what do you have to add to this?
Mihaela Draghici: I guess in our case; it does happen quite frequently. For example, that we get feature requests from our stakeholders, this guy does outcomes and these feature requests come on a plan over a period of time and they change and they come more and more. And it's a matter of again, pushing back and shifting the conversation to, "Wait, what are you trying to achieve? What problem are you trying to solve? What are your goals? Do you think you can achieve your goals with this feature and it's what Flavia was saying, it's not a matter of building features on top of the other? It's about solving problems and sometimes you can solve a problem with the existing features that you have but looking at the functionality and what they serve. And again, it's what Cian was saying as well is look at the data, measure everything, understand what you currently have and what you can add to do to your existing products to solve the problems you're trying to solve but for me shifting this from features to outcomes is also shifting the conversation and the language and by pushing this as much as possible towards the stakeholders, you slowly changed their mindset as well. And also, by bringing success examples and success stories of, "Okay, we've pushed back on your request and we've done something else since that look what we've achieved." And by bringing those success examples, it helps support the approach and get their buy-in.
Sudev Balakrishnan: Got it. I hear a lot of you on in terms of journeys, but every journey of a thousand miles starts with a single step. And all of you seem to have gone on the journey. Can we now ask you to go back in time a little bit to the first step as you were changing this narrative? And think through what was the key conversation? How did that start that initial spark or was it always learning after the existing method may have failed for the organization? What do you think was the key topic that you were trying to drive to change this narrative? Let's start with you, Cian. When did this start and how did it start? Was there a moment someone just woke up and said, We are going to go outcome-based." How did that happen?
Cian Mac Mahon: That's a really interesting question. So, I joined the Growth Oregon HubSpot and a little bit after it was formed, I was working in other things which we would have probably consider growth, but at the time I didn't, so I wasn't usually involved in setting up. I know that on my team, we started transitioning pretty heavily outcome-based when we realized that we were building feature after feature, after feature, and we were only making very incremental improvements, if any. We might build this new thing and a few users abuse it, but we've had had no evidence that it was actually helping us or helping our users. So, we started doing a lot of user research. We started doing a lot of data analysis and we started to realize that like building like our job isn't to build features, right? Our job is to build value and once we made that realization that our job is to build value for our users, we then started thinking about, "Okay, what's that mean?" How do we figure out what value is? How do we define value in like a way we can measure? And that's how we, I think Slack started moving over to more outcome-based development. Once we figured out how to define value in a way that made some sense. So, I think that was the transition for us. We went from building feature after feature and not really being sure if it was working to building value which sounds a bit airy fairy, but I think that would be how we did it.
Sudev Balakrishnan: Got it. Learning from mistakes. Flavia, did you have some special moment that brought this about?
Flavia Neves: I remember the exact moment where it thought, what did I get into? I think it was my first day or second day at FREENOW. I joined a meeting between one of my squats and operations, some guys from operations. And these guys were telling them about something in MVP that they wanted to build and they described the exact solution that they wanted, mind you, these were operations people. I was shocked at that point, but I didn't expect my team to entertain the conversation. So, instead of realigning everybody and focusing on the right questions, what is it that you're trying to achieve? What's the problem? Bring me the problem and we'll try to figure out the solution. I saw everybody rushing, getting post-its writing the tasks on the post-its putting them on the wall. Then the engineers figuring out what was the right sequence of events. And I was like, wow. So, I left the meeting and I thought, "Okay, this is really, really wrong." Oh, no, sorry. Before I left the meeting, the shocking part was when they said, "Okay, so we know exactly what we need to build. This is the plan. We have the MVP ready in right about six months." I was like, "What do you mean MVP in about six months?" That's not an MVP at all. So, I left the meeting and I thought, okay, something is awfully wrong, but it's probably just the squats. So, I have to work with them a little bit and then I started having conversations in the business for that week. And I realized that this was the pattern. And that triggered me to think, okay, this is awfully wrong. With the executive team and the executive team, I was in one of the first approval sessions because we had approval sessions. So, the teams would come up with essentially what we were going to build, even though they had been told what to build. So, we would do this ceremony of getting the senior management team approving what we were going to build. And I got to that meeting and I had to present something that somebody had handed over to me because I had just joined and I was presenting that and midway through the conversation, I said, "I'm sorry. Let's stop this. Why are we building this in the first place?" And they asked me, "Well, you're presenting it. Why are we building it?" And I said, "I have no idea." So, that was the moment that triggered the whole conversation and then I started questioning them about the impact and the value what Cian was saying, we are here to drive impact, to generate value. What does that mean for us? Is it building 10 more features because our competitors have those features or is it really focusing on who we are? What products we want to build? How we want to be perceived and how we want to be the product to be used by our users. And then it was a long journey of with them but that was the moment where they realized, "Oh, fair enough." We have been working in this setup for a really long time, and we actually are in the same place that we were last year building, building, building and that's it.
Sudev Balakrishnan: Great. Both of you could see, it sounds like almost you had a life event in your company compared to Keansburg was a retro like approach. I'm going to try to make this panel real-time but taking the question board is going fast. I'm going to make sure. Mihaela, just rather than answer the question I asked and when there's a question coming in, which is, you think stakeholders know how to answer the question? What are they trying to achieve? Do you find you have to offer suggestions?
Mihaela Draghici: It does happen in cases that they don't the approach that we have is more around let's figure it out together and we keep asking questions until when they stand, when we get to the depth of the situation and of the problem. We do that through workshops, for example and in these workshops, we actually collaborate a lot to get to the bottom of it and understand, okay, what are we trying to achieve? And then we continue with a short discovery stage and so on. And there were cases when after a discovery, we realized, "Okay, this is not a valid problem. We're not building anything." So, we stopped things in even before they started. So, it's a matter of again, pushing as much as possible, the right questions and working together. The stakeholder, in terms of what they could do, what they could try to achieve, but rather having the conversation and from that conversation, reaching a common agreement because this way we are aligned on both sides and we're in it together. So, everyone takes ownership over that problem and then over the outcomes.
Sudev Balakrishnan: You all have so much to add. Just fascinating. I'm going to try to speed up to the second part, which is we talked a lot about how the company operates with the teams. Let's go inside the teams. And I think about the three P ladder. The top is the product you want to build. That's based on the process that you use and at the bottom of it, the most important thing is the people. So, that's how I think about let's go to the people in your teams that do it, and let's say they get internal focus. Now, as you guys are trying to create this transformation, your teams, how do your teams react? Have you had any pushback? What's happened? Flavia, when you want to take this one?
Flavia Neves: Yeah. So, product people are generally very excited because, I mean, they're specialized to solve problems. They were trained to do this and so being given the ability to work in a different way and driving what doing their real job, it was very exciting for them. Engineers, it's a mix, the ones that are more product oriented. Yes. They were absolutely excited about this. I'm not going to lie. The process was hard and it required the mindset changes and everything that is old changes are somehow difficult. So, it was difficult but they were excited. They're part of the engineering team was like, "I don't want any of this. Just let me work on tech stuff. I don't care what users want." So, we had a mix from a product perspective. It was a very good change. And in generally speaking, it was very well accepted.
Sudev Balakrishnan: Mihaela, do you want to add to that? How would the people be responding?
Mihaela Draghici: In our case, it's slightly different because our software development centers have been built to work on an outcome-based focus from the beginning. So, when we're forming the product teams, we have this already in place where we inform everyone throughout the recruitment process, what to expect, and we're looking for the people that would adapt in this environment so it's built like this from the beginning. It's not a transition within our software development centers. However, in many cases it's a transition for the individuals from their previous companies, for example, to the current setup. And at that stage there are persons that find it a bit more difficult or they don't understand certain things like why are we to rating on the same feature 15 times, and we're just not putting it out there and they get a bit demotivated in some cases. So, you need to always bring back and a reminder, why are we here? What value are we trying to bring to the user or to the business. And yes, we will keep on iterating until we reached the goal and I think in our case, the advantage is how the engineers work together and how the teams are formed because the product teams are multidisciplinary. So, we have the product people there. We have the designers we have the engineer, so everyone is working together and I think that having that sense of cohesion and community within the team helps a lot as well. So, we're not separated engineers on their side and the product managers and designers on another side, but we actually work together and that also helps to keep on the momentum and the motivation.
Sudev Balakrishnan: So, I'm hearing that if the sandbox is defined for you easier to play. I know we are up against the clock. Cian, how did it look for you? And then I would want to do a quick poll after that. Go ahead, Cian.
Cian Mac Mahon: So, most likely here that we are very small team’s tech two or three engineers, a product manager and designer. We are given the specific goals are moving towards and I think what's important though is that I come to like building outcome rather than targeting and feature. It is like a specific way of working. Sometimes we need feature driven development if you're working on the infrastructure team or something. When a new engineer joins my team, joins a team close to mine. I spent by making sure that this is the thing they enjoy it. And so, they are a products person as well as being an engineer. Frequently, if someone comes in say, "I'm not going to like this, I want to be told what to do and I'll do it at the incredible, I don't want to spend time thinking about outcome." And I can pretty frequently sit down with them and just draw a line between running 15 experiments, throwing it 14 of them. And that last one directly having positive impact on somebody who's not. Pretty frequently that'll help people understand why outcome driven development is so useful, if they still walk through the inquiry process and say, this isn't for me, we have many teams that need really, really high standard engineers and product managers and designers to place them on.
Sudev Balakrishnan: I want to make sure we break the internet, but we don't break the UXDX clock. We have few, which allows me to do one thing. Can I have a quick thumbs up or thumbs down, thumbs up for if you like outcome oriented. Thumbs down, if you'd like feature oriented. I feel you guys want to go. Thumbs up as outcome, thumbs down as feature. All of you. all three thumbs up. Three on three? All outcome oriented. Fantastic. I think 9:15 is our panel. I wanted to thank you all for sharing so much. I took away several takeaways about the journey companies have to follow, the amount of attention it needs to get to the structure. The work that you guys have to do to get to an outcome or infrastructure is very clear and experiences and the fact that you all love the structure also has come through at the end saying that this is where you guys personally want to go. I have my personal biases of lots of things, but I wanted to try and get your read on this. And it's been very useful.