[On-demand] Product Management Webinar: CPO Strategies

[00:00:00] Hi there, everybody, and welcome. My name’s Matt. Welcome to the ProdPad webinar on Empowering Product Teams: How CPOs Can Turn Strategy into Outcomes. We’ll give it a couple of minutes just to start off. Maybe tell me where you are and how things are there. So I’m in Edinburgh, Scotland, and it’s probably not as hot as a lot of Europe at the moment.

But yeah, we’ve had an awful lot of rain. So, where are you guys, and how are things with you?

I can see we’ve got quite a few people. So we’ve got, Mackenzie. Hi there. Seattle, USA. And, it’s [00:01:00] usual there. It’s always, like, wet and a bit sort of cloudy and, Northwest Iowa, so humid. You can hear the corn grow. Benjamin, good to see you too. Eileen in Chicago, “Storming here with tornado warnings.”

Wow, okay. That’s something we don’t get many of in Scotland, I think it’s fair to say. Kiri, good to see. Bristol, England. Know it well. Humid, too warm for us. Yeah. It’s definitely, uncomfortably warm in this country for most of us. And Tom, good to see you in Gatwick. Great of you to join us.

Product scene in Edinburgh, Tom. It’s pretty good, actually. We’ve got a lot of interesting companies up here. Product management has grown over the years. Back in the day, Product Tank and Mind The Product, helped grow that healthy community. So yeah, it’s pretty good, actually.

It’s pretty good. We’ve got various Fireflies joining. Maria, Surrey, UK, very dry and warm. Yep. We’ve had, bizarrely, in Scotland, plenty of rain. A weekend I was out [00:02:00] going for a bit of a walk in the country and the rivers were flooded, I mean, heavily so. So it’s a real difference between one end of the country and the other.

Rebecca, good to see you in Montana. Smoky here. And Greg in Pittsburgh. Fantastic. It’s rainy and cold. Okay. Yeah. It’s almost as good as old blighty. Yeah. I think it’s been a real mix here. We’ve had some of the country absolute drought, and the rest of the country still flooded.

So, Mitchell, good to see you. Hi. Thank you for joining. Maybe just give it another couple of minutes till sort of five past. We’ve got a healthy set of attendees at the moment, but, I’d like to let a couple of others in. Let them grab their cup of coffee and join us.

Cherry, you’re in [00:03:00] Atlanta. Typical hot, humid day. Yeah, that part of the world gets pretty humid, doesn’t it?

I’m interested, Benjamin, when you say you’re in Northwest Iowa and you can hear the corn grow, what does corn sound like when it’s growing? I’m intrigued. That’s a sound I’ve never heard, so you’ll have to share that with us

Debbie, hi. Reading, again, somewhere I know very well and Sherry says, “The humidity is almost as thick as raindrops falling.” Yeah, uncomfortable I’m sure

And Amanda from Chicago, good to see you also. Thank you for joining [00:04:00] us

Give it one more minute and then we’ll kick off.

Chantal from Northern Spain, hello. And Matthew from Seattle says hello. Hi, guys. Welcome, and thank you for joining us. So I’m gonna kick off now. Hopefully I will share my screen with you. Give me a shout once you can see that.

You should all have that now.

Great. Oh, Azara, hello from London. Good to see you. And Samir from St. [00:05:00] Louis, Missouri, good to see you also. So we’re gonna talk today about empowering product teams. It’s gonna be quite a targeted session, so I’m aiming for about 20 minutes maybe plus a few questions. Your time is valuable, so I want to get as much information in there as I can in the time available.

First, a quick introduction to me. So I’m Matt. I’m CEO of ProdPad. Now some of you may be wondering about Janna and where Janna is, and isn’t she CEO of ProdPad? Janna is our founder and still very, very much part of the team, but Janna asked me to come in and help lead the next stage of growth for ProdPad.

So it’s an exciting time for us, and we’re really enjoying the growth that we’ve got and our wonderful users. And I’m here to bring a bit more experience, a different experience, and joining the team. So I’m working with Janna and Simon and the rest of the ProdPad team, and hopefully you’ll be seeing a lot more of me [00:06:00] over…

for the next few months as I do more of these webinars and you hear more from me. So, as I think I said, I’m going to aim for about 20 minutes or so, something like that, and I will leave time for questions at the end. Please feel free to add them either into the chat window or the Q&A window, and I will loop back to those and try and answer as many as I can.

But I think for me, the purpose of this webinar and the reason I came to it is I’ve been in that CPO seat, and I know that one of the hardest things for me was speaking to a board, understanding the strategy where we wanted to take the company, but struggling to work out how to do that with a team.

So I want to bring some personal experience and learnings to this webinar, and maybe you can share some as well, in the chat, and we can [00:07:00] share them with one another.

So let’s start with the problem. And this you’ve probably all seen before, you recognize it. But the challenge is we all start with company strategy, and it looks great, and everybody’s happy. And then somehow it turns into projects and feature requests. And we’re not entirely sure how we ended up there, but some people ran off and thought, “Do you know what I’ll do?

I’ll break this down into a problem and give you a series of features that deliver the strategy.” And then, of course, what comes straight after feature requests are delivery commitments. So before we know it, we’ve got a release plan, which may even be called a roadmap, but it’s a release plan. And that release plan has been shared.

Suddenly we have concrete dates with features attached to those. And then we have lots of activity. We’re not quite sure what we’re [00:08:00] doing or why, but suddenly we’re releasing things, and we’re getting marketing ready to talk about those things. So we’re really, really busy, but we’re not quite sure what we’re aiming for.

And this is the point at which the question marks come in. Now, it’s a classic loop that you’ve probably all seen many, many times. Teams doing things, lots of things. But your strategy is not getting any closer. It feels like everyone’s running around, everyone’s busy, they’re all pulling their hair out, but nobody is getting, we’re not getting closer to our strategy And interestingly, as CPO, this is the point at which you’re usually asked to sign a budget for more people because you’re not getting through things quickly enough.

Customers aren’t seeing the value of your product. The board isn’t seeing the impact on your company, and that’s when you get [00:09:00] the form on your desk asking for five more people in a team. You’re sat scratching your head because you’re trying to think, “Well, if we’re not delivering it now, is adding more people actually going to make a difference or not?”

So you’ll recognize that loop, I’m sure. So I’m gonna take you through today how I think we should be breaking that loop and preventing the busy work that doesn’t deliver. But just before we do, I was looking through some of Janna’s old slides, and somewhere at the back of one of the slides I came across this, and I think this is brilliant.

For those of you who have heard, back in the day, IBM decided to pay people by lines of code or thousands of lines of code, KLOCs. And that thousands of lines of code, the more you generated, the more you got paid. Now, funnily enough, people [00:10:00] optimized for maximum lines of code, so people wrote very inefficient code but they were really busy.

But as the measure of success, lines of code was it. Story points, same difference. It’s not about value, it’s just about how many, if you bump up the number of story points attached to a particular item, you can get through far more story points. It’s not delivering any greater value. The same for pull requests or bringing it right up to date tokens spent.

The more tokens you’re spending in your AI provider does not equate to useful, valuable outcomes. Or as I like to put it at the bottom, busy work does not equal outcomes. So how do we get away from this? Well, let’s take a step back. I think the CPO’s role is predominantly someone where she or he creates a [00:11:00] link between company strategy, investment, and product work, focusing on outcomes.

So one of the big things that I discovered was when I moved from an individual contributor to a CPO role, I had to stop thinking about what features we’re building and start thinking about the outcomes. What are we betting the investment will move? So as a CPO, I used to make investments in teams, in markets, in various areas, and I was betting that that would help me to achieve my strategy.

Now, tell me in the chat, is this a loop that you recognize where you’re being asked for features and, it’s not quite sure how it’s going to deliver the outcomes or strategy?

Yep. So we have, Tom, [00:12:00] you recognize this. Absolutely. How about anyone else? Is this a loop that you recognize? Yep, Zara, you’re there too. I suspect most of us have probably been there. Chism, absolutely. Kim, yes, it literally happened today. Christine, constantly. Mackenzie, yep, we chase a lot of one-off big ideas dreams.

Yeah. So we’ve all been there, right? We’ve all felt that pain. So how do we break that? Well, the first thing we can do is recognize it. And then we can think about what we do differently. So this was the slide I showed you a moment ago. Go from company strategy to feature request, to delivery commitments, to busy work that’s not delivering the outcomes that you want.

So let’s take a step back. Let’s think about what better might look like. So the shift I want to focus on is this: in the first model, strategy got translated very quickly [00:13:00] into projects and features. And you know, it’s almost, I think, a big upfront design approach, which we feel we’ve probably moved away from, but it’s almost the strategy becomes the big upfront design, and then we just break it down into work tickets really, really quickly.

So what I want to do instead is think about the success becomes whether we’ve delivered what we committed to rather than just producing a release. So that might sound silly, but I’ll share an anecdote with you in a bit about a company I worked with who had exactly this challenge. So in our second model here, the one on screen, you can see what I’ve changed in the pink boxes.

We keep the strategic intent alive, and we turn it into project bets, and we talk about a problem worth solving and the outcome we expect to [00:14:00] create. So in other words, we believe, we bet, that we can change X, whatever X is, from twenty percent to forty percent, for example. Okay? Now, this is not unique. This is Marty Cagan’s thoughts in product model thinking about product strategy should identify the most important problems to solve, and then empowered teams should be given those problems and outcomes rather than simply a list of features to build.

So who’s come across that, sort of thinking, whether it be from Marty Cagan or someone else? Have you guys seen that kind of thinking? Yep. There’s a few people in the chat who say they have. Yep, Christian, Tom, had. Right, Tom, brilliant. So you’ve said yes, in practice, never, in… Or yes, in principle, never in practice.

So let’s talk about that. We’ve got [00:15:00] most important problems to solve or project bets. They don’t seem the same thing. Bring that up at the end, and that’s a really good point, and I’d like to think about that and talk through that with you. So with an investment bet, we’re choosing to put time and money behind an opportunity because we believe it will create a particular customer and business outcome.

So the team’s empowered to work out how. The leadership team’s job is to keep asking whether the evidence says the bet is paying off. So it’s not about what have you released, it’s like show me the answer, show me the evidence. So how do we do that? Well, I’ve got this idea here of the opportunity, the customer outcome, the business outcome and assumptions.

So the opportunity, what problem are we choosing to address? What does it look like? [00:16:00] And, you know, talk about the customer outcome. What’s the customer, what behavior are we gonna see change? Business outcome, because it all has to link back to what does it matter to the business commercially? What difference is it gonna make to us commercially?

And assumptions. What must be true for the bet to work? So when working with CPOs, I encourage them to think about these questions. And I quite often like to start with what I call a bet template or a hypothesis template. And how many of you start with that kind of hypothesis or bet template in your process?

I see, yep, there’s a couple of you there who use something similar. Try to set up, a hypothesis or a bet template before you start work. Anyone else? Yep, defining a problem statement first. [00:17:00] Jay, agreed. Absolutely. So yeah, what is the problem? What’s the customer outcome? Jay, yes, helps as part of R&D and discovery.

Absolutely. Absolutely so. So what does this look like? Well, I wanna talk about some people say that the key is set up the team, set this up, the opportunity they talked about, et cetera, and then get out of the way. Well, I don’t think that’s absolutely true. A lot of CPOs follow prescription, so build this feature.

And you’ll have all heard that kind of idea to me. Abdication. Abdication’s even worse. It’s just throw it over the wall to the team and run away as fast as you can. So go and improve retention. But how do you start work on that? You know, you can imagine as your team, they’re told, “Go and improve retention.”

And they all try their [00:18:00] own ideas, and you’re kind of pulling in different directions, and it’s not really clear how people are working together. So what I want is empowered teams, and that’s where I give them enough scope to guardrail those ideas and those investigations and the discovery, but not letting people, run off in a completely wild direction, but equally telling them why it’s important.

If teams understand why something is important, then they’re more likely to deliver what you need So if we’re gonna empower teams, what does that actually mean? How do I achieve empowerment with the team? So the idea here I’ve put there in terms- has a bit of structure around it, far more so than build this feature.

So a model I like to use is this one. So the outcome, context, evidence and boundaries. [00:19:00] So what I want to do is tell people why it matters to the company. Explain which outcome the team owns, tell them what we already know, and what boundaries and constraints apply. So this model of OCEB, I’ll give you an example here.

So we can see it tells people what we know already, what data we have, what boundaries exist, what the outcome is, and why it’s important to the company. I find, as a leader, that people always align better if they understand the context of their work, what impact it has. So notice what I have not done.

And the answer is, I haven’t told the team what to build, but I haven’t told them, “Just go fix this problem.” I’ve given them enough [00:20:00] structure to guide them, but still leave them a lot of space and opportunity to think. They know the outcome, they know why it matters, what evidence we already have, and what the boundaries they’re working within are.

So this is the space in which real empowerment works.

And I want to use evidence to drive this. I give you an example of a company I worked with years ago who performed a major release of their product. And I sat down with the leadership team, and I’m talking CEO down, and asked them, “Was it a success?” And they kind of looked at one another and thought for a while, and, the answer was, “Well, we released it on Thursday.”

And it rapidly became apparent that a success for them was we’ve released something. It didn’t go as far as to think about what [00:21:00] impact it had on their customers or indeed therefore the company. Now, that might sound really silly, but if you don’t set up things in this kind of model, then a release is what you get.

That short, that first version of the flowchart I showed you very quickly becomes features, and therefore success is we’ve released the feature. So my key questions are: Is the customer behavior changing? Are the expected outcomes emerging? What have we learned? And should we stop, start, continue, adapt based on the evidence we’re seeing?

So this is what it looks like in practice. Here we have a completed model. So strategy becomes bets. Bets become opportunities. [00:22:00] Opportunities allow people to think and experiment. Teams act and learn, starting with discovery, moving ultimately to delivery, but with a clear focus on the evidence and outcomes.

And those evidence and outcomes drive to be future investment choices, and those future investment choices update the strategy. So it’s a continuous loop.

I’ve had a few pieces in the chat. OCEB would be useful to have as default fields in ProdPad initiatives and ideas. Agreed. I think that’s the sort of thing that we could look at and it’d be good to get feedback from people as to whether they feel that’s a useful addition to the product.

So I’m gonna move forward. Takeaways from this session before we move [00:23:00] to questions and answers. So make your bets explicit. Okay. Start off with a bet template or a hypothesis template or something similar, and use that model that I showed to help guide people on what a good solution or a good outcome for that bet might look like.

And give teams the opportunity to own the solution. But guide them so they understand the context of what they’re doing and what good looks like. And then manage future investment through evidence. Use the evidence to drive future investments into product markets, ideas, et cetera.

So I’m gonna move now to some questions and answers. So if you either want to fill out questions in the Q&A section or in the chat, [00:24:00] I’m gonna stop sharing just now and pull up the chat window, so that I can see it. Just bear with me a second while I sort this out. So one of the questions I’ve had is, ” how do you stop a product bet becoming another dressed up project?”

Absolutely. So this is absolutely what you’d expect. So people start by saying, “We’re gonna take a bet,” and it’s just a way of short-cutting a process and getting a project, something into the product. So my answer to that would be Wendy, that a good test is whether the team is being given a solution or an outcome.

So if the bet is really just, I don’t know, build feature X, then nothing’s changed at all. A proper bet should, as I’ve said, make clear the problem [00:25:00] and the outcome you expect, why it matters commercially, and what assumptions need to be true. But leaving the team room to discover the best response. Another question, “what happens if the evidence says the bet is not working?”

This is a great question. What happens if evidence says the bet is not working but leadership is already heavily invested in it? So as a CPO, I’ve been in that seat where the data shows you one thing, but do you know what? The exec have said, “We need to do this this quarter.” Well, I guess that’s why I like the language of bets. ‘Cause it’s not a promise, it’s an investment under uncertainty.

I like that expression, an investment under uncertainty. The point of the evidence loop is to make [00:26:00] it easier to change or adapt, before sunk cost thinking takes over. We’ve all been in that place where we’ve been working on this for six months, so we need to keep it going. So that’s what I’m trying to avoid here.

So the discipline is to agree upfront what evidence would make you continue, change direction or stop. So in various roles I’ve had, having almost a playbook in terms of if this number doesn’t hit this point by this date, we’re gonna put a pause and we’re going to reassess. But agreeing that upfront because

otherwise you find yourself just getting dragged along, by this bet and it’s fundamentally going nowhere. Another couple of questions have come in.

Yeah, okay. So question from someone here about where you’re providing services and it’s [00:27:00] difficult where someone’s under contract, they may not be able to leave, so measuring retention can be delayed. Agreed. So this is the same problem with revenue and retention. It can be a hugely lagging indicator to the thing that made the difference.

And for me, this is where taking sense checks regularly and quickly. You know, taking a pulse check from your customers, finding out how happy are they. Looking at other metrics. Adoption, task success rather than contract retention. Contract retention and revenue are, in my view, awful, KPIs because they’re so lagging it’s impossible to work out.

You see revenue dropping off or retention dropping off, and it’s really unclear what it is that caused people to churn. So I’m just looking through a final question, recognizing we’re almost to time now. So do you use investment bets just in BAU or [00:28:00] as new product or both? Both is the simple answer.

Jay, you said because as in some companies like mine, budget is relative, and that makes sense. But ultimately each idea, each bet within whichever space it is, whether it’s BAU or new product or whatever, the key here is empowered teams, and the other key is setting the outcomes. What outcomes are you looking for and measuring them and turning that into a feedback loop.

And for me, that’s important, whether it’s BAU or new product. So I’d like to say thank you. This is my first webinar. I hope you guys all enjoyed it. I’m gonna be back over the next few months doing more of these sort of short, sharp 30-minute webinars, which are hopefully insightful and give you insight into sort of CPO-type thinking.

And I look forward to seeing you all [00:29:00] again soon. So thank you very much and you have a good evening, a good day. Bye-bye.