Product strategy workshop
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:
- Worthwhile problems to solve.
- Hypotheses about how to solve the problems.
- 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:
- 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.
- 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,
- 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.