Requirements and Hypotheses
Lean UX: Applying Lean Principles to Improve User Experience
In Lean UX, Jeff Gothelf and Josh Seiden outline the process which blends Agile software development (collaborative, rapid, and iterative development), Lean Startup (validated learning and objective measurement), and design thinking (collaboration with an objective problem solving focus).
Requirements versus hypotheses
For many teams, in many contexts, hypotheses are a more effective way to manage your work than requirements.
In the video above, Josh Seiden describes an early challenge he was given as a product manager by his boss: develop an internet mouse. The product ultimately failed. The initial hypothesis was not validated until the product was developed and brought to market.
Requirement: Create an Internet Mouse that people can use when surfing the internet on their TV from their couch.
Hypothesis: We believe people will pay for a device that makes it easier and more fun to surf the internet from their living room couches in front of the TV.
The problem with requirements is they take the thinking out of the design and product team
Because business owners express needs as “requirements”, the development team has no visibility into user and market needs. This results in “the business” doing the thinking and the design and engineering teams doing the implementing.
When you use a hypothesis instead of a requirement, you get all three legs of the stool involved: business, design, and engineering.
When you give a team problem, you engage their creativity.
Putting bounds on creativity
Designers are taught to follow their intuition. They want to create a mockup and throw it out into the world. It’s like dropping a stone in the pond, watching the ripples and intuiting the response. When one person is doing this, it’s hard for large teams because it is an internal, solitary process. A hypothesis allows you to give a team a creative mandate that has boundaries and lets them move forward together.
When to use requirements and hypotheses
Seiden gives a great definition of requirements versus hypotheses that mirrors the Lean Startup approach:
When you’re in production, building to a known standard, you want requirements.
When you’re in an environment of uncertainty, you want hypotheses.
Why are hypotheses better?
They are understood to be only provisionally true: in other words, they express assumptions that need to be tested.
Hypotheses are answers put forth in the spirit of a question.
Agile asserts that “working software is the primary measure of progress.” Lean Startup says “validated learning is the primary measure of progress.” Teams advance by asking good questions and working collaboratively on those questions.
Every design decision you make is a hypotheses and ultimately the market is going to test it for you. The question is: how long is that going to take? A full development cycle of 3 to 9 months is a long time to find out whether you made the right choice. If you can reduce that cycle, you can win. If you do it over and over again, then you pull the risk out of your product development effort. This is why learning and questions are important.
Hypotheses are a way to reframe requirements:
- Every decision you make about your product or service is a design decision
- Every design decision is a hypothesis
- Declare your assumptions and test them
- Involve the entire team in the customer feedback loop
What is a hypothesis?
A hypothesis is a “proposed explanation of the way things work.” It takes the form of “we believe that _____. And we’ll know we’re right when we see this signal: _____.” The second statement can break down further into “we will know we have succeeded when qualitative and quantitative outcome. This will improve KPI.”
In the case of the internet mouse, the team could say: “We’ll know that we’re right when: 1. People use our mockups without trouble; and 2. People offer to pay when we offer to leave the mockups with them.”
The hypothesis process
Replace requirements with hypotheses by:
- identifying assumptions
- Expressing assumptions as hypotheses
- Test the riskiest assumptions first
- Break down your hypotheses down into testable parts
- Use MVP concept to test your hypothesis
- Get out of the building
- Lather, rinse, and repeat
Declaring your assumptions
To get the team thinking about assumptions, ask:
What assumptions do you have about your customers, your product, or your market that, if proven false, will cause you to fail?
Next, probe more deeply for assumptions:
- Who is the user? Who is the customer?
- Where does our product fit into their work or life?
- What problems does our product solve?
- When and how is the product used?
- What features are important?
- How should our product look and behave?
- How will we acquire and sustain users?
- How will we make money?
With your assumption list in hand, test your riskiest assumptions first.
Testing your hypothesis
A minimum viable product (MVP) is the smallest thing that can be used to test your hypothesis. Build your product to validate your hypothesis.
Case study
Seiden offers an extended example of working through this process:
Problem: Our product installation process is too hard for our customer. It is preventing us from measuring customer behavior.
Requirement: Build an installer
Hypothesis: Our customers will value our product enough to install it.
Sub-hypothesis: They will install the product only if the installation process is easy enough.
MVP: Build a page that supports a concierge (human behind the scenes) installer. This MVP tests whether customers are interested in an easier installer. No software has to be build to test this hypothesis.
