Product discovery hasn’t disappeared. Sometimes it looks like working software.

Product discovery hasn’t disappeared. Sometimes it looks like working software.

If I can put a working prototype in front of a user this afternoon, how much discovery should I do before building it?

That question feels increasingly relevant for product managers. AI-assisted development makes some ideas cheap enough to test before we would previously have finished discussing the requirements.

Spotify’s Confidence team calls this “the product loop”: generate an idea, shape it into a testable hypothesis, validate it, and carry the learning into the next attempt.

What interests me is what this means for the familiar advice to do discovery before delivery.

I think that advice still holds. But we need to be clearer about what we mean by “build”.

Building a prototype is different from committing to a product

“Discovery before build” is useful advice when building means committing a team to weeks of implementation, creating something customers will depend on, and taking on the cost of maintaining it.

It becomes less useful if we interpret it as “don’t write any code until you’ve finished discovery”.

A working prototype can be a research tool. It gives someone something concrete to try, misunderstand, reject, or use in a way you didn’t anticipate.

Good product teams have used prototypes for years. What has changed is that a product manager may now be able to create a functional version of a narrow workflow without waiting for a full engineering sprint.

That creates more opportunities to learn through use. It also creates more opportunities to fall in love with an answer before understanding the question.

You still need a reason to build the prototype

The tempting approach is to have an idea, generate an app, show it to someone, and ask whether they like it.

You can get encouraging feedback that way without learning whether you should invest another day.

Before prototyping, I’d want to answer:

• Who experiences this problem?
• What do they do today?
• What assumption are we testing?
• What evidence would make us stop?

You don’t need a lengthy document. You do need enough understanding to choose a useful test.

Sometimes that means watching someone work before writing any code. Sometimes a conversation reveals that the problem is a missing permission, an unclear policy, or an existing feature nobody can find.

A prototype would add very little in those cases.

Give users a task, rather than a demo

Imagine a team considering an AI tool that turns meeting notes into assigned actions.

The first prototype might accept pasted notes and suggest an action list. It doesn’t need calendar access, workspace administration, billing, or a polished onboarding journey.

The important assumption is whether the suggestions help someone produce a trustworthy action list with less effort.

So give a user a suitable set of notes and ask them to prepare the follow-up they would normally send. Watch what happens.

Do they notice missing actions? Do they correct the owners? Does reviewing the output take longer than writing it themselves? Would they trust it enough to use it again?

“I like this” tells you far less than watching someone struggle to correct an action assigned to the wrong person.

A small user study can reveal usability and trust problems. It won’t, by itself, prove broad demand or long-term retention. The next test should reflect what remains uncertain.

Decide what happens to the code

Once a prototype works, there’s pressure to keep adding to it.

We’ve already built this much. Why start again?

Because “it helped us test an assumption” and “it is ready to support customers” are different standards.

After a test, I’d make the decision explicit:

Stop and discard it. The problem isn’t important enough, the approach doesn’t help, or the evidence doesn’t justify more investment.

Change it and test again. We learned something useful, but the workflow or underlying assumption needs another attempt.

Invest in a production version. There is enough evidence to justify engineering work, including reliability, security, accessibility, support, and maintenance.

Discarding the code is a reasonable outcome. So is retaining parts that engineers judge suitable. An automatic rewrite makes no more sense than automatically promoting a prototype into production.

Keep the learning either way. Record the assumption, what users did, and why you decided to continue or stop.

The PM’s responsibility becomes more explicit

Spotify’s article argues that teams should compress building time without compressing the time spent interpreting results. That is the part I’d pay most attention to.

When a team can generate several plausible solutions quickly, a product manager needs to help decide which deserve testing and what the results mean.

That includes resisting weak evidence. A polished demo, a positive stakeholder reaction, and a user saying they would “probably use it” are easy to collect. None settles whether a product deserves sustained investment.

It also means choosing a test that fits the risk. A disposable prototype using synthetic data can be appropriate for exploring a workflow. A system affecting payments, health, or sensitive customer information needs stronger safeguards before exposure to real users.

For the next feature, I’d start with one uncertain assumption and choose the cheapest credible way to test it. That might be an interview, a sketch, a manual service, or working software.

If it is working software, agree on the decision the test will inform before building it. Then leave room for the answer to be: we’ve learned enough to stop.