Framing your work as a hypothesis means no longer just thinking about the thing you’re making or building, but paying more attention to whether that work is achieving your intended goals and outcomes. This in turn means thinking about your work as a series of experiments you do with your users to learn if you’re on the right path. Instead of asking “Did we ship the shopping cart feature?” you ask: “Did we make it easier and simpler for our customers to buy from us?”
When done collaboratively, hypothesis-building is powerful at getting a team on the same page about what it’s doing and why. It also allows the team to be flexible — if one approach doesn’t result in the outcome you expected, you have implicit permission to change course and try something else.
How to do it
- As a team, identify and make explicit the problem you’re trying to solve. What goals or needs aren’t being met? What measurable criteria would indicate progress toward those goals?
As a team, write out the hypothesis for the work you want to do to address the problem(s) you’re trying to solve. You may want to write broad hypotheses at the outset of a project and more specific hypotheses each sprint.
Here’s a common way to structure your hypothesis:
We believe that doing/building/creating [this] for [this user] will result in [this outcome]. We’ll know we’re right when we see [this metric/signal].
- Identify the main entry points for the user need you’re addressing. This could be external marketing, the homepage, a microsite, or another page.
- Build or do the thing, and measure. If you learned something unexpected, then create a new hypothesis and change course so you can continue working toward your goals.
Examples from 18F
- Example from the Lean product design guide.
Applied in government research
No PRA implications. No information is collected from members of the public.