First coined in the mid 20th century, the term “speculate to accumulate” refers to the need invest (at some degree of risk) in order to make meaningful gains. In other words; roll the dice, take a punt, have a gamble.
This is a risky strategy for product managers, and if your gambling skills are anything like mine you’re far more likely to end up backing the three-legged donkey that never makes it over the finishing line.
However, this approach seems to be used time and time again when it comes to product development – blindly investing hundreds of thousands of pounds, if not millions, into products and services in the hope that some pay off. It’s like playing pin the tail on the (three-legged) donkey in a field, But it doesn’t need to be this way.
Sadly, I don’t have any secret formula to beat the bookies, but what I can share are some practical tips on how to ensure your products and services are more likely to succeed.
Understanding Lean
There are many excellent books and articles to be found on “Lean”. However, in my experience, most organisations haven’t grasped the concept; when I hear an organisation describe themselves as “Lean” I often treat it with a degree of scepticism.
I’ve formed this view as there’s often a chasm between understanding Lean and actually being lean. My personal favourite was a recent client who described themselves as Lean. I saw no evidence to suggest they were practising any aspect of Lean principles so I queried their definition of Lean. The response I received was “we’re delivering products on a limited budget and our teams are under-resourced”. It was a real head-in-hands moment.
Being Lean
For me, being Lean is a mindset, going deeper than the build, measure, learn paradigm that is frequently referred to. It’s the concept of employing scientific thinking to problem-solving. It doesn’t come naturally, but with practice, it becomes easier
It’s essentially a process whereby we establish what we think will happen, design and carry out experiments to test the theory, then observe what actually happens and learn from the results.
This is particularly applicable for product managers. There’s no need to guess the way to the end goal, building in a lot of assumptions as a result. Instead, we can use experiments to take conjecture out of the equation, using data to back up our decisions. This results in products and services that meet end-user needs, and ultimately it helps to avoid costly mistakes.
Identify Hypotheses/Assumptions
The first step requires a degree of self-awareness. How much do you really know about the problem you’re trying to solve? Do you know your customers? Do you understand their pain points? Will your solution actually satisfy their needs? How will it do this? What data have you got to support this?
You may have a great solution which in your mind is a sure thing, a dead cert. But it’s highly likely that your solution will be based on a number of assumptions and hypotheses.
You need to identify these assumptions and hypotheses and prioritise them in terms of importance. What needs to be true in order for your idea to be a success? What assumption, if incorrect, could kill your product?
- Will customers find your product/service useful?
- Is there a demand for your product/service?
- Are your customers willing to pay for it? If so, how much are they willing to pay?
- Will your product/service be profitable?
Design Experiments
The second step is to design experiments to help you validate whether your assumptions are correct (or not). The results of the experiments allow you to push your “limit of knowledge” to the next stage, identified in the above diagram.
The more experiments you run, the more you’ll know. The more you know, the more you can hone in on a solution that has a higher probability of success.
Strategyzer has devised a useful set of Test Cards which can help structure your experiments to extract the data you need.
There are four steps:
- Hypothesis – state the hypothesis/assumption you have made
- Test – outline how you will validate whether or not the hypothesis is true
- Metric – define what data you will measure
- Criteria – set a target to validate/invalidate the hypothesis
The test card should also capture how critical the hypothesis is to your solution, how costly the experiment will be to run, and how long the test needs to run in order to gain meaningful data.
Design multiple experiments to validate the hypotheses and assumptions you’ve identified.
Test, Test, and Test Again
Start running your experiments. Prioritise them based on the most critical hypothesis versus the cost/time to run the test. Essentially, you’re building a backlog of experiments. It’s probably better to start with cheaper, quicker experiments where uncertainty is high, and increase the amount you spend on experimentation as certainty increases. You could adopt the 2×2 prioritisation matrix to help with this.
Learn – Persist or Pivot
After each experiment, you will learn something new. Use Strategyzer’s Learning Cards to capture what you have learnt.
If the results of your experiment prove the hypothesis to be true – fantastic, now move on to the next experiment. If the results are inconclusive design another experiment and run it again. If your hypothesis is proven incorrect, it’s time to consider whether you need to create a new experiment to learn more or pivot your solution based on what you’ve learnt.
Only when you have validated your key assumptions and hypotheses should you start delivering your product/feature.
Adopting a lean mindset is a sure-fire way to help ensure more of your bets come in!
Source: Bizztor
