Stop Wasting Time Building the Wrong Features with this Framework
Everyone knows that product managers should use lean startup techniques to drive product development. At a high level, this is easy to understand — release often, continuously measure the impact of what you build, and learn from your results.
As is often the case, the hard work is in the details. What’s the right scope for new features? How should you prioritize the different components inside a feature? How do you make sure you’re continuously learning from what you build?
After working on a variety of products over the past six years, I’ve found that focusing on your assumptions is the best way to guide the product development process. Here’s how to do it.
Identify Your Core Assumption
Let’s say you’re building an education app with content, students, and mentors. You have your basic product out in the market but no way for students and mentors to communicate inside your app. Naturally, your team wants to build in-app messaging to enable communication between students and mentors on the go.
Before you jump into development (with the inevitable complexity of a feature this size), step back and identify the core assumption of your product change.
In this case, you might believe “communication with mentors will help students learn the material” or “communication with mentors will increase student engagement.”
Whatever it is, make sure you and your team know it.
Break Down Your Assumption
Now, take that core assumption and break it down. Let’s say you identified “communication with mentors will increase student engagement” in our example.
Inside this assumption, you have a few possible sub-assumptions. Structuring your thinking in a tree is helpful to visualize the relationships.
Prioritize Your Sub-Assumptions
Leverage your research (user, competitive, domain expertise) to prioritize your sub-assumptions by what is most important to your product. You want to get to the meat of your assumption first, so that if it’s proven wrong, you can respond before you’ve wasted too much time.
Let’s imagine that in our example you have a strong group of excited mentors, but weak student engagement. You know that you won’t have to worry about mentors replying or actively reaching out to students.
However, you are less confident that students will become engaged after interacting with mentors.
Given your active mentor base, the most direct route to start testing communication between students and mentors is to focus on “students will be more engaged after they receive encouraging messages from their mentors.”
Scope and Test Your Most Important Sub-Assumption
Now, I’m guessing many of you are still imagining building an in-app messaging system and asking mentors to leverage it when you roll it out. However, this would be a waste of your prioritization thinking above.
You should work to cut away feature scope that is not necessary to test your assumption.
I like to use the visual of a scalpel, carefully cutting away unnecessary functionality to get to the core pieces you need for testing.
In our example, you only need to provide a way for mentors to message students to start measuring the impact on engagement. I don’t know about you, but email or text sound like workable solutions to get started.
Learn and Repeat
The truly awesome thing about starting with the core functionality in our example is that it will force you to focus on one simple step. How do you get mentors to start proactively reaching out to students?
With that focus, you might realize that it’s harder than just asking mentors to email students more frequently. For example, you might need to provide mentors with a list of students to reach out to this week.
The only way to find out what mentors need to consistently perform their new role is to get them started. Once they have given it a try, reach out and figure out how it’s going. I’m sure your mentors will have ideas for how it could go better.
If you learn that mentors need something other than the ability to create messages inside the app, don’t be afraid to build that instead of following your original plan. After all, that’s the whole reason you broke down that assumption in the first place.
In Summary
This framework will help you identify and prioritize the assumptions inside your next product change. You may end up building something different than you expect, but you’ll waste as little time as possible to start learning from your customers.
Ken is a product manager at Earnest. Prior to Earnest he led the sleep product team at Lumosity and was an early PM on the Office Online team at Microsoft. He has a degree in Computer Science from University of Maryland, College Park.
Earnest is a San Francisco-based technology company building a modern bank for the next generation. Our Product Management team is a nascent group of technical, entrepreneurial, jacks and jills of all trades, and we are actively hiring!
