Category: Blog

Introduction

This is 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.

This workshop holds some assumptions about product management and product teams, including:

• Teams work in, or are shifting towards, an environment of high alignment and high autonomy. This means they are expected to figure out how to identify and solve problems that matter to users and the business and are not told what build.
• Product (in fact, any kind of) strategy is not about creating a to-do list of work. It’s about creating a guide for making focused choices.

Workshop logistics:

• Adjust the timings of each section to fit your team’s needs. If your team already has a grasp of the context they are working in you might spend less time on that. If there are lots of options open to , they might want to spend time refining them. If the teams wants to spend time agreeing what work to do, they can make that part of the workshop also.
• By the end of the workshop teams should be a) an understanding and method for creating an actionable product strategy, b) have identified their product strategy for the next year, c) have written an OKR for the first quarter to get feedback on whether their strategy is working.

Some things for product teams to remember as they go through the workshop:

• Embrace ambiguity – you’ll never know everything you might want to create a strategy but use what you do know and learn more as you go.
• Trust your expertise – you have lots of experience and expertise to fall back on, make the most of it.
• Pace over perfection – you won’t come up with the perfect strategy so it’s more important to get to something workable that you can improve later.

What is a product strategy and why product teams need them

In Thinking in bets, Annie Duke writes about the importance of understanding the difference between luck and skill in the things we achieve. Luck is all the things that happen which are outside of our control and skill is what we do with the things within our control.

Strategy is all about figuring out which things are within the team’s control and how to use those things to achieve goals.

Product teams are generally more successful when they have a strategy to help them focus on the things within their control.

A product strategy includes three things:

1. Worthwhile problems to solve.
2. Hypotheses about how to solve the problems.
3. A means of knowing if you’ve solved the problem.

This creates a loop that helps teams set an actionable strategy, learn whether it’s working, and improve it based on that learning. It helps to create product strategies that are fit for an uncertain world.

Worthwhile problems

The first part of creating a product strategy is choosing which problems to solve.

The problems have to be solvable and worth solving, which means:

• A large enough group of people are affected by the problem.
• The problem is sufficiently problematic for them to use your product to solve it.
• It isn’t a hugely complex or wicked problem that is beyond solving by a single product team.

And of course, the problems a team chooses have to be ones the organisation would want them to solve. So, the more teams understand about the context and environment they are working in, the better informed their strategy will be.

Example: The product team for an online bookshop are seeing a decline in traffic from paid advertising and organic search for mainstream books, which leads to a drop in sales. They suspect it’s because people go straight to Amazon to search for well-known books rather than starting with a search engine.

Exercise:

1. Spend time talking about the industry and market you operate in; organisational priorities, goals and objectives; user research and audience insights; what competitors are doing; what technology trends might affect user expectations, etc, etc. The more context the team can draw upon, the better they’ll be able to spot the right problems.
2. Use this knowledge to identify the problems in . The problems can be expressed quite generally, e.g., we’re losing market share to a new competitor,
3. Filter down all of these problems into those the team thinks they can and should try to solve. The team knows their own skills and capabilities they are the best ones to choose the right problems. Getting to a single, most important problem we’re facing right now is best. Sometimes teams choose a few problems, but remember, strategy is about focusing.

Finding worthwhile problems to solve is the most important part of product management. It isn’t easy, but it really matters. It’s far too easy for teams to spend lots of time and money solving problems nobody cares about, or no one will pay for, or that are solved in better ways by competitors.

Hypotheses for solving problems

The second part of a product strategy is coming up with hypotheses for solving the problems.

Hypothesising doesn’t mean thinking of solutions, of the actual features to build. Instead, it means thinking about what parts of the product could be changed to affect what user behaviour, and expressing them as “If [we change this part of the product], then [users will do this new behaviour], and we’ll achieve [this business result].

But before team’s can come up with hypotheses, they have to identify the parts of the product it’s within their control to change. We call them levers because they give the team leverage to affect changes to user behaviour.

Strategic levers

Strategic levers are the different parts of the product a team can change to make a product succeed or fail. The best way to think about levers are as the features and functionality associated with different types of user behaviour such as onboarding, purchasing or using a feature. For some product teams the levers might include pricing and marketing, whilst for other teams those things might be responsibility of other teams. The important thing is to figure out which levers/epics/capabilities/whatever-you-call-them are within the control of the team so they can increase or decrease their focus and investment in each lever. For example, deciding to optimise the onboarding journey to get users to an aha moment more quickly, or increasing usage of a new feature.

Once a team has figured out all the levers their product has, teams can select the levers they pull. In an ideal world product teams would have the investment to pull all levers to their maximum. But that is never the case, and so teams have to make strategic choices about which levers to focus on and how much to pull them. If we wanted to explain what a product strategy is, we could say it’s a choice about which of all the levers a product has, the ones they are going to pull, and by how much.

Example: The online bookshop product team identify their levers as: Search, book listing, customer accounts, basket & checkout, payment processing, sales data, stock management, email notification. Things outside their control include marketing, dispatch and delivery.

Exercise: Write your list of levers. Make sure they are things within your team’s control. If it helps, think of the user journey and the distinct parts of the product users interact with.

Writing hypotheses

A hypothesis is an idea or explanation for something that is based on known facts but has not yet been proved. The ‘not yet been proved’ part of that definition is what makes a hypothesis different from a guess. A hypothesis has to include a way to prove it is right or wrong. This is how we know our work is having impact.

If we didn’t do anything and the user behaviour changed, we’d know it wasn’t us that caused the change. If we made some changes on the product and the user behaviour didn’t change, we’d have disproved our hypothesis. Ideally, we’ll prove our hypothesis by seeing the change in user behaviour we predicted as a result of the changes we shipped.

We write hypotheses as if-then statements to make the cause (the ‘if’) and effect (the ‘then’) clearly separate from each other, e.g., “If [we change this on the product], then [users will do that], and we’ll achieve [this business result].” These statements express the solutions we think will solve the problems we identified earlier.

Example: The online bookstore product team know they can’t compete with Amazon on selling mainstream books, so they choose to focus on specialist books. They write their hypothesis as, “If we list specialist books, then people searching for books on niche topics will find us, and we’ll increase sales”.

Exercise: Write a hypothesis about what could change about the product to tackle one of the problems identified earlier, what user behaviour you’d expect to change, and what business result that would achieve. Discuss and refine until everyone on the team understands the hypothesis.

Knowing if we’re succeeding

The third part of a product strategy is the feedback loops to tell the team if their strategy is working.

OKRs are designed for getting feedback on a team’s strategy so they know if it’s working. Other goal-setting methods can be used for other things, but OKRs give teams the best means of being outcome-focused and knowing they are having strategic business impact.

Outcome-focused product teams take Josh Seiden’s definition of outcomes as a change in user behaviour that drives business results. The only reliable measure of success for a product team is the ability to change user’s behaviours. If a team can’t do that, they can’t achieve any objective.

OKRs are made up of Objectives and Key Results. An objective is the business goal the team thinks will take them a step towards delivering on their strategy. Key Results are the user behaviour change the team is seeking. Use the ‘who does what by how much’ method to define your key results.

OKRs are usually set every three months, giving teams four periods of focus a year. But they can be set for any time span. The faster a team is at building and shipping, the shorter the focused timebox needs to be for them to achieve an objective.

That timebox is about focusing on a strategic objective. It isn’t a delivery deadline. Teams may be able ship a new feature in the first month and choose to do non-strategic work or choose another strategic objective. Or the team might take 8 months to ship the changes they think will affect the objective, but they have 3 months of focusing on the strategic work.

OKRs don’t specify the work. This gives the team options for how to achieve the objective without having to change the OKR if one option doesn’t work.

OKRs are written by taking the hypothesis the team wrote earlier and breaking it down into their assumptions that need to be validated. The objective is a business goal that represents a step towards solving the problem. If the team can’t achieve this objective, they should take this as an early signal that they aren’t going to prove their hypothesis and solve the problem they set out to. Key Results are set by thinking about the change in user behaviour the team would see if they had achieved the objective. These measures can be qualitative or quantitative.

Example: The online bookshop product team decide that for the next three months, their objective is to “Increase stock of specialist books“. They express their key result as “Customers who have previously purchased specialist books [who] from us are willing to sell them back to us [does what] at much lower price than they paid [how much].”

Exercise: Write an objective and key result for one aspect of the hypothesis that the team thinks needs to be validated, that the team can focus on for three months. Express the objective as achieving something of value to the business and that is obvious whether it has been achieved without to much measurement. Express the key result as “who does what by how much” so that it is focused on measurable changes in user behaviour.

Conclusion

Talking about your strategy

To stop a product strategy being nothing more than an intellectual exercise that stays in a document, to make it real and actionable, teams need to be able to easily remember and talk about their product strategy.

Teams need to be able to express their strategy as a statement that makes it clear what problem they’re solving, how they think it can be solved, and how they’ll know if they’re right. It could be something like, “We’re focused on [objective] by changing [strategic lever] because we believe it can affect [problem], and we’ll know we’re right if [who, does this behaviour by that much].

Example: The online bookshop team bump into their CEO and she asks them what they’re working on. Without hesitation they say, “We’re focusing on giving customers a way to sell their books to us because we think it’s the most cost-effective way to increase the range of specialist second-hand books we have in stock so we can build a reputation as the go-to book seller for niche titles”. The CEO is impressed that the team connects what they are building to the business impact they want to have.

Exercise: Write a strategy statement that includes the worthwhile problem, a hypothesis for solving it and how you’ll know if it’s been solved. Test it with colleagues to check it’s easy to understand. Practice saying it until everyone on the team knows it by heart. Put it in presentations and show and tells. Get it in front of as many people as possible as often as possible.

Doing the work

Now comes the hard part. Putting your strategy into action, deciding what work might change the product in the right way and measuring user behaviour to find out if you were right.

Teams might have lots to do with stakeholders to clear the way for this new work, setting up instrumentation, measurement and analysis, etc., before they can even get to the actual work.

Once teams are able to get on with their strategic work, they’ll need to decide how to approach the work. Is it possible to run experiments that get feedback from user behaviour without having to build new features? Or do they have to deliver complete solutions because users have high expectations.

Example: The online bookshop product team builds a form that allows users to access the book listing functionality to search by title, author, edition, etc., the book pricing calculator to get a price, and the warehouse dispatch system to generate a postage label. They look through sales data and come up with a list of previous customers who have bought specialist books and ask the marketing team to email them about selling their book. They know the warehouse team will have to manually process payments but they decide this is the quickest way to validate user’s will actually sell books back to them so they can increase their stock of specialist books.

Exercise: Choose how to approach the work. Can the team run experiments to quickly get feedback from user behaviour (This doesn’t have to be part of the workshop).

Evolving product strategy

Product strategy should evolve as quickly as the problems users are facing.

At least annually, but sooner if the current hypothesis is disproved, teams should review their strategy. This means looking again at the problems, deciding whether to continue solving the current problem or move onto a different, perhaps new, problem. And working through their hypotheses about which levers might help solve the problems, and how they’ll get feedback on user behaviour.

Example: After the first year, the online bookshop product team have proved their hypothesis correct. They found that previous customers do want to sell their books, they improved the user experience and started marketing it as a standalone service which increased the stock of specialist books and increased sales. Now they need to review their strategy to decide whether they’ve solved the problem they started with and should pick a new problem.

Exercise: Plan another strategy workshop.

Whether you believe a utopian or dystopian vision of the future of AI, or subscribe to the normal technology hypothesis, AI is the undeniable latest revolution facing humanity. Yes, AI has been around in various guises for decades, but there are two things that make AI different to any previous technology revolution that we’ve faced, from the invention of the printing press to the internet.

The first is that AI is a general purpose technology, a bit like electricity. This means that it has broad application. You can use it to do lots of different things. As Tristan Harris put it, when you make technological progress in nanotechnology, you only make progress in nanotechnology. But when you make progress in intelligence, you make progress in every field of human endeavour. Electricity changed manufacturing, transportation, communication, etc. AI is changing it again and changing things electricity didn’t.

The second is that the twenty-first century is the first time in human history where data and technology are so interwoven into our lives, that a general purpose technology like AI will effect every single aspect of everything that goes on in society.

Together, these two factors – wide-sweeping change and interconnectedness – create the backdrop for the discussion on being AI-first.

As a wide-sweeping force for change across society, now and into the future, AI has to be considered from every possible perspective. That means considering economics & productivity, ethics & inequality, technology & data, philosophy, history, anthropology, power & politics, art & creativity, energy use & environmental impact, psychology & sociology, academics and human advancement, ownership & responsibility & rights, and so many more perspectives than I can list.

If you want to call yourself AI-first then you need to have considered what AI means from all of these perspectives.

You can’t speak about being AI-first and still have a narrow perspective on AI because that would deny the reality of it as a general purpose technology that will become increasingly interwoven into every aspect of society and every branch of human endeavour.

If you’re a CEO using the term to justify lay-offs and increase shareholder confidence, then you’re just playing the same old game, you aren’t being AI-first.

So, if AI does become normal technology (which personally I think is most likely) and doesn’t lead to the annihilation of the human race or a golden age of peace and abundance for all, then it will inevitably reinforce the inequalities of how society works today. The only way to change that is to change how we think about it.

I’d like an easy way to get someone to prompt an AI without having to give them the entire prompt to copy and paste.

My idea was to use a short prompt like “Go to this web page and follow the instructions: https://rogerswannell.com/follow-these-instructions/”, and then have the full prompt on the web page.

So I did a quick experiment by adding a simple instruction to a page on my website and giving six of the major AI chat tools the prompt telling them to go to the webpage and follow the instruction.

1. ChatGPT didn’t get that it was being asked to follow the instructions and tried to get me to follow them.
2. Claude couldn’t browser the internet so had no chance of working.
3. Copilot said it couldn’t follow instructions on a web page, which I guess is fair enough for an internal tool as it should prevent prompt injection, but it’s unfortunate as this is one my colleagues will be using.
4. Gemini didn’t recognise what was on the webpage as instructions
5. Deepseek couldn’t access the internet but offered to guide my through the instructions.
6. Perplexity was the only one that got it right, and it even added a smiley.

So, looks like prompt shortcuts aren’t going to work. Back to the drawing board.

Takeaways

Product management is becoming more responsible for business success and revenue. 

The Product School CEO shared The Value Stick and talked about how product management is involved in protecting margin by increasing willingness-to-pay and reducing cost. Vinay Ramani, CPO at Tide, shared his playbook for market-first innovation and how they expanded into new markets by relying on local knowledge and separating from their established approaches before bring successful things into their core business later. 

AI in product management, products and organisations 

AI was definitely a theme, as you might expect. Lots of organisations are trying to figure out how they should use it. The trend seems to be in using AI behind-the-scenes to make organisations more efficient than creating new opportunities or value by building it into products. The Financial Times considered whether AI would change their core mission or support elements of their existing business and landed on the latter, with journalists using AI to make their research more efficient. 

Everyone is modernising, migrating or replatforming 

Ok, maybe not everyone but organisations you might expect to have a modern tech stack still struggle with how the tech keeps pace with the rate of change in the business. It was interesting to hear how TIER Dott, a company that rents electric bikes and scooters, managed bringing together two platforms and apps into one following a merger, and how Mastercard introducing SAFe to help them manage legacy tech platforms failed. 

Talks

Videos of the talks.

• Augmenting Your Product’s Value Proposition with AI by Debbie McMahon, CPO at Financial Times 

• The Future of Product in 2025 by Carlos González De Villaumbrosia, Founder & CEO at Product School 

• Product Localisation Playbooks for International Expansion by Vinay Ramani, CPO at Tide, Ex-Meta, Google, Uber 

• Product & Culture Integration After M&A by Pénélope Carlier, VP of Product at TIER Dott 

• Killing SAFe, Safely: Breaking Bureaucracy to Unlock True Agility by Simone Paul Tamussin, CPO at Mastercard Gateway 

• Partnering with AI Agents to build Stronger Teams and Smarter Products by Christine Itwaru, VP of Product at Beamer Userflow; Sally Fuller, Head of Mobility Products at BT; Susanne Jones, Senior Partner & Customer Transformation Leader at IBM and Sang Ha Park, AI Agent Workforce Leader at Sendbird 

• Scaling & Monetising Marketplaces by Carlos González De Villaumbrosia, Founder & CEO at Product School and Tanya Cordrey, CPO at Motorway. 

• Practical AI Use Cases for Product Leaders to 10x Impact Today by Dave Killeen, VP of Product at Pendo 

• Don’t Leave Money on the Table: Optimising Payments to Reduce Churn by Chetan Pandya, SVP of Product at DAZN 

• Streamlining Product Operations for Category Expansion by Sam Hancock, VP of Product at Deliveroo 

As a product manager, I think about AI in three ways: AI in the market, AI as a tool, AI in products.

AI in the market

Understanding how AI is affecting the market you operate in is essential. It’s a must. As with an emerging tech, product managers need to be watching how the tech is developing, what use cases come out and how organisations use it to meet those needs.

The introduction of AI is mostly ‘technology push’ which means it’s a solution in search of a problem, but also means that it’s widely applicable to lots of problems. If we believe even a small part of the hype, we can expect AI to change every industry and so affect every person’s life in some way. It’s more of a question of when and by how much, rather than if. So as a product manager, even if you don’t work in ecommerce or healthcare or fintech, your users are being affected by AI used in those sectors, and it will change their behaviour and expectations (just like the internet and mobile devices did) for your sector and product. Understanding and getting ahead of the trends is part of the job.

AI as a tool

Using AI as a tool means using it to be more efficient in what product managers already do. I’ve heard it said that “AI won’t replace you, but someone using AI will”. Again, when, not if. Can you imagine working as a product manager and not using that new-fangled email for communicating? It won’t be long until we think of AI in the same way.

Product managers can (and increasingly, should) use AI to write user stories or create prototypes or summarise workshop notes. Current thinking seems to be that AI isn’t reliable enough to be used without a human-in-the-loop, so as that human, products managers have to exercise the kind of critical thinking they would is other areas of their work. Its AI as a tool, not AI as an avatar/assistant (yet, but it’s coming), and a bad worker blames their tools.

AI in products

Using AI in products relies on product managers asking, “does it solve a worthwhile problem?” In the rush to find the problems technology push allows, adding AI into a product without that problem being worth solving could be wasteful but there are advantages to exploring ambiguous spaces and building an organisation’s capability for the future.

Product managers could be discovering worthwhile problems in two complimentary ways at the same time.

Firstly, testing hypotheses about user adoption, even if that is done quite bluntly by plugging an LLM into the product to see if anyone uses it is a completely viable approach given the state of the market mentioned above. There are other ways to understand user adoption, of course, but it’s important to understand that what doesn’t work today might work next year because of how user expectations will be quickly changed by other organisations using AI.

At the same, story-telling about the possibilities, building the case for investment, and creating longer-term technical capability for using AI as part of the product tech stack are all good things for productbmanagers to be doing. As well as, or instead of, surfacing AI to the user as part of the interface, it can include using AI to make predictions, analyse images, automate proceses with uncertain outputs, etc., etc.

It is also for product managers to balance the opportunity with the risks.

Product managers could be doing supplier due diligence, data protection and information rights assessment, figuring out an IP protection stance, analysing the total cost to run, assessing the risks, understanding ethical concerns about privacy and bias, and environmental impact of AI’s use of energy and water, and all the other things that come with introducing an emerging technology to an organisation, their product and their users.

That’s my current thinking on how product managers can think about AI. It’ll probably change, but for now I’d say product managers must be understanding AI in the market, should be using AI as a tool, and could be introducing AI to their products.

Thanks for the inspiration, Olu.

In 2025, I hope to:

1. Run more
2. Learn something new
3. Change my mind
4. Support my colleagues better
5. Keeping blogging
6. Give blood
7. Spend less time on social media
8. Read lots more books
9. Set myself some fun challenges
10. Talk to more people
11. Eat better
12. Help the right people get the recognition they deserve
13. Ask for help
14. Get even more organised and better at tracking, reviewing and improving my productivity
15. Have more focus on fewer things
16. See positive progress through the permacrisis
17. Get rid of more possessions
18. Maintain a twelve month runway
19. Care more, but attach less
20. Lead better, not more
21. Get stronger
22. Understand responsibility
23. Donate to charities
24. Fix a few things
25. Have more impact on the things that matter to me

Most interesting ideas I explored

Is it a product or service?

Had a few chats and thought quite a bit about the definitions of product and service, mostly on the assumption that they are different things. In the past, products and services definitely had different definitions, but nowadays the differences are often hairsplitting. So, until anyone can provide a robust definition for how products and services are different things, I’m saying they are the same thing seen from different perspectives.

Product or service

Who defines things in organisations matters. In my experience, if service designers do the defining, they tend to create a hierarchy where ‘the service’ is the big thing that spans the entire user experience and ‘products’ are the pieces of tech a user interacts with at each step as they go through the service. This implicit organisational power dynamic (kind of Conway’s Law) and misunderstanding that product doesn’t equate to tech, doesn’t lead to good, equitable, or useful definitions.

I’ve written before about how I think product managers and service designers can work together, so in a world where a service and a product are mostly the same thing, it doesn’t make sense for these roles to have mutually exclusive responsibilities, but instead to have complimentary perspectives that define and create better products/services.

Product or project

A product is a product if an organisation chooses to treat it as a product, and the best way to decide is to look at the problems it’s tackling. If the problems are well-defined, stable, and have predictable solutions, you don’t need product thinking or the skills a product team brings in tackle uncertain problems, and so don’t treat it as a product, treat it as a project. If the problems are new, unknown and the potential solutions are uncertain, then a product team with the skills to apply product thinking are a good way to tackle those problems, and so the organisation should treat those problems as a product.

Product or tech implementation

Differentiating between a product and technology implementation is much easier. If you’re working with hypotheses, discovering user problems, and delivering solutions iteratively, then you’re probably treating the work as a product. If you’re working with an accepted business case, stakeholder requirements and delivering features, then you’re probably implementing some tech.

Either way is fine, the important thing is to pick the right approach.

The future of product management

There have been so many boringly mediocre social posts about the future of product management being all about AI this year. I mean, look around. If that’s the best future you can envision, you clearly aren’t paying attention and probably shouldn’t be working in a role that involves having a wide perspective.

If product management is about navigating uncertainty and ambiguity, then the future of product management should consider the largest and most pressing cause of uncertainty; the state of the global economy (how it’s affecting organisations and what it means for the value product managers provide), climate crisis (how product management can help organisations stay within planetary and societal boundaries), the aging population, wars, energy and food insecurity, etc., etc. All of these create a permacrisis that should inform the future of product management.

And if anyone thinks that such big things are outside the scope of product managers, consider that how we think about disruptive innovation and growth now is a result of Schumpeter, Keynes, etc., and economic policies from the 1930’s that attempted to tackle the great depression and effects of World War I.

Cross-functional teams

I’ve explored a few different thoughts about cross-functional teams.

Truly cross-functional teams need wider remit

Truly cross-functional teams need the influence, authority and remit to affect goals, people, process, structure, technology and products/services. This idea comes from reading more about socio-technical theory, which introduced the idea of cross-functional teams and basically says you can’t treat the people side of an organisation differently than the technology side, they have to be designed to work together.

Unfortunately, most cross-functional teams usually only have the remit to make changes to tech, not as aspects of a socio-technical organisation. Maybe it’s a problem of focusing more on the ‘team’ part of ‘cross-functional teams’ and less on the ‘cross-functional’ part that makes us think it only needs to be within the boundaries of the team. Or maybe it’s another case of an idea that was designed to disrupt the status quo being co-opted into reinforcing existing power structures. Who knows.

Cross-functional teams should have regular contact with users

Internet-era cross-functional product teams work in an open system that is constantly changing and they have to respond to those changes. Industrial-era teams work in a closed system, meaning they aren’t affected by things changing out there in the world. One of the best ways for cross-functional product teams to know about changes is to have regular contact people who’s behaviour shows the change. Things like insight reports on customer behaviour, whilst useful, distance the team from the changes users are going through. They make an open system behave like a closed system, which reduces a team’s ability to respond to change and achieve outcomes for users.

The problem with professions

But cross-functional teams aren’t perfect. Professions exist to tackle a gap created by the move to cross-functional teams, but they in turn create a coherence problem for people facing different approaches that result. There must be a better way to provide a complete employee experience within cross-functional teams.

Decision stack

Spent some time understanding and critiquing the decision stack. The stack has Vision at the top and Strategy the second step down. Strategy breaks out into a number of Objectives, each of which in turn break down into Opportunities to explore to find ways to achieve the Objectives. At the bottom of the stack is Principles.

The different layers interact in two ways; the how and the why. How flows downwards, so Strategy says how to achieve the Vision and Objectives show how to achieve the Strategy. Why goes upwards, so Opportunities are selected because of the Objectives, which were chosen because of the Strategy.

The decision stack is a useful way to bring more coherence to the often vague and amorphous product work, but like every other framework, it says nothing about the environment necessary to make it a success.

Onto some thoughts from this year…

Logic model

A product logic model explains inputs, activities, outputs, outcomes and impact with if/then reasoning to show how changing one thing affects another. It depicts the hypotheses product manager’s use in their work, for example, how adding a different output (feature) is expected to affect an outcomes (user behaviour). Should the logic model be in the decision stack, and if so where?

I think it should, and goes either between vision and strategy, if we want to order things by longevity, or between opportunities and principles, if we think it’s more important to show that it’s foundational and supporting of how all the things above will work.

Whether we show the logic model using north star metrics or impact mapping (a favourite of mine) or theory of change, the point is to help understand and show others which aspects of the product that are within our ability to change and how the change will lead to what outcomes and impact. It shows whether our Objectives are the right ones to be working on, it validates our Strategy, it’s the feedback that tells us if we’re achieving our vision.

Principles

Principles are funny things. They can be really useful in solid decision-making or be useless talk about nothing much.

If you think of your principles as foundational, then you’ll be deontological about them. That means you consider them universally applicable rules or guiding boundaries that you don’t cross. Whereas if your principles are nice ideas that you might talk about occasionally, then you’re more utilitarian about them. You think that the ends justify the means, so you apply a principle when it suits and not when it doesn’t.

Given that centuries of moral philosophy hasn’t been able to decide between the two, I think we can accept that neither of these approaches is wrong, and the placing principles at the bottom of the stack doesn’t give us an answer about how to choose. It visually suggests either approach; a foundation to build upon (deontological) or less important than the opportunities above them (utilitarian).

I guess the interplay between applying universally applicable rules or using principles when they suit is another of those things product managers juggle.

Product ontology

I tried to think about the ontology and epistemology of product thinking to give it some robust theoretical foundations. I didn’t get very far other than the idea that product work might be better approached as constructivist rather than positivist.

User research is constructivist

I think user research uses a constructivist ontology. So, rather than trying to reveal an objective reality, it seeks to show how people create and interpret their own reality. I’ve never heard user researchers talk about this (except this guy) or even cover an ontological position in a research report. That seems a bit of a shame as it sets out a position that counters the criticism of user research not being robust enough because of population size.

Product attribution

Product attribution models usually take a positivist ontological stance, assuming there is a single objective truth to be revealed and show how this feature lead to that increase in metrics. But, given that product work is about affecting user behaviour, and an outcome is a change in user behaviour, wouldn’t a constructivist ontology make more sense? It also fits better with user research. I need to think about what a constructivist log model and metrics would look like, but that’s for next year.

Things I changed my mind about

Talking to people

I’m a big believer in asynchronous communications, and talking to people never comes easy for me, but I pushed myself to talk more to team members and to meet people outside the org. Now I think conversation is the unit of culture change. The more people talk to each other, the more knowledge is shared. And in modern knowledge work, sharing knowledge is a competitive advantage.

AI

I used to think GenAI was going to lead to big changes in people’s lives and new business models for organisations. Now I think it’ll have a similar scale of impact on content creation as email did on communication, and that in most cases it probably isn’t worth the environmental impact. Machine learning analysis, on the other hand, has much more potential (if you have the data).

OKRs

I used to think OKRs were a rubbish. Now I think they’re a good technique for teams to align with strategy and a tool for organisational change. I even did a short intro training session for some colleagues.

Stuff I wrote

What’s the difference between a delivery manager, a project manager and a scrum master, because they often get confused.

Against the standardisation of product management, because it’s a bad idea for a discipline that is going through so much change.

How product managers and service designers work together, because it’s better to bring complimentary perspectives than opposite opinions.

Uncovering better ways… of being agile.

Team objectives and fast feedback: a better way to improve individual performance, because individual performance objectives make no sense in a socio-technical organisation.

Three reflections on ten years in charity product management.

Goals

I have three longstanding goals that I’ve used for many years to focus my roadmap. Here are some of the things I did this year to contribute to my goals.

Contributing to digital transformation for social good

Work

Joined the Open University as a lead product manager.

Went to UKEduCamp.

Joined the Product Leader’s group.

Continually developing my knowledge, skills and practice

Reading

Books I read:

• Wiring the winning organisation
• The service organisation
• The agile manager
• Design for how people think

Learning

I didn’t do much formal learning this year but learned and practiced a lot about working with people. I’m really grateful to those who helped me learn.

Writing

764 posts (including 52 weeknotes and 25 blog posts, the rest were notes and links).

68.4k words.

33.5k views.

Most viewed post written in 2024: What’s the difference between a delivery manager, a project manager and a scrum master with 255 views.

82.3% of visitors came via search engines, 8.2% from other websites, 5.7% from social media, and 1.5% via AI.

Leading an intentional life

Travel

My coastline trip was on hold for this year because I had more important things to do.

Finances

Runway isn’t as healthy as I’d like but I spent money on worthy things so I’m ok with that.

Health

Didn’t walk, run or swim much this year.

How to decide if you’re building a product or building a technology system:

• Are you creating something that will validate hypotheses about how to enable the organisation to move in an agreed direction?
• Are you deciding what to build based on dedicated discovery work to understand what problems users are facing?
• Are you delivering small, frequent, reliable releases to users and getting feedback on whether you’re solving their problems?

If the answers are No, then you aren’t building a product, you’re implementing technology. There’s nothing wrong with that. Implementing technology is necessary, but it’s better to be clear about what you’re doing and why, and treat it accordingly.

I’ve been thinking about how mental models relate to definitions (like ‘product’) which relate to artefacts (like roadmaps). It’s confusing and dissonance-creating to define a product one way and then create a roadmap in a different way. So, if an organisation defines it’s products as pieces of tech, then an outcomes-based roadmap is going to make no sense. Lining up artefacts, to definitions, to mental models might help create more coherence and understanding. So, I thought I’d start with mental model based definitions of products.

By tech

This is the usual thinking in lots of organisations: a piece of tech equals a product. ¯\(ツ)/¯

Pros – Intuitive mental model because it’s fairly easy to see the boundaries of the tech and what that means for user experience, etc. Aligns the capability of the tech with the expertise of those working on it. Features roadmap makes sense because it expresses changes to the tech.

Cons – It makes it almost impossible for a product team to be outcome-focused as a user hardly achieves their outcomes by interacting with a single piece of tech. It falls into Conway’s law, which means users across multiple products often don’t get the consistent experience they’d expect when going from one tech to another.

By outcome

A product is all the things necessary for a user to achieve an outcome, including tech, team capabilities, policies, processes, etc.

Pros – Most user focused way to think about a product. Offers greater flexibility in how to achieve an outcome as a change could be in policy, user interface, etc.

Cons – Limits how to structure teams to work on a product as there aren’t going to be that many outcomes. Measuring outcomes is hard, so teams have to rely on proxy measures.

By activity

I’m not sure activity is the right word but it fits well enough. I mean product managers being responsible for things users do like Payment, Notifications, Search or Onboarding.

Pros – Allows for a great deal of flexibility in how the activities are defined which makes it easier to add, merge and disband teams aligned with activities.

Cons – It can be a bit feature-led, which means teams need to communicate and coordinate to create a coherent product experience.

By goal

The goals would usually be metrics based, e.g., Increasing Daily Active Users or improving retention.

Pros – Product teams can experiment and implement across any tech or user experience to achieve their goal.

Cons – Requires coordination across teams to prevent one team from negatively impacting another team’s goal.

It’s easy to get confused about prioritisation. We often use that word when we mean other things. We should mean ordering things by relative importance, but sometimes we also mean the sequencing of those things. One word, used to mean different things to different people. And that’s where it causes confusion.

I think it’s clearer to separate how important something is from when you’re going to do it. And to make that separation even cleaner, we could prioritise the problems we want to tackle, and sequence the solutions we want to create.

Prioritising problems

Like all good product managers, we want to start by understanding the problems we want to tackle or opportunities we want to go after.

We want to know which are the most important problems, and to figure that out we might look at how many people have the problem, how affected they are, how much they need a new solution, etc. All this information helps us pick which problems to tackle and which not to. And that’s the point of prioritisation; choosing what to work on, not when to work on it. It’s the logic of ‘this, not that’, whereas sequencing is ‘this, then that’.

Sequencing solutions

Once we have the problems prioritised by importance, we can then sequence the solutions.

We want to sequence the solutions separately from prioritising the problems because there are different factors to consider. Now we need to think about team capacity, technical skills, dependencies on other systems, budgets and other organisational constraints, etc. These things don’t affect what problems we’ve prioritised but they make a difference to when we’ll be able to tackle them.

By thinking about problems and solutions differently we can avoid confusing how important a problem is from when we want to solve it. It helps us make better decisions about whether to tackle more important problems sooner or when to solve easier problems.