Bridging the Gap to Ensure Business Alignment Between Product and Dev

Flavia Neves, Cian Mac Mahon, Sudev Balakrishnan, Mihaela Draghici at UXDX Europe. Video: https://www.youtube.com/watch?v=GraisRiHGVA

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Opening and where each team is today

[00:00:00] Sudev: All right. Welcome, everyone, to our panel, Bridging the Gap. We are following John, following 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. I have two rules for this panel. The first rule: people are still skeptical between physical worlds and virtual worlds, so I'm going to ask all of you, Flavia, Mihaela, Cian, let's break the internet today. That's rule one. Rule number two: as a moderator, I'm going to ask you not to make my job as moderator as hard as the US presidential debates. That's my rule number two. I don't want to be beeping and stopping anyone.

[00:00:43] Welcome to everyone, and thank you. Collectively, our three amazing panelists have so much 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, is about a very fundamental question. It's a question about how we structure work. A hundred years ago there was a French pilot and writer, 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, teach them to yearn for the vast sea." That talks to how you want people to be inspired and aspire, rather than be prescriptive. Was Antoine right? Was he wrong? We don't know. Let's find out.

[00:01:34] I'm going to start by grounding us in where the panelists are. Can we just start off very quickly finding out where all of you and your teams are today in your journey? Are your current teams outcome oriented? If so, what drove the choice? Let's start with you, Cian.

[00:01:52] Cian: Sure. I'm a tech lead on one of our growth teams at HubSpot, and I focus mostly on onboarding for our new users. I think we're pretty outcome oriented on my team. We are given a goal or a metric to chase, and then it's up to us, in terms of engineers, product managers, designers, and we have researchers, how we chase that goal and try to make an impact on that metric.

[00:02:19] Sudev: Great. Sounds like you have crossed the (inaudible), so to speak, and gone to outcome-oriented. Flavia, how's your team?

[00:02:32] Flavia: Good afternoon, everybody. I'm Flavia. I am currently VP of Product at FREENOW. 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 chasm altogether to the other side, the right side.

[00:02:57] Sudev: Fascinating. So you have a real balancing act [?] going on right there. Mihaela, how is it in your own space?

[00:03:06] Mihaela: Hi. As everyone knows already, I am a Product Manager at Volkswagen Digital Solutions, a software development center here in Lisbon, Portugal. Throughout our software development centers, we work on outcome-based product development. However, it's quite challenging, because across the rest of the group, many of the departments and divisions still work on feature-oriented roadmaps. As Flavia said, our case is similar: we're trying to push towards more adoption of an outcome-oriented approach in our software development. It's a challenge.

Who determines the outcomes?

[00:03:52] Sudev: Got it. It's fascinating, because it sounds like the three of you have a good range, which will make for a very good discussion. If you are all aspiring towards outcomes, and outcomes are the keys to the car, 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 do teams do it themselves? Are they really outcomes, or are they just lipstick on a pig? Let's start with you, Mihaela. Do you want to talk to that?

[00:04:21] Mihaela: Yeah, sure. That's quite interesting, because I think it's never quite straightforward. There are always a lot of conversations happening with our stakeholders. Usually they come to us with a problem and also with a solution. What we usually do is push back and keep asking what the actual problem is, and try to focus the conversation on the problem itself. Then we move to a lot of extensive discovery, a lot of user research interviews and so on, and identify more problems to solve, and then decide how we can find the best solutions and apply them to those problems.

[00:05:05] 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. As product teams, we're taking ownership of these outcomes, how we measure them, and how we work towards them.

[00:05:25] Sudev: That's great. I'm just imagining that you have a little bit of arm wrestling going on.

[00:05:32] Mihaela: We stick to conversation.

[00:05:36] Sudev: Cian, what does it look like in your space? Where do the outcomes come from? Do you have this word called stakeholders? It's a popular word, stakeholders and clients. What do you do?

[00:05:44] Cian: Sure. I think right now we're pretty outcome focused. That hasn't always been the case; we made the transition as well. We have this goal, these 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 analysts. We knew that we would like more users to be more successful with our products, and we defined what "more successful" meant to us. Then we backtracked from that to say, "Okay, what stats, what metrics can we try to increase where we have good evidence they will improve our defined success?" That's where it came from.

[00:06:42] It's not like we have this one metric that's set in stone. We're currently having a pretty long debate as to whether, for my team specifically, we should change that metric, which I think is a really important part of being outcome 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 sprint towards it. Maybe there's a slightly better outcome you can work towards. That's how we set it: as an ongoing conversation between data analysts, product managers, designers, and then engineering managers 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.

[00:07:13] Sudev: Got it. Flavia, you had an interesting hybrid situation. Could you talk to both sides? Why does one pick one, and why does another pick the other? And when they pick it, why do they like picking the outcome-oriented one?

[00:07:27] Flavia: Two years ago, when I joined the company, everybody was feature driven. Everything would come from the executive team, or a mix of the executive team and operations, the markets, because we are in several different markets and everybody has different requirements. They're essentially a part of our users, or at least the voice of our users. Then we transitioned the tech hub in Barcelona to outcome-driven. What we had in this transition process was lipstick on a pig. We were transitioning to this new world, and we were using all of these new frameworks and dual track, doing discovery, et cetera, but still doing what we were doing before, with a new layer on top. Pretending that we do discovery, pretending that we do things the right way, but the objectives were still being dictated by somebody.

[00:08:25] Now I think we got to a point where we overcame most of these barriers, and now the teams are the ones pushing things forward. In the part where we were outcome driven, that said, I think it was essential to have a 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 couldn't come up with much, or what they were coming up with was not necessarily connected, or it wasn't aligned.

[00:09:01] 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. I think the difference is that the people that work in an outcome-driven setup are real 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. They come from consultancies, from financial services, more traditional industries or companies, and so I feel they're sometimes a little bit insecure: "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 it forward."

[00:09:56] But the difference is outstanding, because those that are working in an outcome-driven setup actually see things moving forward. With the project managers (they're not project managers, but with this mindset) 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. That's the difference between both.

[00:10:31] Sudev: Fascinating. I picked up a few threads in there. It sounds like there's a journey that we should typically expect on this. It doesn't happen overnight; there's probably a cultural difference to this, and there's probably inherent learning that needs to happen in the organization. Fascinating.

When stakeholders push back on the pushback

[00:10:49] Sudev: We've been talking about this as a black and white world, while Flavia's is probably grey. Cian, you talked about changing outcomes being a good thing. Does it ever happen that as you try this new outcome-oriented method, the stakeholders, or whoever happens to define these things, suddenly come back and say, "Guys, I'm tired of dreaming up the aspirational way to package all of this for you. Why don't you just build this thing? That's it. The tactic is clear. What more do you want?" What do you think causes them to do this, and what do you tend to do as a consequence to keep that journey alive? Let's start with Flavia. Go ahead.

[00:11:44] Flavia: Sorry, do you mind repeating the question? Because I got cut off a little bit.

[00:11:49] Sudev: Say, for whatever reason, maybe 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 going to go back to 'why don't you just build this thing?' Why do you keep asking me all these crazy questions about the larger why?" I have a research background, so there's the "why", and the "why behind it", the why behind the pushback. Do they ever push back on the pushback and say, "Too much, guys"? I think we heard earlier today about democratization for teams having gone too far. So I would love to understand: does this happen? If so, what typically tends to make it happen? And what do you do as a consequence to continue the journey?

[00:12:33] Flavia: That happens almost daily. I'm known for asking those whys, 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 the data? Why are you so obsessed with data?" 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 criteria, without proper data or research, or something that gives us more or less the direction, will not yield the results that people want.

[00:13:20] It's very easy to look back and pick certain things, because we're doing this transition, and 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 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 the reasoning for building this versus something else. This was the result. Is this what you want going forward?" When they're backed into a corner with real-life examples, they tend to say, "Okay. You're still annoying me incredibly, but there's no arguing against facts." There's not much they can say.

[00:14:12] Sudev: 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 do you get buy-in from the organization or the stakeholders for something major like that? Why would they not question it 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?

[00:14:36] Cian: Sure. It's a really good question. I think it always comes back to having evidence that the direction you're changing to is better than the one you were previously on. 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. Say we're going to change that metric from the number of users active in a single account to the number of different parts of the app used in a specific account. We might be able to justify that change.

[00:15:17] We can say, "Hey, if we take a look at the percentage of users with outcome A who ended up monetizing, versus the percentage of users with outcome B who ended up monetizing, and we take our current user cohorts, we can see that a user who does thing B is more likely to monetize later than someone who does thing A." 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."

[00:15:47] We also do a lot of experimentation, which is what my on-demand talk is about, and we'll pretty frequently have a ghost outcome. We'll have "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 the reason we're now having these discussions about changing our outcome metric is that we started to notice that there was a higher correlation between that one and the metric we were being judged on across the org. 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 product development, data will win the argument every time.

[00:16:28] Sudev: Got it. Mihaela, Cian and Flavia have talked about this. What do you have to add?

[00:16:37] Mihaela: In our case, it does happen quite frequently. For example, we get feature requests from our stakeholders instead of outcomes, and these feature requests come in over a period of time, and they change, and more and more of them come. 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?" It's what Flavia was saying: it's not a matter of building features on top of each other. It's about solving problems, and sometimes you can solve a problem with the existing features that you have, by looking at the functionality and what they serve.

[00:17:22] And it's what Cian was saying as well: look at the data, measure everything, understand what you currently have and what you can add to your existing products to solve the problems you're trying to solve. For me, shifting 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 change their mindset as well. Also by bringing success examples and success stories: "Okay, we pushed back on your request and we did something else instead, and look what we've achieved." Bringing those success examples helps support the approach and get their buy-in.

The first step: how the change started

[00:18:06] Sudev: Got it. I hear a lot from you in terms of journeys, and every journey of a thousand miles starts with a single step. 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? What was the key conversation? How did that initial spark start? Or was it always learning after the existing method had failed for the organization? What do you think was the key topic 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?

[00:18:47] Cian: That's a really interesting question. I joined the growth org at HubSpot a little bit after it was formed. I was working on other things which we would probably have considered growth, but at the time I didn't, so I wasn't really involved in setting it up. I know that on my team, we started transitioning pretty heavily to 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 would use it, but we had no evidence that it was actually helping us or helping our users.

[00:19:24] So we started doing a lot of user research. We started doing a lot of data analysis, and we started to realize that our job isn't to build features. Our job is to build value. Once we made that realization, that our job is to build value for our users, we then started thinking, "Okay, what does that mean? How do we figure out what value is? How do we define value in a way we can measure?" And that's how I think we started moving over to more outcome-based development [?], once we figured out how to define value in a way that made some sense. 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.

[00:20:09] Sudev: Got it. Learning from mistakes. Flavia, did you have some special moment that brought this about?

[00:20:20] Flavia: I remember the exact moment where I 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 squads and some guys from operations. These guys were telling them about an 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. 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, and then the engineers figuring out the right sequence of events.

[00:21:22] And I was like, wow. 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'll have the MVP ready in 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 this squad. I have to work with them a little bit." Then I started having conversations in the business that week, and I realized that this was the pattern. That triggered me to think, okay, this is awfully wrong.

[00:22:00] Then, with the executive team, I was in one of the first approval sessions, because we had approval sessions. The teams would come up with essentially what we were going to build, even though they had been told what to build, and we would do this ceremony of getting the senior management team to approve what we were going to build. I got to that meeting and I had to present something that somebody had handed over to me, because I had just joined. 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."

[00:22:48] That was the moment that triggered the whole conversation. 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 the product to be used by our users? Then it was a long journey 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're actually in the same place we were last year: building, building, building, and that's it."

[00:23:27] Sudev: Great. It sounds like you almost had a life event in your company, compared to Cian's, which was a retro-like approach. I'm going to try to make this panel real-time, but the question board is going fast. Mihaela, rather than answer the question I asked, there's a question coming in: do you think stakeholders know how to answer the question "what are they trying to achieve?" Do you find you have to offer suggestions?

[00:23:57] Mihaela: 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 we get to the depth of the situation and of the problem. We do that through workshops, for example, and in these workshops we collaborate a lot to get to the bottom of it and understand what we are trying to achieve. Then we continue with a short discovery stage and so on. 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 even before they started.

[00:24:44] It's a matter of, again, pushing the right questions as much as possible and working together with the stakeholder. Not telling them what they could do or what they could try to achieve, but rather having the conversation, and from that conversation reaching a common agreement. This way we are aligned on both sides and we're in it together, so everyone takes ownership of that problem, and then of the outcomes.

How the teams react

[00:25:14] Sudev: You all have so much to add. Just fascinating. I'm going to try to speed up to the second part. We talked a lot about how the company operates with the teams. Let's go inside the teams. 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 let's go to the people in your teams, and take an internal focus. As you are trying to create this transformation, how do your teams react? Have you had any pushback? What's happened? Flavia, do you want to take this one?

[00:25:48] Flavia: Yeah. Product people are generally very excited, because they're specialized to solve problems. They were trained to do this, so being given the ability to work in a different way, doing their real job, was very exciting for them. Engineers were a mix. The ones that are more product oriented were absolutely excited about this. I'm not going to lie: the process was hard, and it required mindset changes, and all changes are somehow difficult. So it was difficult, but they were excited. Another 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 generally speaking, it was very well accepted.

[00:26:48] Sudev: Mihaela, do you want to add to that? How are the people responding?

[00:26:54] Mihaela: In our case, it's slightly different, because our software development centers have been built to work with an outcome-based focus from the beginning. When we're forming the product teams, we already have this in place: we inform everyone throughout the recruitment process what to expect, and we're looking for the people that would adapt to this environment. 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 to the current setup.

[00:27:39] At that stage there are people that find it a bit more difficult, or they don't understand certain things, like why we are iterating on the same feature 15 times and not just putting it out there, and they get a bit demotivated in some cases. You always need to bring back 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 reach the goal.

[00:28:12] 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. We have the product people there, we have the designers, we have the engineers, so everyone is working together. I think having that sense of cohesion and community within the team helps a lot as well. We're not separated, with engineers on their side and product managers and designers on another side. We actually work together, and that also helps to keep up the momentum and the motivation.

[00:28:46] Sudev: So I'm hearing that if the sandbox is defined for you, it's easier to play. I know we are up against the clock. Cian, how did it look for you? And then I want to do a quick poll after that. Go ahead, Cian.

[00:28:54] Cian: Most likely here, we are very small teams: two or three engineers, a product manager and a designer. We are given the specific goals we're moving towards. I think what's important, though, is that building towards an outcome rather than targeting a feature is a specific way of working. Sometimes you need feature-driven development, if you're working on the infrastructure team or something. When a new engineer joins my team, or a team close to mine, I spend time making sure that this is the thing they enjoy, and that they are a product person as well as being an engineer.

[00:29:34] Frequently someone comes in and says, "I'm not going to like this. I want to be told what to do and I'll do it incredibly well. I don't want to spend time thinking about outcomes." And I can pretty frequently sit down with them and just draw a line between running 15 experiments, throwing out 14 of them, and that last one directly having a positive impact on somebody's business. Pretty frequently that'll help people understand why outcome-driven development is so useful. If they still walk through the 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.

Closing poll

[00:30:20] Sudev: I want to make sure we break the internet, but we don't break the UXDX clock. We have a few seconds, which allows me to do one thing. Can I have a quick thumbs up or thumbs down? Thumbs up if you like outcome oriented, thumbs down if you like feature oriented. Thumbs up is outcome, thumbs down is feature. All of you, all three thumbs up. Three for three, all outcome oriented. Fantastic.

[00:30:42] I think that's our panel. I wanted to thank you all for sharing so much. I took away several takeaways about the journey companies have to follow, and the amount of attention that needs to go to the structure. The work that you have to do to get to an outcome-oriented infrastructure is very clear from your experiences, and the fact that you all love the structure has also come through at the end, saying that this is where you personally want to go. I have my personal biases on lots of things, but I wanted to try to get your read on this, and it's been very useful.