Before the MVP: How to craft a hypothesis statement
Kickoff meetings are crucial for team alignment. They usually start with the pitch or vision and end with a populated product backlog. A lot happens in between the start and end points of a kickoff meeting as well as throughout the product lifecycle, but the success of any MVP all boils down to one guiding principle: the hypothesis statement.
The hypothesis statement is what you are setting out to test with your MVP. This statement will guide what you decide to build and not build in your first iteration of the build-measure-learn process. Hypothesis statements consist of four major components:
- Customer segment
- Success metric
In an effort to help identify these components for your startup, I’ve outlined a process we use at philosophie to help product teams collectively decide on a hypothesis statement. For startups, I recommend having the entire team involved in the process, assuming it’s three to six people. For larger organizations, I recommend having one stakeholder from each department, six people max. Having each team member’s buy-in towards the creation of this statement will align the team from the get-go and mitigate conflict throughout the MVP process.
Before we get started, I’d like to acknowledge that books like “The Lean Startup,” by Eric Ries and “Inspired” by Marty Cagan do an excellent job explaining why we should use lean methodologies. I’m going to assume you are already familiar with these topics and instead focus on how to apply these methodologies. That way you can take these learnings and apply them to your startup idea, next phase of feature development, or new internal project.
1. Customer segment: identifying customer segments and creating personas
Who are your customers? Where do they work or go to school? What are their activities? What are their pain points?
In it’s most basic form, a customer segment is a group of users with similar traits or characteristics, i.e. recent college grads, community leaders, or high school seniors. A persona is a representation of a user from a specific customer segment.
To elaborate on this definition, I’ve borrowed a description from Silicon Valley Product Group’s article, Personas for Product Management:
“For those that don’t know what a persona is, they are a technique for capturing the important learnings from interviewing users and customers, and identifying and understanding the different types of people that will be using your product. The persona is an archetype description of an imaginary but very plausible user that personifies these traits — especially their behaviors, attitudes, and goals.”
As a group, identify two to three customer segments to focus on. If your product or service serves more than three customer segments, prioritize them and select the top three. Down the road, your product may serve several different customer segments, but for MVP purposes let’s try to focus on one.
- Assign each team member two out of the three customer segments.
- Using the 4x4 Persona Worksheet above, have each participant create one persona for each of their customer segments.
- Present the personas to the group
- Collectively decide on one persona to represent your target customer segment.
2. Problem: isolating a pain point
What problems is this persona currently facing? Typical pain points include money and lack of time, but try and dig deeper into these pain points using the Five Whys tecnhnique.
Using this persona as a guide, brainstorm all of the different problems he or she is facing on stickies, one pain point per sticky note.
- Prioritize these stickies from biggest to smallest pain point
- As a group, collectively decide on the problem you would like to focus on solving
- If the team has trouble coming to an agreement, try using dot-voting to reach a consensus
3. Solution: focus on doing one thing really, really well
How are you going to solve this problem for the selected persona?
Brainstorm a list of potential solutions, products, and/or features.
- Have each participant write out their proposed solutions on sticky notes
- Post the solutions on a white board
- Group the solutions into categories
- Choose one sticky note from each category to represent the proposed solution for that category
- Use dot-voting to decide on the solution you want to focus on testing over the next four to eight weeks.
4. Success metric: outline your user engagement funnel and decide on a success metric
Based on the customer segment, problem, and potential solution you have identified, how will we know the target user’s problem has been solved?
This is where I always used to get stuck. There are so many metrics, how will I ever know which one validates or invalidates my hypothesis? I spent some time reviewing KPI’s for a project I was working on with Nick and Lane, and finally realized the crucial step I was missing. Outlining and understanding the user engagement funnel.
Take a few minutes to outline your user engagement funnel with the team. You may not decide on the bottom-most metric, but assign a number to the metric you do collectively agree on. It’s critical that you and your team understand your user engagement funnel and have analytics in place to observe where your users are “getting stuck” in the funnel.
By the end of the exercise you should be able to plug each of these answers into the following diagram:
To help illustrate this example, two of our amazing clients, Align and ZeeMee, have offered to share their hypothesis statements.
Align is an astrology-based dating app, that values connecting people based on sign compatibility and location. In our kickoff meeting we identified three primary customer segments, a handful of problems these people were experiencing with current dating platforms, and a variety of solutions. By the end of the meeting we were able to outline a solid hypothesis statement:
Similarly, ZeeMee, a digital portfolio for high school students applying to colleges and universities, had a handful of customer segments they wanted to support with a short timeline between admission cycles. For the first iteration of our MVP we boiled down our assumptions to the following hypothesis statement:
Once you are all in agreement, print out the your hypothesis and put it on the wall. This statement will serve as the vision for the MVP and a point a reference for the Product Owner during crucial product decisions. When you do start the build process, team members can often find themselves getting lost in the details. By having a high level hypothesis statement to refer to it will make product decisions more straight forward and reduce conflict within the team.
Special thanks to Lane Halley, Nick Giancola, skot e carruth, Brooke Kao, Emerson Taymor, and Jamie Caloras.
In Lean UX, the starting point is having a clearly written hypothesis statement. This gives your entire team a clear focus for their work. It keeps everyone aligned and sets the right constraints. In order to arrive to a well written hypothesis statement here are some of the steps:
- Declare Assumptions – A high-level declaration of what is believed to be true.
- Hypothesis – Specific descriptions of assumptions that target your product
- Outcomes – Metrics that can help validate your hypothesis. These can be both qualitative and quantitative
- Personas – Users for whom we are trying to solve the problem
- Features – The product changes or improvements that may solve our problem
First, based on specific user and business assumptions you want to write a problem statement using the follow template:
[Our service/product] was designed to achieve [these goals]. We have observed that the product/service isn’t meeting [these goals], which is causing [this adverse effect] to our business. How might we improve [service/product] so that our customers are more successful based [these measurable criteria]?
Next, you want to come up with some user assumptions by asking the following questions along with your team:
- Who is the user?
- Where does our product fit in hi work or life?
- What problems does our product solve?
- When and how is our product used?
- What features are important?
- How should our product look and behave?
After stating the assumption for both your users and prioritizing them based on level of risk. The final step is to write a hypothesis statement using the following format:
We believe [this statement is true].
We will know we’re [right/wrong] when we see the following feedback from the market:
[qualitative feedback] and/or [quantitative feedback] and/or [key performance indicator change].
Most of the time the main hypothesis can be hard to test when building out specific features. To break the hypothesis down further, you can create sub-hypothesis to test specific features using the following format:
We believe that
[doing this/building this feature/ creating this experience]
for [these people/ personas]
will achieve [this outcome].
We will know this is true when we see
[this market feedback, quantitative measures, or qualitative insights].
Once your hypothesis statements are written. The next step includes deciding on the Key Performance Indicators that can validate your hypothesis for each feature build. This should again be done collaboratively. I’ll talk more about how to determine the right KPI to measure success in the next post. Stay tuned!
Lean UXProduct Management