Problem statements was the last product management tool that I wrote about. Once you’ve defined and understood the problem(s) that you’re looking to solve, the next step is to validate ways to solve the problem. As a product manager, there’s a risk of jumping straight into solutions or features, without really evaluating the best way to tackle a problem.

I learned a lot from the “Lean UX” approach to things, as introduced by Jeff Gothelf and Josh Seiden. The key point to Lean UX is the definition and validation of assumptions and hypotheses. Ultimately, this approach is all about risk management; instead of one ‘big bang’ product release, you constantly iterate and learn from actual customer usage of the product. Some people refer to this approach as the “velocity of learning.”

What are assumptions? – When thinking about problems and solutions we often make a lot of assumptions. For example, I like how Alan Klement points out that when we create user stories there’s a risk of making lots of assumptions (see below). I believe that the biggest problem isn’t so much in the assumptions themselves but more in not validating one’s assumptions before designing a product or service. What I love about the “Lean UX” approach is that it exposes assumptions early on and provides a way to validate these assumptions early and often.

What are hypotheses? – Hypotheses are a great way to test your assumptions. A hypothesis statement is a more granular version of the original assumption and is formulated in such a way that it’s easy to test and measure specific desired outcomes:

You can use these hypotheses to test a specific product area or workflow. The key thing with assumptions and hypotheses is their focus on behavioural outcomes or changes, not just on the feature or solution in its own right. 

The other important thing I learned about assumptions is to validate your riskiest assumptions first. I’ve benefited enormously from using simple prototypes to validate risky assumptions such as “this feature will definitely solve my customer’s problem” or “customers will definitely pay for this service” before committing lots of time, money and effort to solving a problem.

What assumptions and hypotheses aren’t? – I’ve seen some people falling in the trap of treating assumptions/hypotheses as absolute truths. The whole point of having assumptions and hypotheses is being transparent upfront about educated guesses, unknowns or risks.

Main learning point: Working with assumptions and hypothesis is essential in my opinion. It’s all about risk management. Instead of building something for many months before getting any customer feedback, I’d always recommend identifying and validating your riskiest assumptions first, using an iterative approach to learn ‘early and often’.

Related links for further learning:

1. https://medium.com/the-job-to-be-done/replacing-the-user-story-with-the-job-story-af7cdee10c27#.7kn2clk0y
2. https://marcabraham.wordpress.com/2013/04/05/book-review-lean-ux/
3. https://www.uie.com/brainsparks/2014/05/21/josh-seiden-hypothesis-based-design-within-lean-ux/
4. https://medium.com/@mwambach1/hypotheses-driven-ux-design-c75fbf3ce7cc#.bk8p1zvky