What are you testing? How to craft a hypothesis statement before building your MVP
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 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 4×4 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 technique.
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:
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.