Category: Blog

Introduction

I think product strategy is easy and everyone should do it, and I’ve got 30 minutes to convince you all of that. So, a few minutes of me talking, some work for you to do, and then we’ll come back together and see if I’ve succeeded.

Why product strategy is important

If the world was simple and predictable we wouldn’t need strategy. We could just make a plan, stick to it, and achieve what we set out to. Wouldn’t that be nice?

But it isn’t like that. The world is chaotic and uncertain and unpredictable and constantly changing. Just look at some of the things that make our little world in higher education chaotic; global politics, UK politics and policy decisions, cost of living crisis, job market and employer expectations, AI and other emerging technologies. Does anyone think we live in a calm and predictable world? Of course not. So we need ways of thinking, mental models and conceptual tools that help us deal with the uncertainty in intentional ways.

That’s what product strategy does.

What is product strategy

Strategy gives us a way of responding to change in an organised, intentional way. It helps us use the things in our control to affect things outside of our control.

For product managers, the main thing outside of our control that we want to affect is user behaviour. We want to change that in ways that help people achieve things that are important to them, like getting qualifications that helps them get a new job so they can be more financially stable in this chaotic world.

And some of the things within our control might be the interfaces our users see, the features they interact with, the policies and processes they don’t see, or the data we use.

How to create a product strategy

I’m going to tell you about a three-step method I use for creating product strategies, and then you’re going to use it for some example products.

This method works for small, simple product strategies (which I’m a big fan of, strategy doesn’t have to be this big serious thing that takes important people months of thinking about).

Finding worthwhile problems

The first step is to find your worthwhile problems.

If you asked me to explain the job of a product manager in three words, I’d say “finding worthwhile problems”. That’s what it’s really about. Finding problems is easy, they are all over the place. Finding problems that are worth solving, that’s the tough bit.

We might use market research, data analysis, user research, our experience, looking at competitors and comparators, technical constraints, organisational processes, etc., etc., to find problems. We might assess their worth-solving-ness by how much it’ll cost to solve, how many people are affected, how much they are affected by the problem, what might people be able to do if they didn’t have that problem or what the consequences are for them of letting that problem exist.

Remember I said this method works for small strategies and big strategies, this is how. We can spend ages doing lots of research and analysis into big problems, or we do a quick bit of analysis on a small problem. You’re the product manager, you choose what kind of research and how much is enough to find those worthwhile problems.

Once you’ve got your worthwhile problems, you need hypotheses for solving them.

Hypotheses for solving them

Notice, I didn’t say you need solutions. We don’t start with what solution shall we build because the world is unpredictable and users behave in strange ways, so we can’t say for certain that shipping this feature or changing that process is definitely going to solve the problem. That’s why we think of hypotheses.

We can phrase hypotheses as “if, then” statements. If we do this, then that will happen. If we make the button bigger, then more people will click on it and book onto a tutorial. If we remind people a few days ahead, then more people will book onto a tutorial. If we tell people how important the tutorials are, then more people will book onto a tutorial. We’ve can have lots of hypotheses about how to solve the problem of people not booking onto tutorials.

Before we can get on with the work of building something that proves our hypothesis, we need a way to know if our hypothesis was right or not.

A way to know the problem is solved

The third part of the strategy, often the bit that gets missed and always the hardest bit, is measuring and evaluating whether the problem has been solved by the new feature we shipped.

If finding worthwhile problems is planning the party, hypothesising and building solutions is going to the party, then measuring and evaluating is cleaning up after the party. No one likes doing it, but it’s really important. It’s important because the worthwhile problem you found actually affect real people. If we don’t solve it, they carry on having to deal with the problem, so we need to be able to measure whether the changes we made solved the problem.

Quite often, in fact more than product managers want to admit, we’ll ship a solution, evaluate it, and find out it didn’t solve the problem. That’s why we want multiple hypotheses for solutions, so if one doesn’t work we can try another. And keep validating our hypothesise until we know the problem is solved.

Once again, we can do this in a big way or a small way. It can be a long-term, rigorous and robust evaluation methodology or a quick look at analytics. But usually, the best way to know if a problem is solved is in the changes we see in user behaviour. If more people are booking onto tutorials, that behaviour tells us we’ve solved the problem.

Your turn (Breakout exercises)

Ok, now it’s your turn. You’re going to be put into breakout groups. You have 10 minutes to write a product strategy using the three statements:

• Our worthwhile problem is…
• If we do…, then this will happen…
• We’ll know it’s solved when…

In your groups, write a product strategy for your product.

• Group 1: Task app
• Group 2: Travel booking
• Group 3: Messaging
• Group 4: Photo sharing

Then you’ll come back and tell everyone your product strategies.

Group 1: Task app

Group 1, tell us your product strategy for a task app.

Group 2: Travel booking

Group 2, tell us your strategy for a travel booking product

Group 3: Messaging

Group 3, your turn. What’s your strategy for a messaging service?

Group 4: Photo sharing

And lastly, group 4, tell us about your strategy for a photo sharing product.

Thank you all, good work.

Writing product strategies in real life

We’ve got a couple of minutes so I wanted share a few thoughts on writing product strategies in real life for your products

Get people together

Product strategies are better when they have multiple perspectives. Get your team together and spend time figuring out your worthwhile problems.

Start with the smallest, simplest strategy

Pick one worthwhile problem, come up with some hypotheses about how to solve it, do those things and measure to see if the problem is solved. If it isn’t, pick another hypothesis.

The more you do it, the easier it gets

Product strategy really doesn’t have to be a big complicated thing only done by senior people. The more practice you get the better you’ll become at reeling off, these are the problems we’re tackling, this is our current hypothesis for solving the problem, and this is how we’ll know if we’ve succeeded.

Wrap up

So, I thought there was a worthwhile problem to solve around the myth of product strategy being a complicated, time-consuming thing that only senior people do. My hypothesis for a solution was to introduce a lightweight method for creating product strategies that every product person can use, and now you can all tell me if I’ve succeeded by raising your hand.

Thank you all for listening.

This year’s numbers

Completed 1,649 tasks.

Spent 37,245 minutes in meetings.

Wrote 43,102 words in 52 weeknotes.

Had 22,830 visitors to my website.

Highlights of the year

Started an MBA.

Was invited to do a talk to a product leaders group, even though I had to cancel it was really nice to be asked.

Facilitated retros with many of our leadership team.

Did more line-manging and coaching of other product managers.

Most interesting ideas I explored

Product strategy

Everyone wants to do product strategy but no one knows what it means (me included).

Strategy is fundamentally about how to use what’s within your control to affect what’s outside your control. If you’re trying to affect something within your control, you don’t need a strategy, you only need an implementation plan. Strategy is only necessary if you’re facing ambiguity and uncertainty. The more uncertainty you’re dealing with, the better your strategy needs to be. Wicked problems need lots of strategy.

I haven’t yet found a better framing for product strategy than the three parts of ‘a worthwhile problem to solve’, ‘hypotheses about how the solve it’ and ‘a way to know if the problem is solved’. It works well because it treats solutions as hypotheses and has a feedback loop to know if the problem is solved, and because it allows for different depths depending on the uncertainty being faced. If all you want to do is change some user behaviour so the product becomes stickier, then your product strategy can be pretty light touch. But if you want to tackle educational inequality, then your product strategy needs considerable depth to understand the problem (including causes and effects), lots of consideration about which are the right hypotheses

The problem with most strategies is that they are too inward looking, they are based on what an organisation wants to achieve rather than what’s going on in the market and with users. There’s lots of established thinking that product managers should use, such as supply and demand, queuing theory, distribution strategies, etc., etc., to underpin and inform their hypotheses about how to solve the problem, and help them loom outside their organisation.

Product tools

It bothers me slightly that there aren’t any good product management tools. There are plenty of delivery tools that manage workflows, but I’ve never seen one that instils good product practices such as user research analysis to identify problems, connecting problems to hypotheses for solutions, and measuring user behaviour to understand if the solution worked. If I wanted to be an entrepreneur, this is what I’d be working on.

Feedback loops

Feedback loops are an essential part of modern complex systems (which is what a product is) and so an essential part of working in those systems. They are one of those things that once you see them, or more often see the absence of them, you can’t unsee them.

One of the most important things I learned is that feedback has to be an order of magnitude faster than the system or situation being controlled in order to regulate it effectively. That means, if you’re shipping updates to a product fortnightly, you need to be collecting, analysing and responding to user behaviour feedback on those releases hourly. If the feedback loops are slower than what’s going on in the system, then the system can run off in an uncontrolled and unregulated direction that is difficult to come back from.

Feedback loops also helped me rethink how agility works in waterfall projects, where it’s less important that all the same kinds of activities are done in the same phase than it is that those activities have effective feedback loops to check they are getting things right.

Flow efficiency

Got a little obsessed with Flow Efficiency, the ratio of the total time spent in value-added work activities divided by the total time taken. It’s a really important concept and measure that touches prioritisation, capacity and value delivery. For example, if you wanted to understand the flow efficiency of how issues are dealt with you’d record the number of working hours from when the issue is detected to when it’s resolved, and divide it by the number of hours spent actively on it and you’d see how little of the total time is spent on the value-adding work. Of course, not all work is important enough to warrant improving it’s flow efficiency, but if we have no means of understanding the work that is important we’ll never be able to focus on it.

Digital transformation and the fourth industrial revolution

This is the big, ever-present, topic that affects and explains a lot of what’s going on in the world. No one knows how it’s going to play out but we can spot the trends by looking back at the previous industrial revolutions. Capitalism, globalisation, climate crisis, global economy, and political power shifts; all of these help us understand why the world feels so uncertain and like everything is changing all at once.

What a time to be alive.

At the organisational level, there are a couple of interesting trends, one about how organisations are understood and the other about the way work happens.

Converting organisational structures and business logic into a machine-readable format is one of the most important themes of digital transformation. Codifying what humans do, so that in the future machines can do it instead is the capitalist agenda. If you don’t believe me, ask yourself what Microsoft’s end game might be by having an org-chart in Teams, transcribing meetings, and giving all that data to Copilot. It creates a machine understanding of an organisation, of who speaks to who and about what. Which takes us to the second theme; how work gets done.

The ideas of liquid modernity that underpin digital transformation suggest that work is becoming increasingly continuous and that there is no end state to reach. The idea that the transformation will be done one day is an outdated notion. We aren’t shifting from one way of working to another, we’re shifting from a fairly static way of working to one that is never going to stop changing. How to respond to constant change is the practical question for every organisation.

I think part of the answer we’ll see is models from the on-demand economy being used to organise work within organisations. These models, which you might be familiar with for last mile delivery like Uber and Evri, rely on algorithms to distribute work (which you can only do effectively within an organisation if you understand who talks to who about what) and will learn to handle different types of work (at the moment we really only use them where every task can be completed in basically the same way, e.g. deliveries). Algorithms can change far more quickly than people so they really are the only viable option for a future on constant change.

Positioning product managers

I haven’t written about this much but it’s been on my mind a lot this year. From the extremes of “AI is going to replace product managers” to speaking to product people struggling to know what their role involves and should evolve to, how product managers position themselves and their profession is a constant question.

Product management is a very contextual role. That means its different in every organisation, for each product, and depending on the different skills of the person. This is a good thing. It’s a source of confusion also, but its better than trying to create cookie cutter product managers that only do certain things regardless of whether that’s what the product, team or organisation needs.

My suggestion is that product managers look at the intersection of what skills they uniquely bring, what the organisation needs, and what is industry good practice.

This helps us answer questions like, how technical should product managers be. If they work in an organisation with other technology experts then they don’t need to be at all technical, but if the team doesn’t have data analysts then the product manager probably needs to know how to run SQL queries. A very technical product manager working in a team of very technical people is likely to be too focused on the technology and miss what the organisation really needs from a product manager. A better positioning for a product manager in that situation would be to understand how technology affects users, the market and society in general. What affect does ubiquitous technologies like smart phones have on user behaviour? What supplier lock-in is the organisation at risk of? How are technology trends shaping competitor products? This is the kind of knowledge no one else is likely to have and it helps shape the future of the product. It gives product managers a unique positioning rather than being poor versions of other roles.

Stuff I wrote

Three ways for product managers to think about AI – AI in the market, AI as a tool, AI in products.

Product strategy workshop – A broad outline of a workshop for product teams to get started with developing a product strategy and using OKRs to get feedback on whether it’s working.

How I think about epics, features and user stories – They can be thought of as different types of things that are interconnected rather than as the same type of thing in hierarchical relationships with each other.

Towards a product topology for universities – Products are the things the university provides, not the things provided to the university by IT teams.

What I want from a product management tool – We don’t need another workflow management tool. We need a tool that assesses opportunities, aligns stakeholders, makes bets and analyses user behaviour to report on outcomes.

Analysing how a team spends its time – How do we know if we’re spending the right amount of time on the right things? In modern knowledge work, meetings often are the work, and so having a method for analysing how a team spends it’s time is important for optimising meetings.

Success state roadmaps – Attempting to express what we’ll see if we’re on the right track to success. The more specific each success state, the easier it is to know if the team is on track at each measurement point in time.

Escalators and mazes – We can use the metaphors of ‘escalators’ and ‘mazes’ to think about the two different types of products. Escalators take users from one place to another. Mazes keep users within the maze. Knowing the difference helps us design products with greater clarity and coherence, measure the right things and align the product with it’s business model.

Getting agile governance right – Three things are needed; showing work in progress, educating stakeholders, and building feedback mechanisms.

Books I read

• Think big, act small
• Managing and organisations
• Pitch
• Product in service
• How to measure anything
• Real world agility
• The Service Organization
• The product-led organisation
• Solving for value
• Building AI powered products
• Impact-first product teams
• Team topologies
• Persuasive technology
• The social brain
• Generative AI and education

Books I bought but haven’t read yet:

• The empowered manager
• Making the matrix work
• Kill bad meetings
• Speed lead
• Diffusion of innovation

Most viewed posts

1. Case study on Amazon’s approach to innovation and competition in the knowledge economy – 3,430
2. Systems thinking for product managers – 2,485
3. What’s the difference between a roadmap and a delivery plan? – 1,310
4. Microsoft Planner vs. Trello – 1,032
5. Schmenner’s Service Process Matrix – but for charities – 731
6. Four principles for great teamwork: communicate, collaborate, contribute, coordinate – 544
7. What’s the difference between a delivery manager, a project manager and a scrum master – 411
8. What’s the difference between product manager, project manager and delivery manager? – 287
9. From good ideas to social good: How charities approach innovation processes – 286
10. What’s the difference between a Prototype and Pilot? – 258

Doug Belshaw answered Steph Ango’s 40 questions. Here’s mine for 2025.

1. What did you do this year that you’d never done before? Start with a hard one, why don’t cha. I think there were probably lots of little things but nothing big stands out.
2. Did you keep your new year’s resolutions? Kind of. My new year’s resolutions are pretty much always centred around my three areas of focus: contributing to for-good digital transformation, getting an effective education, and living an intentional life. So, all the things I did this year such as starting an MBA (effective education) and maintaining my runway (intentional life) are keeping my new year’s resolutions.
3. Did anyone close to you give birth? No.
4. Did anyone close to you die? No.
5. What cities/states/countries did you visit? Hardly went anywhere, just London.
6. What would you like to have next year that you lacked this year? More exercise. It’s always the first thing I drop when things get busy.
7. What date(s) from this year will remain etched upon your memory, and why? Can’t remember any dates in particular and I’m good with that because memorable dates are usually dramatic or traumatic and there’s been enough of that in the past few years.
8. What was your biggest achievement of the year? Pretty much everything I achieved either involved others or was a step towards something else, so nothing feels like something I have achieved, but I’ll go with developing a clearer positioning of my role at work. I hope I continue to bring calm kind challenge to all the different things I get involved in.
9. What was your biggest failure? Not supporting people as much and as well as I should have.
10. What other hardships did you face? My hardest hardship this year was number 39. I’m fine with the stress of suicide attempts, police, ambulances, sleepless nights, unhelpful NHS teams, etc. The hard part is accepting that the help I can provide isn’t always the help that’s wanted or needed.
11. Did you suffer illness or injury? No, I’m pretty healthy as far as I know.
12. What was the best thing you bought? A little keyring torch. It helped me connect with a little boy when he needed it.
13. Whose behaviour merited celebration? One of the leaders I worked with this year showed inspirational levels of humility and self-reflection. That kind of thing isn’t celebrated nearly enough but seeing it stuck with me as something to aim for.
14. Whose behaviour made you appalled? I should probably say it was people like Trump and Musk but I have such low expectations of them that it’s hard to be appalled by their appalling behaviour, so I’ll say it was some of the NHS mental health team members who literally have the power to affect people’s lives and use that power without much consideration of how their decisions affect people.
15. Where did most of your money go? House. I track my expenditure and group it into categories for easy analysis so I know exactly how much I’ve spent on books, clothes, and on the house.
16. What did you get really, really, really excited about? I don’t think I got really, really, really excited about anything, but I was definitely excited by some of the things I’m doing at work and starting to study an MBA.
17. What song will always remind you of this year? I went to a Dermot Kennedy gig so it’ll probably be this one.
18. Compared to this time last year, are you: happier or sadder? Richer or poorer? Healthier or unhealthier? About the same. I judge how rich I am by my runway (how many months I could go without an income), which is about the same now as it was at the start of the year. I don’t have a means of judging happiness but feel as even-keeled at the end of the year as I did at the beginning. Health is pretty much the same although with better leading indicators (eating, sleeping, exercising).
19. What do you wish you’d done more of? Blogging. I used to blog a lot more and wish I had the time to do more of it. It’s where I explore ideas more deeply than I can in weeknotes and it helps me have a more well-thought-through position on things I talk to others about.
20. What do you wish you’d done less of? Wasting time on things that turned out not to have the effect I thought they would, but without perfect foresight, sometimes you just have to try things.
21. How are you spending the holidays? Just like every other day.
22. Did you fall in love this year? No.
23. Do you hate anyone now that you didn’t hate this time last year? No, same.
24. What was your favourite show? I don’t watch much TV so I’ll go with Survivorman, which is always my go-to escapist fantasy.
25. What was the best book you read? Probably Impact-first product teams. Mostly because of the confirmation bias.
26. What was your greatest musical discovery of the year? Didn’t have any.
27. What was your favourite film? Can’t remember watching any films so don’t have a favourite but was interested to see some of the stuff about the 50th anniversary of Jaws (which is one of my favourite films).
28. What was your favourite meal? Coffee cake and custard in a hospital visiting room.
29. What did you want and get? A hoodie. (I assume this is referring to Christmas presents.)
30. What did you want and not get? There wasn’t anything else I wanted.
31. What did you do on your birthday? Nothing much.
32. What one thing would have made your year immeasurably more satisfying? Spending time in wild places.
33. How would you describe your personal fashion this year? “Gone ‘till November”, which could have been written about my trousers because I pretty much wear shorts most of the year.
34. What kept you sane? Work. It gives me focus, intellectual challenge, and a sense of contributing to a larger purpose.
35. Which celebrity/public figure did you admire the most? None of them.
36. What political issue stirred you the most? Flags on lampposts. It’s a horribly scary, too-close-to-home show of right-wing power. Also, the stupidity of using St. George’s cross as a symbol to exclude people who “aren’t English enough” when St. George was from what is modern day Turkey.
37. Who did you miss? I didn’t really miss anyone, my brain doesn’t work that way.
38. Who was the best new person you met? Probably a delivery manager who’s really good at his job. Delivery management is one of those roles that can be done effectively in so many ways so it’s always good to meet someone who knows their way.
39. What valuable life lesson did you learn this year? You can take a horse to water but you can’t make it drink. Or, you can offer help but you have to accept that people don’t have to accept it.
40. What is a quote that sums up your year? “I expect next year to be a record-breaking year.” -Jensen Huang.

In product development, governance is essential for ensuring quality and problem/market fit of the solution. Governance should provide broad oversight of the wider organisational implications of the solution so that the team building the product can maintain their flow and focus.

In a traditional waterfall or stage-gated development process quality assurance and approval checks happen towards the end of the work. It makes sense if you’re optimising for efficiency as all the quality check governance happens when the development is as close to it’s live and finished state as possible. But it’s based on the assumption that it’s possible to know ahead of the development work all the possible considerations and implications, which approval checks can refer to and confirm met or not.

The agile perspective is that its not possible to know all those implications ahead of doing the development work and so the better approach is to get smaller feedback more regularly and respond to it more quickly. This is better than waiting until near the end because changes are easier to make whilst development work is in progress. This approach optimises for effectiveness where getting it right is more important than doing it quickly.

Getting agile governance right takes three things; showing work in progress, educating stakeholders, and building feedback mechanisms.

Showing work in progress

Working in the open is not a nice-to-have, its an essential part of agile governance.

Show and tells, weeknotes, public roadmaps, and regular discussions with stakeholders, are all part of working in the open. They are about showing progress, but they aren’t status updates, they are quality control. By showing work in progress regularly and prompting stakeholders to ask the right questions, product teams can make explicit any assumptions they have and clarify things they are unclear about.

For some teams, this is where agile governance stops (and fails). They show the work but stakeholders don’t know what to do with what they’ve seen. Teams can easily spot this by the amount and quality of discussion they have with stakeholders.

Educating stakeholders

Understanding the implications of what the product team is doing requires dedicated and widespread organisational knowledge.

A stakeholder is anyone for whom a change matters because it affects their ability to achieve their goals. They need to be able to think critically about what they’ve seen from the product team, to consider the implications on their area of the organisation, and to ask the right questions to clarify the impact. This doesn’t happen by accident. Stakeholders need to learn how to be an effective part of agile governance, and often it falls to product teams to do that.

Educating stakeholders means helping them be clear about which of their goals might be impacted by the product. If the product helps user’s self-serve, what are the implications for call centre capacity and workforce planning? A development team won’t have the knowledge to answers those questions but a stakeholder who manages the call centre might. But only if they come to a show and tell or read weeknotes with that question in mind.

Generally, stakeholders need to be explicitly told that their role is to understand enough about the overlap a product has with their area that they can spot implications that no one else sees. Once they’ve noticed implications they need a way to tell the product team and have confidence the they’ll be discussed and resolved.

Building a feedback mechanism

Product teams need to put processes and tools in place to collect, manage and communicate a response to stakeholder feedback.

All too often, stakeholder feedback is managed in an ad hoc way because it’s seen as a challenge to the product rather than an opportunity to achieve a wider and more coherent solution. But when teams and stakeholders understand that feedback is an important part of agile governance, and being able to do it effectively is the difference between a product launching without unexpected issues and it landing with positive impact.

Big public show and tells often aren’t the right forums for discussing the details of feedback, so instead teams should make it known among stakeholders who to speak to, how to get in touch, what kind of information to provide, how the discussion will happen and how long it’ll take. Those kinds of expectations should be the basics of stakeholder engagement.

Sometimes that discussion leads to development work, sometimes to a change in business process or providing additional information to someone. Sometimes its a big change but more often, and especially if the agile governance process is working well, it’s a small change caught early enough to be made without lots of consequences.

How to know it’s succeeding

When agile governance is succeeding, no one should notice. Perfect governance results in zero issues and zero rework, and we don’t notice what isn’t there. So we can only judge agile governance by its failure. If work goes live and causes issues, not just in the code but for other parts of the organisation, then governance failed. If that happens, run a retro with stakeholders to find out why and what you can do to fix it.

More thoughts from others:

• Tips on doing Show and Tells well
• The show and tell: what it’s for and how to do it right
• Running effective show & tells
• A decent hybrid show and tell set up
• Governance principles for agile service delivery

Metaphors enable us to use what we know about familiar thing to understand more abstract things. That makes them really useful tools for thinking about hard-to-define things like ‘products’.

We can use the metaphors of ‘escalators’ and ‘mazes’ to think about the two different types of products. Escalators take users from one place to another. Mazes keep users within the maze.

Knowing the difference helps us design products with greater clarity and coherence, measure the right things and align the product with it’s business model.

Escalators

Escalators help manage the flow of people. They help them get from one place to another with greater ease.

Government services, health and dating are escalator products. They succeed by getting their users from one state (untaxed vehicle, want to loose weight, single) to another (taxed vehicle, lost weight, in a relationship). They know that once they do, users will stop using the product. They might come back again if they find themselves back in the original state, but users would consider the product a failure if it didn’t help them make a change that meant they could stop using the it.

Escalators use success metrics like conversion rate and acquisition costs which tell how effective the product is at bringing users in and moving them through the product.

The business model behind these kinds products involves being the only one (government services) or having lots of marketing to attract new users (dating). And the value collection method (making a payment) is usually upfront as part of completing a transaction or onboarding.

Mazes

Some mazes lead a user along a single path, some have forks in the path that give the users choices about which way to go, but all mazes try to keep users in the maze

Social media, games, banking and video streaming products are mazes. Success is about keeping people moving around but not getting out.

Monthly recurring revenue, daily active users and lifetime value are the kinds of metrics that show success for mazes. They indicate how many users are staying in the maze.

Maze business models are often around collecting and monetising user data, so don’t always involve users paying to use the product (e.g., social media). Businesses that can get a money and monetisable data from their users win twice (such as video streaming).

Designing escalators and mazes

Neither of these types of products is inherently good or bad. Both types can have extractive business models and deceptive design patterns, just as both can have ethical business models and transparent design.

Thinking about products in this metaphorical way helps us be clear about how we design products to work effectively. If we’re creating an escalator we would avoid using techniques that try to achieve some kind of lock-in or rely on user data for income. If we’re creating a maze we wouldn’t design for immediate, one-off user outcomes, or have a business model that relies on early value exchange.

References

Edkins, J. History of Mazes and Labyrinths. 2008.

Lakoff, G., and Johnson, M. Metaphors We Live By. 1980.

Escalators. Wikipedia. Accessed 2025.

I’ve been thinking about how roadmaps align with product strategy. Often, the relationship relies on a lot of implicit knowledge to see how the two relate and so I wondered if there might be a way to make it clearer.

Before we get into that, first a few words on definitions and what we mean when we say “roadmap” and “strategy”. This is a few years old but I mostly still agree with it. A roadmap is not a delivery plan. It’s about goals, intention, and uncertainty, it doesn’t specify the work or when it will be delivered. And this is more recent thinking on product strategy. A strategy should express worthwhile problem to solves, hypotheses about how to solve them, and a way to know if the problem has been solved.

How strategy connects with different types of roadmap

The Now/Next/Later roadmaps fit nicely with the first part of the strategy; worthwhile problems. Janna Barstow, inventor of the Now/Next/Later roadmap, says it is focused on discovery and staying aware of customer needs and business opportunities. Product teams should use NNL when they need

Gannt chart-type roadmaps often show which feature is expected when, but because we’re product managers and not project managers we use them to express our hypotheses about how to solve the problem. We aren’t satisfied with merely getting features shipped, we know shipping features is how we run experiments and validate customer adoption. Product teams should use this type of roadmap when they need to communicate when they are making strategic bets.

But we don’t have a type of roadmap that expresses the third part of the strategy, how we’ll know if we’ve solved the problem. Or, using a different approach to strategy, Roger Martin’s ‘Where to play, how to win’, we don’t have a way to express what winning looks like and how we’ll know if we’re getting there.

Success state roadmaps

Success state roadmaps (I need a catchier name) attempt to express what we’ll see if we’re on the right track to success. The more specific each success state, the easier it is to know if the team is on track at each measurement point in time.

The roadmap reads left to right to imply a sequence – things on the right happen after things to the left – but it doesn’t explicitly mention dates.

Lets look at an example.

PKM

We’re working on a personal knowledge management product, and because it’s 2025 it has to use GenAI. Our (very simple for the purposes of this example) strategy looks like this:

1. Our worthwhile problem to solve is that users have information in multiple systems and no way to join it together so they can improve their recall spot patterns in their thinking.
2. Our hypothesis about how to solve the problem is that if they make all their information available to our AI, and add their own comments about that information, then we can analyse, organise and summarise information for them, and so make the information more available and useful.
3. We’ll know the problem has been solved when 75% of our users give our product access to 3 sources of information (e.g., email, notes, podcasts), and use our product to add their thoughts about that information, and access summaries at least once a week.

How does that look on a success state roadmap?

We can add our final success state to the end of the roadmap and then work backwards to define states of success that tell us we’re on track to achieve our final success. Because our final solved state mentions three different user behaviours we can break our definition of success into three outcomes to make it easier to see where the value is.

Outcome (user behaviour we’re trying to change)	State 1	State 2	State 3	State 4	State 5	Final success state
Give access to source information	20% of users give access to their podcasts when onboarding.	30% of users give access to their podcasts when onboarding.	40% of users give access to their podcasts when onboarding and notes app later.	50% of users give access to their podcasts and notes app when onboarding.	60% of users give access to podcasts and notes when onboarding and emails later.	75% of users give access to 3 sources when onboarding.
Add thoughts	10% of users add voice notes about podcasts they listened to.	20% of users add voice notes about podcasts they listened to.	30% of users add voice notes about podcasts or about information in their notes app.	45% of users add voice notes about podcasts or about information in their notes app.	60% of users add voice notes about podcasts, notes or email.	75% of users add voice notes about podcasts, notes or email.
View summaries	10% of users interacted with summaries of the podcasts each week.	20% of users interacted with summaries of the podcasts and voice notes each week.	30% of users interacted with summaries of either podcasts or notes, with or without their added thoughts each week.	45% of users interacted with summaries of either podcasts or notes, with or without their added thoughts each week.	60% of users interacted with summaries of any source or pattern analysis each week.	75% of users have interacted with summaries, either for information sources or for pattern analysis across all sources, each week.

How we define out success states shows things like we need to build trust with users so they’ll give us access to increasingly personal information sources, and implies the experiments the team could run, e.g., making onboarding quicker by only asking to access one source and then adding other sources later.

Breaking out success into three outcomes also helps us see where each reinforces the other. For example, we wouldn’t define the second step of ‘Add thoughts’ as having 40% of users adding voice notes because only 30% of users have given access to podcasts.

Where are we now and where do we want to get next

Having used our success state roadmap to define the steps to success, we also want to use it to show our current level of success and

Lets imagine it’s the end of quarter 1 and the product team is presenting their roadmap to senior leaders.

Green shows the success state we have reached. Getting users to give access to their information is going well, but getting them to view summaries of their information

Orange shows the success state we want to get in the next quarter. The team believes that the real value to users comes from viewing the AI generated summaries, so this is where they are going to focus most, but they’ll also try to increase the number of users adding voice notes.

Outcome (user behaviour we’re trying to change)	State 1	State 2	State 3	State 4	State 5	Final success state
Give access to source information	20% of users give access to their podcasts when onboarding.	30% of users give access to their podcasts when onboarding.	40% of users give access to their podcasts when onboarding and notes app later.	50% of users give access to their podcasts and notes app when onboarding.	60% of users give access to podcasts and notes when onboarding and emails later.	75% of users give access to 3 sources when onboarding.
Add thoughts	10% of users add voice notes about podcasts they listened to.	20% of users add voice notes about podcasts they listened to.	30% of users add voice notes about podcasts or about information in their notes app.	45% of users add voice notes about podcasts or about information in their notes app.	60% of users add voice notes about podcasts, notes or email.	75% of users add voice notes about podcasts, notes or email.
View summaries	10% of users interacted with summaries of the podcasts each week.	20% of users interacted with summaries of the podcasts and voice notes each week.	30% of users interacted with summaries of either podcasts or notes, with or without their added thoughts each week.	45% of users interacted with summaries of either podcasts or notes, with or without their added thoughts each week.	60% of users interacted with summaries of any source or pattern analysis each week.	75% of users have interacted with summaries, either for information sources or for pattern analysis across all sources, each week.

By the end of quarter 2, the updated roadmap looks like this:

Outcome (user behaviour we’re trying to change)	State 1	State 2	State 3	State 4	State 5	Final success state
Give access to source information	20% of users give access to their podcasts when onboarding.	30% of users give access to their podcasts when onboarding.	40% of users give access to their podcasts when onboarding and notes app later.	50% of users give access to their podcasts and notes app when onboarding.	60% of users give access to podcasts and notes when onboarding and emails later.	75% of users give access to 3 sources when onboarding.
Add thoughts	10% of users add voice notes about podcasts they listened to.	20% of users add voice notes about podcasts they listened to.	30% of users add voice notes about podcasts or about information in their notes app.	45% of users add voice notes about podcasts or about information in their notes app.	60% of users add voice notes about podcasts, notes or email.	75% of users add voice notes about podcasts, notes or email.
View summaries	10% of users interacted with summaries of the podcasts each week.	20% of users interacted with summaries of the podcasts and voice notes each week.	30% of users interacted with summaries of either podcasts or notes, with or without their added thoughts each week.	45% of users interacted with summaries of either podcasts or notes, with or without their added thoughts each week.	60% of users interacted with summaries of any source or pattern analysis each week.	75% of users have interacted with summaries, either for information sources or for pattern analysis across all sources, each week.

The team have succeeded in increasing the percentage of users viewing summaries but getting users to add voice notes is proving to be a much harder problem. They have to make a choice about whether to spend their time next quarter on that or to focus on doing more of the things that are succeeding, and using a success state roadmap shows where they are succeeding and helps them choose more rationally.

If they were following a feature-specific, time-bound delivery plan they wouldn’t know whether they are succeeding or not and would continue to ship features.

Summary

Success state roadmaps show us whether our strategy leading to a successful product.

By defining what we mean by success (part three of our strategy), and breaking down the states we expect to see (on the roadmap), we’ll have a clear connection between strategy and roadmap, and a clear view of which outcomes the team are most able to affect. We create a feedback mechanism from user behaviour to strategy which tells if our strategy is working or not.

Product teams can use their success state roadmap to communicate success and make agile, focusing choices about which success state to go after next.

Leaders can use success state roadmaps to review and adapt strategy and anticipate the final success state.

How do we know if we’re spending the right amount of time on the right things?

In modern knowledge work, meetings often are the work, and so having a method for analysing how a team spends it’s time is important for optimising meetings.

DORA identified how to make high-performing software development teams. If we could apply that kind of thinking to meetings, maybe we could answer questions about whether we are spending our time on the right things.

Here’s how…

Collect data

We need the numbers.

People

For the team we need to know:

• How many people are in the team?
• How many minutes does each person work per week?

That gives us the total time available for the whole team:

Name	Hours worked per week
Anne	1,800
Bobbie	1,800
Carlos	1,440
Davin	1,800
Eduardo	1,800
Frederick	360
Gino	1,440
Hilary	1,800
TOTAL	12,240

Meetings

For each meeting:

• How many minutes does a meeting last?
• How many people are in the meeting?
• And for our thematic analysis, what is the meeting about?

That gives us a table that looks like this:

Meeting	Theme	Minutes	People	Total time	Percentage of total
Weekly planning	Planning	60	8	480	3.9%
Focus	Development	240	5	1200	9.8%
Tuesday standup	Alignment	15	8	120	0.9%
Focus	Development	240	5	1200	9.8%
Expertise share	Learning	60	7	420	4.3%
Wednesday standup	Alignment	15	8	120	0.9%
Focus	Development	240	5	1200	9.8%
Thursday standup	Alignment	15	8	120	0.9%
Focus	Development	240	5	1200	9.8%
Show and tell	Governance	60	6	360	2.9%
Friday standup	Alignment	15	7	105	0.9%
Risk management review	Risk	30	5	150	1.2%
Progress update	Reporting	30	2	60	0.5%
TOTAL	7	1260		6735	55.0%

Analyse

Then we can group the meetings into themes and get a table like this:

Theme	Total time	Percentage of team time
Alignment	465	3.8%
Focused work	4800	39.2%
Governance	360	2.9%
Learning	420	3.4%
Planning	480	3.9%
Reporting	60	0.5%
Risk	150	1.2%

With our data analysed like this, now we can interrogate and interpret it.

Interrogate and interpret

How much time does the team spend on certain activities?

We can see that the team spends 3.9% of it’s time planning work for the week. Is that too little, too much or just enough? If we ask team members on a Thursday morning if they are still clear about what was agreed in the Monday morning, and they say that they are, then perhaps the team spends enough time planning.

Are we spending the right amount of time on the right things?

We can look at it the other way too. If we’re working on something pretty risky, is spending 1.2% of the teams total time on managing risks appropriate?

How much time is organised and how much is self-directed?

Meetings account for 55% of the teams time. This means the team has 5,505 hours a week of self-directed time. This comparison could be used as a proxy for trust and be analysed against the teams output to understand whether more self-directed time leads to more output.

Conclusion

Of course, knowing time spent doesn’t tell us anything about the quality of what happens in the meetings, but that’s a different problem to measure. Understanding how a team spends it’s time is important for improving meetings and the flow of work.

We don’t need another workflow management tool. We need a tool that assesses opportunities, aligns stakeholders, makes bets and analyses user behaviour to report on outcomes. We need a tool that helps to filter and focus.

Assess opportunities

Collect, collate and anaylse:

• Existing user behaviour
• New user research
• Market research
• Strategic priorities

Pattern analysis

Select information from research, perform thematic analysis to pull out themes.

Identify opportunities.

Make bets

Decide which opportunities to pursue.

Write hypotheses about potential outcomes (expected user behaviour and business results).

Align stakeholders

Using the opportunity analysis, create a business case, including:

• Value proposition
• Risk analysis
• Cost estimates
• Return on investment

Approval

Publish to stakeholders gor review and comments.

Approval from Finance for the investment, approval from senior stakeholders that the business case aligns to strategy.

Publish to roadmap (not a delivery plan that says when the solution will be live because we’re still talking about opportunities at this stage).

Validation

Decide how to validate.

• MVP
• Pilot
• Audience segment

Generate User Stories to send to other tools like ADO.

Track outcomes

Connect to analytics tools and hypotheses to report on user behaviour and how well it’s tracking against the hypotheses.

At UKEduCamp, Saul Couzens, Head of Research and Innovation IT at Sheffield University, said something like; “Products are the things the university provides, not the things provided to the university by IT teams”. It’s taken me months of thinking about this to start to understand what it means.

Universities provide lots of things. And how we divide and define these things, and then bundle them into coherent experiences is a complicated strategic choice (strategic in the sense of how it creates a competitive advantage). There’s no perfect topology for unbundling and bundling, but I thought it might be fun to try to map out some of the products universities provide, so here’s a few:

Product	Discover	Apply	Funding	Support	Lectures & seminars	Submission & assessment	Library	Credentials	Appeals & complaints	Network	Careers
Description	Find out about courses, funding, studying, etc.	Apply for a course.	Get funding for a course.	Get help to resolve a problem.	Get info about lectures & seminars	Submit an assignment, take an exam, get results	Read learning materials	Get certification for completed courses	Make a complaint or appeal a decision	Meet other students	Find out about careers & connect with employers
Hypothesis	If prospects can find all the information they need about a course and university, then they are more likely to make the right choice for them.	If applicants can apply for a course quickly and easily, then they are more likely to choose that university.	If applicants can secure funding for their course quickly and easily, then they are more likely to choose that university.	If students can resolve issues quickly, then they’ll have more time for studying.	If students attend lectures & seminars, then they will learn more and do better in assignments and exams.	If students do well in assignments and exams, then they are more likely to succeed in their studies.	If students access more learning materials, then they’ll learn more and do better on assignments and exams.	If students can provide proof of their educational attainment, then they’ll be more employable.	If students can get appeals and complaints resolved quickly and satisfactorily, then they are more likely to focus on their studies.	If students form relationships with other students, then they’re more likely to help each other progress in their career.	If students know more about industries and employers, then they are more likely to make good career choices.
Outcome	Prospects make an informed decision about choosing the university and course.	Applicants apply for a course.	Applicants get funding for their studies.	Prospects, applicants and students get issues resolved.	Students attend lectures and seminars.	Students submit assignments on time and attend exams.	Students access learning materials.	Students provide proof of credentials	Students get complaints and appeals resolved.	Students connect with other students.	Students make informed choices about careers.
Primary metric	Time taken to from first visit to start of course registration.	Time taken to complete application.	Time taken to secure funding.	Time taken to resolve case.	Time spent in lectures & seminars.	Number of assignment submissions & results on time.	Time spent engaging with learning materials.	Time taken for employers to verify credentials.	Time taken to resolve complaint or appeal.	Number of students connected to.	Depth of knowledge about a sector.
Channels	Web. Phone. Social media. Email. Agent.	Web. Phone. Agent.	Web. Phone. Agent.	Web. Phone. Email. Chat.	Web. Email. Video.	Web. Live.	Web. Chat. Agent.	Web.	Web. Phone.	Web. Social media. Live event.	Web. Live event. Email.
Capabilities	Social media marketing. Advertising. Email marketing. Content production & management. Enquiries. Telephony.	Course information. Registration. Telephony. CRM. System of record.	Website. Telephony. Forms. Data integration.	Website. Telephony. Case management. System of record.	Website. Video streaming. CMS. System of record.	Website. File management. Proctoring. System of record.	Website. Asset (physical and digital) management.	Access management. Website. System of record.	Website. Telephony. Forms. Data integration. CRM. System of record.	Social media and community management. Event management.	Data harvesting and analysis. Reporting. Event management.

Epics, features and user stories can have different relationships.

They can, and often do, have a hierarchical relationship where feature is a bucket to group user stories and epics are buckets for features. This means that, conceptually, any given user story only relates to one single feature and that feature can only be part of one epic. This relationship leads to two problems; either the product is developed as individual pieces not a coherent whole, and/or the mental models of those doing the work doesn’t fit with how we organise the work, both of which creates confusion. So, it’s not the best relationship.

I think there’s a better way to think about the relationships between epics, features and user stories. Think of them as different types of things that are interconnected rather than as the same type of thing in hierarchical relationships with each other.

So, that means…

Epics are long-standing capabilities that evolve over time to meet business and user needs. They are meant to provide context and set direction; that’s the job they do. Roadmaps for mature products might be organised by epics/capabilities to show how the product is developing in a balanced way across all epics. We can associate features with multiple epics to show how a feature is contributing to improving that capability, but an epic isn’t a bucket for a subset of features. And there isn’t a one to one relationship between a feature and an epic. Epics are never finished, which fits better to a product way of seeing the world.

Features are combinations of functionality. They can be added, changed or removed to improve the value a product offers. Sometimes a user might interact with a feature but not always. A single feature could contribute to multiple epics or just one, or none. That’s because features are independent of epics and do a different job, they are about how things work.

User stories are boundary objects. They are meant for passing information between different knowledge domains, such as user research, design and development, in a way that makes sense to all of them without translation. User stories working as boundary objects are flexible enough for different roles to get what they need from them and yet robust enough to maintain commonalities that all roles understand. This makes them far more powerful than just being another way to specify elements of a feature. And just like epics, user stories also don’t have a one-to-one relationship with a feature. Telling the story of a user isn’t just about how they should use a single feature because no one uses features in isolation. Understanding the story of the user isn’t just about what to build, it’s about how to affect the people who use the product. Good user stories refer to the past and future, they explain situations and motivations, they inspire possible changes in user behaviour.

Now, rather than epics being nothing more than buckets for features they are a distinctly useful thing in themselves. They show the capabilities of the product developing over time.

And rather than user stories being feature requirements-in-disguise they have a specific function. Their job is share knowledge between people and roles.

Epics, features and user stories are three different things, performing three different roles, that, when used in unison, help to make sense of work from different perspectives.