Why Do Product Discovery?
Many teams and organisations jump into build mode too early. Then they build something that customers reject, they miss the mark, or they need extra budget to get it there. When you suggest a Product Discovery as a way to help get better results it gets rejected. This article is a way to answer the question: “Why do Product Discovery?”
In its simplest form, the core reason for doing a Product Discovery is to increase your level of certainty that you’re addressing the right problem, for the right customer, with the right product.
Product Discovery is relatively cheap and fast compared to Product Delivery (building the product or feature). You want to learn lessons and mistakes during Product Discovery because they will cost you 10–100x more for them in Product Delivery.
Sidebar: Product Discovery is a process (sometimes iterative) for better understanding your customer(s) and their problems. It often includes researching customers, researching the market, developing mockups, prototyping and sometimes developing rough working products. Some teams do this continuously, and others do it more like a project. Steve Blank’s book Four Steps to Epiphany is where I had the epiphany of how essential Product Discovery is.
It’s unlikely this sentence alone will convince non-believers of undertaking a Product Discovery, so let’s work through the benefits of a Product Discovery further.
I’ve outlined the benefits through the lenses of those base human (stakeholder) and business needs: towards pleasure/away from pain and increase revenue/lower costs. When you’re selling “why do a product discovery” internally, you’ll want to emphasise the benefits that play best in your organisation and to your stakeholders.
The Benefits of Product Discovery
The key benefits are:
- Better articulate the value of your product or feature. Product Discovery will help you understand how valuable your solution will be, and how many customers it will impact. This will help deliver a better product, and it will also help with budget requests (knowing the size of the opportunity tells you what you should invest).
- Reduce the cost and likelihood of date/budget overruns. The more you understand about what your customer needs, the better you can prioritise and cut effort that won’t deliver value.
- Deliver better value within the same budget. A Product Discovery will give you a better frame to prioritise from because you’ll understand the customer, the market and the problem better. Better prioritisation means you can deliver better value within the same budget.
- Less likely to waste budget on bad ideas. Product Discovery can invalidate an idea and signal it isn’t worth pursuing. This saves the company from the development and maintenance investment as well as the chance you frustrate customers. Again, a mistake in Product Discovery will be 10–100x cheaper than a mistake in Product Delivery, especially once the software is live.
- Increase your prices. Product Discovery will help you understand the value of your product and the pain of the problem to your customer. This means you might be able to increase prices or deliver more value. Knowing this early might change how investments are made.
- Uncover better use of funds. Product Discoveries often invalidate the initial idea but lead to adjacent ideas that are a more valuable and better use of company resources. You’ll win for uncovering a new opportunity, and the company wins because it gets a better return on investment.
- Uncover assumptions and risks so you can address them earlier. The discipline of a Product Discovery will help expose assumptions and risks you were taking that hadn’t been acknowledged. The sooner you understand your risks and assumptions, the better because you can address them.
- Impress the right customers, don’t worry about disappointing the wrong customers. Product is as much about what you don’t do and who you don’t do it for as it is who you do it for. You need to disappoint people, and you need to out-of-scope customers. A Discovery process helps you select the right people to disappoint.
Again, focus on the benefits that will play to your stakeholders’ and organisation’s drivers.
Highlighting the Risk of Not Doing a Product Discovery
Sometimes benefits don’t cut through, but the risk does. The risks of not doing Product Discovery are:
- You’re more likely to release products that don’t solve the problem. If you haven’t done a Product Discovery, then you’re unlikely to really understand the customer and their pain. If you don’t understand something, then it’s doubtful you can solve it or solve it well. This brings us to the next risk.
- You’re more likely to need an additional budget to solve the problem. You release something that entirely or partly misses the market. You’ll need more budget to improve it, or you will end up with disappointed customers.
- You’ll frustrate or lose customers. A product or feature that doesn’t solve the problem or gets in the way leads to frustration. If customers get frustrated or can’t do what they hired your product for, then you might lose them.
- You try to be everything for everyone, meaning you’re nothing for no one. Without knowing precisely who you are targeting as your customer, you will end up being pulled in every direction by customers and stakeholders. You need a Product Discovery to give you a firm basis to stand your ground on so you can say no.
Responses for frequently heard rejections
I’ve shared my responses to frequently heard rejections to help you further with your crusade to get your team or organisation to take up Product Discovery. Here is what I say to some of the reasons people give for not doing Discovery:
- “We understand our customer”. The more confident someone is about knowing their customer, the less confident I am that they know their customer. Reality dictates that we can’t know if customers want something until they buy and use it. Even then, customers purchase a product and use it in ways we often don’t understand. I hear this one so frequently it got its own post.
- “We only have the budget to build”. Many organisations are in solution mode, jumping straight to solutions when they get the hint of a problem. Hence, they allocate a budget to build a solution or find allocating resources to development easier than research. For the immediate build, you can focus on using a portion of the contingency that was allocated on Product Discovery on the basis that the Discovery will help you reduce risks and meet the build budget. In the long run, you need to educate the organisation on Discovery being a hygiene factor — that is, if you don’t have the budget to do a Discovery then you don’t have the budget to do the build.
- “We know the functionality we want”. This often happens when a team works inside-out (as opposed to outside-in). IT, finance or even the CEO has specified what they want — “users must be able to log in and trade shares seamlessly, easier than they can today”. And it’s true; they do know the functionality they want. They just don’t know what their customers want, or whether the customer even cares for the functionality. If you know the “functionality but not the experience” (a phrase often used in this situation), then you don’t actually understand what your customer wants — which means you run all the risks outlined above if you don’t do Product Discovery.
Bonus: Product Discovery Output
Sometimes stakeholders have a hard time understanding the value of Product Discovery because they can’t picture what they will get. So as a bit of a bonus here is a brief checklist of some of the concrete deliverables you might want to say you’ll deliver:
- Customer Interviews, the Notes and Insights
- Prioritised Customer Profiles
- Opportunity and Market Size
- Assumptions and Risks Register (From Customer Perspective)
- Validated Wireframes/Mockups
- Competitor Research
- Prioritised Jobs-to-be-Done
- Key Success/Failure Metrics
Read more:
Originally published at https://www.terem.com.au on October 1, 2020.
