Delivering Exceptional Customer Value: Strategies for Success - UXDX Presentation

David's Notes:

In today's competitive landscape, prioritizing customer value is essential for business growth. Recent discussions have shed light on the importance of putting customer value at the forefront and have provided valuable insights into effective strategies for achieving it.

When devising our roadmap, it is imperative to concentrate on creating direct value for our users, customers, and the market. While technical aspects certainly have their place, they should not overshadow our ultimate goal of delivering customer value.

To gauge our success in delivering customer value, measuring it becomes crucial. Instead of solely focusing on technical metrics, we need to assess whether our team is effectively meeting the needs and expectations of our customers.

An Epic statement emerges as a valuable tool in prioritizing customer value. By clearly defining the feature, target client, expected outcome, and success metric, we can align ourselves with the objective of creating customer value.

By conducting retrospectives on the value delivered by each epic, we can learn from both successes and failures. This process allows for continuous improvement, enabling us to make more informed decisions regarding our roadmap.

Ultimately, prioritizing customer value is pivotal for the success and growth of our business. Our roadmap should revolve around generating direct value for our customers, and we must continuously evaluate our progress in achieving this objective. By utilizing the Epic statement and engaging in retrospectives, we can constantly improve and surpass customer expectations. Let us wholeheartedly embrace this customer-centric mindset and propel our company's success through the delivery of exceptional customer value.

Transcript:

[00:00:00.330] - David

Hello to everybody. As Roy said, I'm going to talk about culture class making product management engineering work effectively together. And I have about an eight hour presentation. 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 Roy 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, I'll give you a little bit of context about who I am and how I got here and what I'm talking about. This. I was an ex CTO and ex Chief Product Officer. I ran both those departments in 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. And our fundamental thesis and this fundamental thing about this talk is about product management 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.220] - David

And we work with a number of companies. We do four things. We will go into technology companies, evaluate proc, manage 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 manage engineering being effective for companies that have a CTO or Chief Product Officer. They often ask us to coach the technology 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 management engineering teams, and then help hire someone on. And we also do due diligence for VC, PE firms and M and A transactions. And we've done it for a bunch of companies. The reason I'm pointing this out is we see patterns, patterns, things we see at the Walt Disney Company. We've also seen startups mid market companies worked@linda.com before they got sold to LinkedIn for I think it was $1.4 billion. B to B companies, B to C companies.

[00:02:33.040] - David

There's commonalities about product management and engineering that we're able to apply to. Bunch of companies. I'm going to share a bunch with a bunch of those with you today. 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 classes. 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, iteration, as those tools to overcome the culture clashes now, the first one is alignment. Now, I mentioned before that our view is product management and engineering have one function as one team. That means they need to get aligned. And there's really three stages of alignment. I would talk about people who run product manage engineering. I'm using CTO and Chief Product Officer. But I mean, here the product management and technology executives are really also all the people in the team. People often think their job in those roles to optimize their team's efficiency. How do I make my team be better at engineering?

[00:04:02.800] - David

How do I make my team product management be better? In product management, I have some input, something that we do, and some output. So if I'm in technology, I have some user stories that I get as input. My developers code, some stuff we output, meet the acceptance criteria. We're done, we're good. We should do that faster, better, less bugs. 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, and we're good. That's what I do. I want to optimize my team to make that as efficient as possible. 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, 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. And so think about product management.

[00:05:37.190] - David

And engineering only thinks about what we're doing and 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 what it was going to get done. They told us when it was going to get done. If we didn't get released in time, it's their fault. And it creates finger pointing, creates that barrier that I talked about. That's the first culture clash. 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 is, who is the customer? If we're going to focus on someone, who are we focusing on? Now, you'll see, in many companies that product management, 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.

[00:07:01.210] - David

That's who we serve. You might hear people describe there's technology which is product management, engineering and business. There's business and there's us. And we serve what marketing and sales does. The thing I just mentioned before, but now the problem is that we have the same culture clash that I talk about doing product management engineering. We move that wall, and now we put it 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 how you have to focus on that's. Great. Okay, so we said there was the first culture clash between product management engineering, which 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 class. Remember, I said there's four. 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?

[00:08:55.130] - David

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, that 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 is important. And why is it 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. You should be able to measure whether your team, product management, 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.

[00:10:13.860] - David

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. 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 their 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 and when. I mean every member of their team, I mean everybody on UX everybody on QA, everybody in Prox, 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 the right way. And you want to engage in that conversation. Since product management 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.

[00:11:38.260] - David

But that all goes to understanding who the customer is and delivering value. Now here's the nice thing about that. The nice thing is I mentioned before that the CEO is your colleague as his sales and marketing. The natural fallout about delivering value for your customers is product management engineering also falls into alignment with the CEO naturally. The job of the CEO is to create a sustainable company with high value. Now here's the fundamental thesis is that customers and markets only buy from companies, 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. And Benjamin Graham, if you never read him, he's the guy that Warren Buffett, he taught Warren Buffett. He wrote books and he said the intrinsic value of a company is the sum of all discounted cash flows said quickly produce profit at everything you do.

[00:13:13.820] - David

If your CEO wants to create a sustainable company with high value, product management engineering as a team, creating products that people want to buy because they create value from them makes you fall into alignment naturally with your CEO. If your teams are thinking about the customer correctly and customer value correctly, then by definition they will fall in line with the CEO. 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 is going to create customer value, but being able to be intelligently, being smart about what things go on the roadmap and why. This slide hides a 1 hour presentation all by itself. We can talk about North Star metrics and the value of North Star metrics and people talk about one North Star metric. I argue that generally you don't want one, but you want a small number.

[00:14:53.190] - David

How to create those, how to align those, how to line 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. Not just falling in alignment with the CEO, but getting them, getting 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 provide value for customers also fulfill the company strategy. And believe me, you want to be a real proc 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 engineering, and so we just do what the salesperson says to do to close next sale or what the marketing person tells us to do.

[00:16:10.260] - David

So you have to be smart about the things you put on the roadmap that they're also fulfilling the company strategy. So I promised you five tools to overcome culture class. I've only given you one. We have about ten minutes left, so I'm going to speed through things. So alignment is the first one. The second one is measurement. So 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. 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. And these are often the metrics that engineering and product management communicates to the CEO and to other executives. The problem with these metrics are 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.

[00:17:39.600] - David

If you report to your CEO these kind of metrics, your CEO not only then understand, but are likely to think that you don't understand what the business is doing. 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 in. 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, but there's a secondary benefit to metrics. Turns out that everybody in your company you can think of like a vector. 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 class with each other, you're not making forward motion.

[00:19:22.950] - David

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. John Dore, he's a venture capitalist. If you don't know him, you should probably read about him. He's really smart guy. He's 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. So we've talked about alignment, we've talked about measurement. Let's talk about review. People know how to retro their sprints. 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? Do we perform higher? Do we not perform as well as we expected? What did we learn? What people don't think about is to retro the epics sprints talk about retro and sprints, talk about efficiency.

[00:20:51.820] - David

We want to talk about effectiveness. And so by retro the value of your sprint, did we in fact, the retrovalue of your epic, did this epic actually fulfill this epic value? 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 have we learned? What do we want to do? Again, we underperformed. That's sad. What have we learned? What do we want to change? 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. So we've talked about alignment, measurement, review. We're going to talk about transparency, iteration, all in one. Sorry, I'm spitting 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, and the things in the roadmap are good uses of company capital to move the company forward, to create value for the customer and to fill the strategy.

[00:22:31.300] - David

Now you're going 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 that you did not perform so well on. 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'll do. Sales certainly does that. If you have an outside sales force, here's how we sold, here's how we may quote or not. You're doing this because not just because your colleagues 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 are the trends 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.

[00:23:45.800] - David

But unless you have that conversation about how you performed, you won't know. And then you iterate. 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 isn't good. He said this love does not consist of gazing at each other, but looking outward together in the same direction. Product management, engineering have the same task, gazing at the same direction. How do we serve customers? How do we create value in the world? 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 just probably hit me on LinkedIn or hit me on Contact US. And I'm glad to take any questions that people have. Great.

[00:24:56.610] - Roy

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 Katerina that I think it's something that I've experienced as well. She's saying that we do internal pricing innovation, so product pay engineering to build to build things, which is asking what advice do you give for her in trying to get alignment structure in place?

[00:25:30.220] - David

So product pays engineering is that the way it is. Is that how they think about it?

[00:25:37.790] - Roy

Yeah. 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.500] - David

Yes. So it's not terrible and it's not good. And what I mean it's not terrible is proc management. 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. It's like, 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. And so what's being described as an accounting mechanism for finance to understand what the investment is, investment in markets and features make perfect sense because there's an ROI and a 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.320] - Roy

That's some great advice. So hopefully, Katerina, 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.600] - David

Thank you.