Here’s a scenario:
Top Exec at your company comes to you and says, “Yesterday, I was talking to Big Industry Player and they mentioned how they have Shiny Object. I think we should have Shiny Object too. How fast can we get it done?”
At a ProductCamp DC event a few years ago, my co-founder and I hosted a session called “Tales From The Product Frontlines”. Our first topic was about this very scenario. It so energized the participants that it took up 30 of the 45 minutes we had been allotted!
During the session, we asked folks questions like:
- What do you do now to vet new ideas, whether your own or from some other source?
- How is that working?
Most folks talked about having some sort of governance structure, such as an Executive Steering Committee, to vet new ideas based on some established criteria. Many talked about the need to create a business case. Some advocated that Product Management is best suited to do that, regardless of where the idea came from.
Yet, after the session, every person I spoke with told me they felt writing a business case was a total waste of time.
The old ways just don’t work
Pragmatic Marketing’s 2013 survey revealed that product managers spend over a month’s worth of time writing business cases. These business cases are filled with highly assumptive 3- or 5-year projections that are used to support significant investment asks. It’s no wonder we hate this — we’re staking our professional credibility on these unvalidated assumptions!
The problem is many product managers are never taught a systematic method by which to obtain the crucial information needed to inform a business case.
So what’s the solution?
Let me pause here to say if you’re hoping I have a magic secret for quickly validating a product idea, or if you’re totally married to writing business cases or MRDs, then stop. This post isn’t for you, because:
- It’s different and requires you to THINK.
- It’s hard work.
- It can take some time to get results.
But it works. I’m writing for the 10% who (1) realize that the old ways just don’t work, and (2) are willing to try something different.
(Thanks, Kevin Dewalt, for putting this so well, and forgiving me a little plagiarism!)
The solution is validated learning
The bottom line is spending time writing a big document is a colossal waste of time. Instead, focus on validated learning.
Because any new product idea is based on assumptions, those assumptions need to be validated. This can be achieved by formulating testable falsifiable hypotheses around the riskiest assumptions and rigorously testing these hypotheses.
The process of validation can be outlined in 5 steps. Each step generally follows this meta-pattern:
- Formulate a testable falsifiable hypothesis.
- Test the hypothesis.
- Analyze results and learnings.
- Decide to pivot or persevere.
I’ve used these this process to validate ideas for software products, but I imagine it could be adapted for any product concept. (So give it a try and let me know your results!)
1. Write down your customer hypothesis
Most folks typically start with the solution first. That’s the wrong place to start.
You need to take a step back and think very deliberately about your customer. This is true whether you’re pursuing adding a new component to an existing product or are pursuing a brand new product idea.
Note, by customer I mean your buyer — the individual who will buy your product. Even in B2B, you need to think about the specific individual or persona to whom you will need to sell your solution. That’s your customer.
2. Write down your problem hypothesis
What problems does your idea solve for the customer?
One way to do this is to think about the goal or job the customer is trying to accomplish.
For example: “I believe [customer] has a problem achieving [goal].” Or: “I believe [customer] is trying to accomplish [job], because [desired benefit].”
I typically use my Product CanvasTM to do this, as it allows me in a focused manner to break down the problem domain into discrete problems, and then formulate hypotheses around what I believe to be the top problems that my solution absolutely has to solve for first.
3. Validate your customer/problem hypothesis
Now it’s time to test your hypothesis. You do this by talking to folks you believe meet your target customer demographic.
Be sure to define minimum success criteria. This is the minimum amount of data you will need from the test to justify investing more time, effort or resources into proceeding with the idea.
When you’ve met your minimum success criteria, analyze your data, and decide whether to pivot or persevere.
A pivot is a fundamental change in direction of your business model or product strategy. You face a pivot when your hypothesis has been invalidated (i.e., proven false).
At this early stage, you could expect a pivot in terms of a change to your target problems, your target customer, or both. This may mean going back to step 1 or 2.
However, if the results of your test prove (i.e., validate) your customer/problem hypothesis, you may decide to persevere and move on to step 4.
4. Validate problem/solution fit
Now that you’ve validated your customer/problem fit, you need to test whether your idea is a potentially viable solution to the customer’s problem.
There are many ways to go about this, but nothing really beats creating a visual representation of your envisioned solution in the form of a wireframe or mockup. To keep things simple and minimize work, I look to design a representational screen or flow for each discrete problem identified on my Product Canvas and validated via the previous steps.
The primary goal of this stage is to garner early customers who endorse your solution vision and would be willing to use and pay for an early version of the product.
You’re also looking for directional feedback to identify the “right” handful of features to build for these early customers to prioritize your product development.
Formulate hypotheses around your screens, define your minimum success criteria, then reach back out to the customers you had interviewed earlier and demo the screens to them. Also, try to mix in some new folks who fit your target customer demographic.
When done, just like you did at the end of step 3, analyze your data and decide whether to pivot or persevere. At this stage, you may pivot on the solution, the problem or even the customer.
Or, if you’ve validated your hypothesis, you may have problem/solution fit and can move on to step 5.
5. Validate your solution via an MVP
There are many misconceptions about what constitutes an MVP, and I’ve written about these before.
In short, an MVP is an actual product that attempts to deliver real value to customers.
It’s “minimum” in the sense that it’s an attempt to deliver the absolute necessary set of features or capabilities needed to solve the customer’s problem for which the customer will pay.
Note that an MVP doesn’t necessarily have to be a software app. It could be a service.
A primary outcome of the previous step is being able to understand your customers’ problems at a granular level, which helps prioritize the initial set of features to build. This drives the definition of your MVP.
Once again, formulate a set of testable hypotheses to ensure you’re continuing to drive your product development based on validated learning. Depending on the complexities of the problem and solution, and the nature of my target customer, I may opt to first demo the MVP before actually delivering it. The results of your MVP test will again determine whether to persevere or pivot.
If you’ve got this far, you’ve validated critical components of your product idea. It doesn’t mean your idea is guaranteed to succeed, but you will have gained a far better understanding of the market opportunity, allowing for a far less assumptive and much more robust business case for your new product idea.