# Simple strategies – version 0.2

Two additions to this version of my thoughts on creating simple product strategies:

- Strategies, plural. Not one big strategy, but lots of small simple strategies that make it easier to figure out what’s working.
- Capabilities to solve the problem. Thanks to Ian for this addition. He’s right, a strategy without the ability to deliver on it is useless.

So, four parts to simple strategies.

- A worthwhile problem to solve
- A hypothesis about how to solve the problem
- The capabilities to solve the problem
- A way to know if the problem has been solved

## A worthwhile problem to solve

This is where product managers spend most of their effort – finding and understanding problems and figuring out if they are worth solving. Those problems can be big or small, tame or wicked, organisational or customer problems. What makes the problem worth solving depends on the context but could include how many people it affects, how much they are willing to pay for a solution or how much it limits an organisation from doing what it wants to do. Without a worthwhile problem to solve, no strategy is going to create a successful product.

## A hypothesis about how to solve the problem

With a deep understanding of the problem and confidence that it’s worth trying to solve, a product manager can create multiple hypotheses for solving the problem. Testing and validating these hypotheses enables the product manager to hone in on the solution most likely to succeed. Getting to a single well-defined hypothesis gives direction about what to build in order to solve the problem.

## The capabilities to solve the problem

The product manager has to match what to build with whether the team can build it. Working with the team to figure out what they can build, they test feasibility. Not just feasibility for the technology, but compliance, security, accessibility, etc., to know the organisation and team has everything it needs to solve the problem.

## A way to know if the problem is solved

Product managers have to figure out how to know if the product they built has solved the problem. Often this is by understanding user behaviour and measuring whether the product caused a change in that behaviour, also known as achieving an outcome. The product also has to be scalable, financially viable, marketable, etc., etc. in order to solve the problem for lots of people at the same time.

Next… an example.