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: 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). Better articulate the value of your product or feature. The more you understand about what your customer needs, the better you can prioritise and cut effort that won’t deliver value. Reduce the cost and likelihood of date/budget overruns. 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. Deliver better value within the same budget. 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. Less likely to waste budget on bad ideas. 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. Increase your prices. 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 better use of funds. 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. Uncover assumptions and risks so you can address them earlier. 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. Impress the right customers, don’t worry about disappointing the wrong customers. 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: . 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 release products that don’t 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’re more likely to need an additional budget to solve the problem . 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’ll frustrate or lose customers 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 say no. You try to be everything for everyone, meaning you’re nothing for no one. can 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: 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 . “We understand our customer”. own post . 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 only have the budget to build” 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 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. “We know the functionality we want”. they 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: Product Discovery: A Practical Guide for Agile Teams Steve Blank’s Four Steps to the Epiphany The Difference Between Product Discovery and Product Delivery Previously published at https://www.terem.com.au/blog/why-do-product-discovery/

Discovery

Is This New Corporate Venture Big Enough?

Product Decisions In Large Organisations Don't Have To Be Hard

Don't talk to McKinsey, talk to Terem

Nominated for 2022 - HackerNoon Contributor of the Year - Agile

Nominated for 2022 - HackerNoon Contributor of the Year - Agile Software Development

Too Long; Didn't Read

CTA: Download the FREE AI Productivity Shift report

How Doing Product Discovery Can Help You Build A Truly Invincible Company

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

How To Make Agile Work at Scale

Why Being Likable At Work Matters

Windows Sticky Keys Exploit: The War Veteran That Never Dies

Zero People Charged With Online Pirating, Swedish Prosecutor's Office Reports

Is ‘bias for action’ making product managers lazier?

How To Make Agile Work at Scale

Why Being Likable At Work Matters

Windows Sticky Keys Exploit: The War Veteran That Never Dies

Zero People Charged With Online Pirating, Swedish Prosecutor's Office Reports

Is ‘bias for action’ making product managers lazier?

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps