In the Amazon TV series Bosch, a sign stapled to the cubicle wall of homicide detective Harry Bosch reads, “Get off your a** and go knock on doors.” Detective Bosch’s reminder to himself and his coworkers is clear. You can sit at your desk and think about who might have committed the crime. You can brainstorm about it with your fellow cops. And you can come up with a theory. But then it’s time to leave your office and put that theory to the test.
It’s a pretty fitting motto for a product manager as well, isn’t it?
As PMs, we have so much information coming at us, from so many sources, all the time. It can be difficult to know which ideas, suggestions, plans, requests, or demands to act on. Should we just do exactly what our executive team asks for? Should we rely solely on survey feedback, or solely on our gut, or some combination of the two?
How do we know where to focus our finite time, energy, budget, and development resources?
How a Product Manager Can Use the Scientific Method
Remember the scientific method you learned in school? Scientists themselves use many variations of the method, and it has evolved a great deal over the centuries, but a useful example of the method looks like this (courtesy of Khan Academy):
Step 1: Make an observation
Step 2: Ask a question
Step 3: Form a hypothesis (or testable explanation)
Step 4: Make a prediction based on the hypothesis
Step 5: Test the prediction
Step 6: Iterate (use the results to make new predictions or hypotheses)
This straightforward, step-by-step process, which is used in everything from astrophysics to behavioral psychology, can also serve as a helpful guide for product managers looking to determine if a feature idea or a new product will be a winner.
A scientific method case study: ProductPlan
For a concrete example of how this can work for a product manager, we’ll use our early days here at ProductPlan, when our co-founders identified a common pain among PMs and tried to devise a solution.
Step 1 (Make an observation):
“Product roadmaps are difficult to build and keep up to date, and they’re usually boring to view.”
In the product manager’s version of the scientific method, this first step is where you will identify a pain point, a problem to solve. That’s our role as PMs, after all. Contrary to a common misconception, product managers do not primarily build features or release products; we solve problems.
ProductPlan’s founders—experienced product managers themselves—realized that most PMs were creating and sharing roadmaps that often fell short in many ways.
These roadmaps were typically text-driven and not visually compelling—a missed opportunity, given that a roadmap should be a high-level, strategic view of a product’s plan. They were also drafted as static documents, making them time-consuming to update and difficult to create alternate versions.
And on and on went the list of typical product roadmap shortcomings.
Step 2 (Ask a question):
“Why aren’t product managers building more effective roadmaps?”
The next step for ProductPlan’s founders was to ask why.
Why would so many product managers—sophisticated strategic thinkers who know how valuable a compelling roadmap can be for securing buy-in from stakeholders and enthusiasm from the organization—be developing flat, boring roadmap documents?
It’s important to note here that your question of choice will initiate the need for some background research. This is exactly what our founders began doing to develop a theory for why so few product roadmaps were being built as they should be.
Step 3 (Form a hypothesis or testable explanation):
“Product managers don’t have the right app to build their roadmaps, so they’re forced to build them using the wrong apps.”
This was the turning-point step for our founders. They surveyed the market and determined that the issue wasn’t that PMs didn’t choose to build compelling roadmaps. It was that they couldn’t find the right tools for the job.
In other words, product managers couldn’t find a purpose-built product roadmap app—one designed specifically for PMs to help them quickly spin up product roadmaps that would be visually compelling, simple to update and share, and easy to switch views for specific audiences.
Step 4 (Make a prediction based on the hypothesis):
“With a purpose-built roadmap app, PMs would be able to build much more successful roadmaps, and businesses would be willing to pay for that app.”
At this point, ProductPlan’s founders made a prediction that they would need to verify before proceeding: Organizations would see the value in a purpose-built roadmap application and would pay for such a tool.
So they began the next step in the product manager’s scientific method—validating their prediction.
Step 5 (Test the prediction):
“Let’s build this thing! (Or at least a ‘minimum viable’ version of the thing.)”
Having received extensive and largely positive feedback from their target user personas, ProductPlan’s founders then set out to test whether their idea could actually create a viable business—by building a minimum feature set they could bring to the market.
The early-stage, MVP version of ProductPlan’s roadmap software app earned a few paying customers, and then a few more, and then enough that the product’s revenue was supporting the company’s operations and growth.
In other words, step 5 of the founders’ scientific method was a success: They had tested their prediction (that there was a viable market out there for product roadmap software) and learned that they were correct.
In fact, one of our founders has written a helpful post about how to use the MVP method for your early-stage product launch.
It’s also worth noting here that there is no single correct or guaranteed way to test your product or feature hypothesis. If there were, there would be no failed products. And as we’ve written about on this blog, sometimes products fail (and sometimes hilariously).
You can develop an MVP version, as ProductPlan did in its earliest days. Or you can rely on surveys. Or you can build and release a freemium version of your product, charging only later, and only for a more robust version of the product.
The point is, you can’t rely on your hunch (your hypothesis) alone. As Detective Bosch would put it, you’ll need to get off you’re a** and go knock on doors.
Step 6 (Iterate—use the results to make new predictions or hypotheses):
“What can we do next to improve the experience for our customers, or to solve a new problem entirely?”
Once they had received the initial results of their testing—ProductPlan’s early paying customers had helped to validate both the app and the business—the founders then began working on ways to add to their software’s functionality and to solve more problems for product managers who had been stuck for years building clunky roadmaps as spreadsheets and static slideshow files.
In fact, this final step in the product manager’s scientific method—use what you’ve learned to make new predictions that you can test—is still at work today at ProductPlan.
Indeed, we are continually using this entire process. From spotting problems our users are facing, through testing whether our hypotheses about solving those problems are viable, this method helps us make key decisions about what we’re building into our product roadmap app. And we believe that a methodical approach to everything we do is one reason ProductPlan is the roadmap software of choice for thousands of product and IT teams across dozens of countries—including companies like Starbucks, Mozilla, and Intuit.
In other words, to quote another recent character in popular culture, don’t just guess about what product to build next or which feature to prioritize. “Science the s%#* out of it!”
