Culture Clash: How to Make Product and Engineering Work Together Effectively

David Subar at UXDX Community: USA Online Series. Video: https://youtu.be/NpEJ-OE7-II

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.

Introduction: who I am and what we see across companies

[00:00:00] Hello to everybody. As I've already said, I'm talking about culture clash, making product management and engineering work effectively together. I have about an eight-hour presentation and I have about 30 minutes to present it, so I'm not going to get through everything today. I'm going to get through all of the highlights, and as Rory suggested, if you have questions afterwards feel free to reach out to me. Here's my email address. I'll be on the Slack community as well, and I'll have my contact information again at the end.

[00:00:36] I'll give you a little bit of context about who I am and how I got here and what I'm talking about. I was an ex-CTO, an ex-chief product officer. I ran both those departments at a number of companies over a number of years, and about nine years ago I started this company, Interna, and we consult on product management and engineering. Our fundamental thesis, and the fundamental thing about this talk, is that product management and engineering are not two teams. They're one team. They're one team that works together to build a product. And if you can achieve that, those teams can be effective.

[00:01:17] We've worked with a number of companies. We do four things. We will go into technology companies, evaluate product management and engineering teams, and come out with a diagnosis and prescription: here's some things you're doing well, here's some things you might want to do differently, here's how, on that same concept about product management and engineering being effective. For companies that have a CTO or chief product officer, they often ask us to coach the technology and product management executives, whether they're titled CTO or chief product officer or not, and help them with their teams. If the companies don't have someone, they often ask us to come in and function as interim CTOs and chief product officers, help fix product and engineering teams and then help hire someone on. And we also do due diligence for VC and PE firms and M&A transactions.

[00:02:10] We've done it for a bunch of companies. The reason I'm pointing this out is we see patterns, patterns with things we see at the Walt Disney Company. We've also seen startups, mid-market companies. We worked at Lynda.com before they got sold to LinkedIn for, I think it was, 1.4 billion dollars. B2B companies, B2C companies. There's commonalities about product management and engineering that we're able to apply to a bunch of companies, and I'm going to share a bunch of those with you today.

[00:02:47] So if I have time, I'm going to talk about four culture clashes, and I'm going to give you five tools to overcome them. We may only get to three of the culture clashes. I'm going to try to get to at least three in the time that we have, but I'm going to give you five tools. I'm going to talk about alignment, measurement, review, transparency and iteration as those tools to overcome the culture clashes.

The first culture clash: optimizing your own team's efficiency

[00:03:15] Now, the first one is alignment. I mentioned before that our view is product management and engineering are one function, one team. That means I need to get aligned, and there's really three stages of alignment I want to talk about.

[00:03:37] People who run product management and engineering, I'm using CTO and chief product officer, but I really mean here the product management and technology executives, and really also all the people in the team. People often think their job in those roles is to optimize their team's efficiency. How do I make my team be better at engineering? How do I make my team practically better in product management? I have some input, something that we do, and some outputs. So if I'm in technology, I have some user stories that I get as input, my developers code some stuff, we output, read the acceptance criteria, we're done, we're good. We should do that faster, better, less bugs.

[00:04:27] If I'm in product, then I have some user needs. Maybe it comes from the roadmap, maybe I built a roadmap. I output user stories. I work with UX to put those interfaces together. Those are my outputs. And then engineering does something, I check it out, we're good. That's what I do. I'm going to optimize my team to make that as efficient as possible.

[00:04:59] The surest way to create a culture clash between product management and engineering is to worry about my team's efficiency, to think about what am I doing, because that creates a barrier, a wall between product management and engineering. And remember, the primary goal here is that we're producing products for some industry, for some customers. We create value when we create value for those customers.

[00:05:35] Thinking about product management and engineering only thinking about what we're doing creates that wall, and it creates finger pointing. I'm engineering, look, I just did what product management told me. If it's not the right thing, if the UX is wrong, it's on them, it's their fault. I wrote the code. I'm in product management, I'm in UX: if they're slow to produce it that's their fault. We told them what to do, we told them when it was going to get done, they told us it would get done. If we didn't get released in time it's their fault. It creates finger pointing, creates that barrier that I talked about. That's the first culture clash.

The second culture clash: business versus technology

[00:06:20] So the next reasonable thing, the thing I hinted at a minute ago, is to focus on a customer, a customer we serve. But that begs the question, who is the customer? If we're going to focus on someone, who are we focusing on?

[00:06:44] Now, you'll see in many companies the product management and engineering will say, we do what marketing tells us to do, sales gives us things, the CEO has these ideas and we just implement them. That's who our customer is, that's who we serve. You might hear people described: there's technology, which is product management and engineering, and business. There's business and there's us, and we serve what marketing and sales does, the thing I just mentioned before.

[00:07:23] But now the problem is that we have the same culture clash that I talked about between product management and engineering. We move that wall and now we put it in a different place in the company, between business and technology. You see that language? That language is poisonous. Because those people in marketing and sales, the CEO, they're not your customer. They're your colleagues. Your customer is the people that pay your company for the products you build. That's what you have to focus on.

[00:08:09] So that's great. Okay, so we said there was the first culture clash, between product management and engineering, which is when you're only focused on your group's efficiency. So bonding it together removes that culture clash. The second culture clash is business and technology. Remove that one by focusing on customer value, recognizing that the other people in your company are your colleagues, not your customers. So that's the second culture clash. Remember I said there's four.

Rooting the roadmap in customer value

[00:08:44] So if we're really focusing on the end customer, the people that use our stuff, how do we know if we're delivering customer value? And the answer here is, look at your roadmap. The majority of the activities on your roadmap should be rooted in creating direct value for the users, for your customers, for your market. By the way, those are three individual terms that mean slightly different things, and it's important to understand those meanings and how those are different. I probably won't have time to talk about them today, but once again feel free to reach out to me afterwards and I will describe the differences to you, and why it's important, and why it is that not only do you need to understand it but you need to use that terminology in the company and your colleagues all need to understand it as well. But the majority of things on your roadmap need to be rooted in creating customer value for your users.

[00:09:43] You should be able to measure whether your team, product management and engineering together, are able to deliver that customer value, and that has to be the primary discussion you're having. It's not about the beauty of the architecture, the elegance of the code, or how many clicks there are on a UI, or even how speedy the system is. Those are all important, but the primary discussion has to be about, did you create customer value? Once again, you're trying to overcome that culture clash, you're trying to align.

[00:10:26] And then it's important that every member of the team needs to know how every story delivers value, and they need to embed it into how they think, into the soul of what they're doing. They need to argue one story over another, and the cost of doing it, and the criteria why the stories are there. And when I say every member of the team, I mean everybody on UX, everybody on QA, everybody in product, certainly everyone knows that, everyone in engineering. Everyone needs to understand the why. There's multiple ways to do everything. If people don't understand the why, they're not likely to consistently do it the right way.

[00:11:14] And you want to engage in that conversation, that product management and engineering are one team. You want to be able to engage in that conversation of, I understand why you asked us to do that, let me propose something else that might get done less expensively, take less time. If the people don't know the why, they're not going to be able to have that conversation. But that all goes to understanding who the customer is and delivering value.

Why customer value aligns you with the CEO

[00:11:45] Now here's the nice thing about that. I mentioned before that the CEO is your colleague, as is sales and marketing. The natural fallout about delivering value for your customers is that product management and engineering also falls into alignment with the CEO naturally. The job of the CEO is to create a sustainable company with high value.

[00:12:17] Now here's the fundamental thesis: that customers and markets only buy from companies that deliver value to them. Why would you buy from someone who wouldn't? Revenue is a side effect of delivering value. People will buy from you if you produce things that deliver value. Profitability is repeated revenue with unit margin on everything that you sell. I'm being a little pedantic here, but trust me. Net profit is gross profit less operating expenses: do it at a reasonable cost.

[00:12:55] And Benjamin Graham, if you've never read him, he's the guy that taught Warren Buffett, wrote books, and he said the intrinsic value of a company is the sum of all discounted cash flows. Said quickly: produce profit in everything you do. If your CEO wants to create a sustainable company with high value, product management and engineering as a team creating products that people want to buy because they create value for them makes you fall into alignment naturally with your CEO.

[00:13:33] If they are thinking about the customer correctly and customer value correctly, then by definition they will fall in line with the CEO.

[00:13:51] But here's the trick, and here's something that I'm not going to be able to have time to talk about in depth, but here's the trick to know. Not everything that creates customer value also creates value for the company. Just being innovative is not sufficient. MVPs and iterations by themselves are a walk in the dark. You need to be thoughtful about not just having everything on the roadmap create customer value, but being intelligent, being smart about what things go on the roadmap and why.

[00:14:34] This slide hides a one-hour presentation all by itself. We can talk about North Star metrics and the value of North Star metrics. People talk about one North Star metric. I argue that generally you don't want one, but you want a small number. How to create those, how to align those, how to align those with strategy. If you're interested in this, reach out to me and I will gladly spend time with you and talk about how to put together a proper roadmap that aligns not just customer value creation, but filtering it to the things that also create value for your company.

[00:15:16] Not just falling in alignment with the CEO, but getting the product roadmap in a way that creates value. The key here, and once again I don't have time to go into it too far in depth, is the difference between being a feature factory and a real product group. Being a real product group requires that the things that are on the roadmap that create value for customers also fulfill the company strategy. And believe me, you want to be a real product group, not a feature factory. Because when you're a feature factory you fall back into that second culture clash of, oh, people in the company don't perceive our value in product management and engineering, and so we just do what the salesperson says to do to close the next sale, or what the marketing person tells us to do. So you have to be smart about the things you put on the roadmap, that they're also fulfilling the company strategy.

The second tool: measurement and the epic statement

[00:16:19] So I promised you five tools to overcome culture clashes. I've only given you one. We have about 10 minutes left, so I'm going to speed through things. Alignment's the first one. The second one is measurement. It's not enough to know the things on the roadmap create value, but you need to be able to know what they are and report them.

[00:16:42] So which metrics do you report? Often people in engineering talk about velocity or cycle time or PR response time, and product management talk about, I created this roadmap, we finished this roadmap, we have this many user stories, this many bugs came out. These are often the metrics that engineering and product management communicate to the CEO and to other executives.

[00:17:09] The problem with these metrics is they're great internal metrics to run your department. Once again, to be efficient you need to know these things. But they address activity, not outcome. Once again, we're interested in providing value to customers. These are things that we do. Your CEO does not understand what those metrics mean. If you report to your CEO these kinds of metrics, your CEO is likely to think that you don't understand what the business is doing.

[00:17:55] So I propose to you that everything on the roadmap needs to talk directly about the kind of value that it creates. And here's one formula to do it: an epic statement. It's the second tool I'm giving you. An epic statement says, we believe by doing this specific feature for this specific type of client, they will achieve this specific outcome, and we will know that when we see this metric move. So once again: what you're building, for whom, what they get out of it, and how will you know. Everything that's customer facing on your roadmap should have a statement of it. This roots you into creating customer value.

[00:18:51] But there's a secondary benefit to metrics. It turns out that everybody in your company you can think of like a vector, and remember, vectors have two attributes, a magnitude and a direction, a heading. If you sum up all the vectors in your company, if they're all pulling in the same direction, you're getting maximum output. If people are doing different things, even if you hired a bunch of smart people, if they're doing things at cross purposes with each other, you're not making forward motion. By everyone understanding the things around the roadmap and how they create value and how you'll know, you'll tend to have everyone pulling in the same direction.

[00:19:36] John Doerr, he's a venture capitalist, if you don't know him you should probably read about him, he's a really smart guy, done a lot of good investments at Kleiner Perkins, said what we want is a team of missionaries, not mercenaries. Mercenaries are people that do what you ask them to do because you're paying them. Missionaries are people that do what they're doing because they understand and they care. By having all of the product-facing features on the roadmap have a mission statement, you've now told them why they should care and what they should expect.

The third tool: retro the epics, not just the sprints

[00:20:14] So we've talked about alignment, we've talked about measurement. Let's talk about review. People know how to retro their sprints. At the end of a two-week sprint they look at it, they look at the values of it and they say, did we get the same velocity we expected? Did we perform higher? Did we not perform as well as we expected? What did we learn?

[00:20:40] What people don't think about is to retro the epics. Sprints talk about velocity[?] and sprints talk about efficiency. We want to talk about effectiveness. And so by retroing the value of your sprint, did we in fact meet the value of your effort, did this epic actually fulfill this epic review, we can then ask ourselves questions of, here's what we expected, the value we expected to create for our users. Oh, we overperformed, that's interesting. What did we learn, what do we want to do again? We underperformed, that's sad. What did we learn, what do we want to change?

[00:21:27] If you retro the epics, now you have the flywheel of, we're here to create customer value, here's what our goal is, we made bets, right? Each epic is a bet on the roadmap. These bets succeeded, these bets didn't succeed, here's how we're going to bet better next quarter.

Transparency and iteration: report the bets to the whole company

[00:21:50] So we've talked about alignment, measurement, review. We're going to talk about transparency and iteration all in one, sorry, I'm speeding up a little bit here because we don't have much time. It's not enough to review the bets yourself, and this is the hardest thing: you've got to report broadly to the company about how the bets were made. You've made a promise to the company that things in the roadmap are good uses of company capital, to move the company forward, to create value for the customer and to fulfill the strategy. Now you have to come and say, here's how we did. This is the hardest thing, because you're exposing yourself. The things you do well are easy to talk about, but you also have to talk about the things you do not perform as well on.

[00:22:45] I said earlier, sales, marketing, the CEO, the CFO, the board, these are your colleagues. You've got to report to them how you do. By the way, you should expect they'll report to you how they do. Sales certainly does that. If you have an outside sales force: here's how we sold, here's how you know, we made quota or not.

[00:23:07] You're doing this not just because they're your colleagues, but because they know things that you don't know. That epic on the roadmap didn't work? Oh, that's interesting, here's what we're hearing from customers. If you don't have a direct sales force, marketing represents this sometimes. The CEO might know things like, here's what the trends are in the marketplace, or what competitors are doing. Marketing might know that as well. The board might know those things. There might be investment criteria: we need to double down in this stuff, we can spend more money. But unless you have that conversation about how you performed, you won't know. And then you iterate.

[00:23:53] I just have a few minutes left, so I'm going to skip a whole bunch of slides and leave you with this. The gentleman who wrote The Little Prince, I won't try to pronounce his name, my French is not good, he said this: love does not consist of gazing at each other but looking outward together in the same direction. Product management and engineering have the same task, gazing in the same direction. How do we serve customers? How do we create value in the world?

[00:24:28] As I mentioned, I'm glad to talk about any of this stuff again if there's stuff that isn't clear. Here's my contact information. You can hit me at this contact us. I realize this doesn't say my email address, but feel free to email me directly. You can hit me on LinkedIn. Actually the best thing to do is probably hit me on LinkedIn or hit me on contact us. And I'm glad to take any questions that people have.

Q&A

[00:24:55] Rory: Great, thank you very much, David. I really enjoyed that talk. It sung to a lot of what I'm interested in as well. We got a question in from Katarina that I think is something that I've experienced as well. She's saying that we do internal pricing innovations, so product pays engineering to build things. She's asking, what advice do you have for her in trying to get an alignment structure in place?

[00:25:30] David: So product pays engineering. Is that the way it is, or is that how they think about it?

[00:25:36] Rory: Yeah, so I don't have the full details, but in my experience what I've had is that product will get a budget approved and they'll kind of say to engineering, okay, now you're going to work for us.

[00:25:52] David: Yes, yes. So it's not terrible and it's not good. What I mean by it's not terrible is product management and engineering should come to the decisions together about how much should we invest for this much value. I don't like the language of, engineering, you now work for us. I like the language of, engineering, we work together to provide value. And that's why understanding the why is so important, for engineering to know, to say, oh, I understand what you're asking, we can do 80% of that at 30% of the cost and give you these other features, because I know the why.

[00:26:34] David: And so what's being described is an accounting mechanism for finance to understand what the investment is. Investment in markets and features makes perfect sense, because there's an ROI and the payback. But engineering is just a part of that. So part of it is, you might have to accept that accounting feature of paying for engineering, but you don't have to engage in the conversation that way, and I suggest you don't.

[00:27:05] Rory: That's some great advice. So hopefully, Katarina, that's something that you can bring back and take use of. So thank you very much, David. Unfortunately we're out of time, but thank you for sharing your insights, and hope everybody out there enjoyed it.

[00:27:19] David: Thank you.