“...if we want to identify successful solutions, we need to start by building empathy for the people who will use or be impacted by our solutions. We need to understand their needs, pain points, desires, wants, goals, and motivations.”
— Teresa Torres
In Software Engineering: A Practitioner’s Approach, Roger Pressman observes “Fixing a problem in development costs 10 times as much as fixing it in design, and 100 times as much if you’re trying to fix the problem in a product that’s already been released.”
Yet many teams, especially “agile” ones, skip discovery and head straight for delivery for reasons such as “it doesn’t fit in our two week sprint.” Teams press full steam ahead on features the PM pulled from a roadmap or backlog (in the name of filling sprints or occupying teams) without much evidence these are the right things to work on.
The trouble is, if you’re not doing discovery, you’re guessing and hoping it all works—you’re riding the “release and pray” approach. John Cutler advises, “Instead of focusing on keeping people busy...if you can’t really make a case for something, it might be a clue to step back and learn more.”
In his book Inspired: How to Create Tech Products Customers Love, Marty Cagan outlines four types of risk:
Many founders believe feasibility is the biggest risk. It also looks like the easiest place to start.
However, feasibility is rarely (if ever) the biggest risk in software. “Can it be built?” is a function of time and money. In most cases, the biggest risk—the one where if you’re wrong, nothing else matters—is value: Is this valuable? Do you know who it’s valuable to? Can you differentiate the value in the market? Can you deliver the value in a way customers will buy?
...if you’re not doing discovery, you’re literally guessing and hoping it all works—you’re riding the “release and pray” approach.
If you’re wrong about value, it doesn’t matter how usable, buildable, or strategic your product is when you deliver it. Which is why smart teams do discovery.
Discovery and delivery are distinct processes with separate end goals. One is about learning and the other is about launching.
Discovery is about deciding what to build. The goal is to de-risk potential solutions and learn as quickly as possible.
Delivery is about building the thing you decided to build. The goal is to quickly deliver quality software that adds value to the customer and business.
Product Discovery: deciding what to build
Product Delivery: building what you’ve decided to build
Discovery starts with an insight and ends with a tested hypothesis. Delivery starts with a tested hypothesis and ends with a quality piece of software that delivers value to the business and customers.
Discovery and delivery are important to define because many product teams conflate the two. Nowhere is this as obvious as in MVPs.
It’s not unusual for founding teams to spend 3 or more months building an MVP. From the delivery angle, this may seem relatively quick. A functional product in a quarter! But the goal of an MVP isn’t delivering a product; the goal of an MVP is discovery around a hypothesis. It exists to test your riskiest assumptions and de-risk the first version of your product. And from that angle, even three months looks ridiculous...especially when no one uses the MVP.
But the goal of an MVP isn’t delivery; the goal of an MVP is discovery.
In those crucial months, founders could have run innumerable tests to address risky value assumptions without racking up enormous opportunity cost.
There are a variety of discovery methods you can use to test, “is this the right thing to build?” or “are we solving the right problems for our customers?”
If you’re not sure where to start, take a hard look at your limitations: how much time and budget do you have? If you’re short on both, a conversation with a customer can cost you as little as one hour. If you’re flush in both, you can explore building an MVP, the most expensive and time-consuming discovery option.
Other limitations to consider:
The right method, or the right combination of methods, will vary. But the goal of discovery is always to answer, “is this worth our bet?” in the shortest amount of time possible.
If you want to create a great product, discovery and delivery are both essential. Done well, each supports the other. Efficient delivery creates margin for ongoing discovery, and effective discovery de-risks delivery.
Another way to think about it is this: improving time to learning drastically improves time to market. The quicker you can close your knowledge gap and answer crucial value questions, the quicker you can release a valuable product to the market.
Time to learning: How quickly you can validate or invalidate a product hypothesis
Time to market: How quickly you can get to market, once you know what to build
Ultimately, you want to get good at recognizing where you are and what you’re trying to achieve:
Building products is messy, and there will always be some level of uncertainty. But learning when to discover and when to deliver increases the odds that you deliver a positive outcome for customers and business...without racking up opportunity costs along the way.
Oops! Something went wrong while submitting the form :(