Product discovery: what it is and how to run it before you design

Most products don't fail because they were badly designed. They fail because someone designed the wrong thing, beautifully.

Product discovery is the work that stops that happening. It's the short, deliberate stretch where a team works out whether a problem is real, who has it, and what a solution needs to do, before anyone opens Figma or writes a line of code. Done well, it's the cheapest insurance a product team can buy. Skipped, it's usually the most expensive line item nobody budgeted for.

Here's what product discovery actually involves, how we run it at UntilNow, and how to tell when you've done enough.

What is product discovery?

Product discovery is the process of reducing uncertainty about what to build. It answers three questions:

• Is the problem real, and painful enough that people will change what they do to fix it?
• Who exactly has it, and how are they solving it today?
• What's the smallest thing we could build to prove we can solve it better?

Delivery is about building the thing right. Discovery is about building the right thing. Most teams are set up for delivery: sprints, tickets, velocity. Discovery doesn't fit neatly into any of that, which is exactly why it gets skipped.

Why teams skip it, and what that costs

Short version? It feels slow. The founder's conviction is strong, the roadmap's already been shown to investors, and a few weeks of interviews looks like a few weeks of not shipping.

The cost shows up later. Features nobody uses. Onboarding that leaks. A rebuild six months in because the data model assumed the wrong customer. We see this in UX audits all the time: the interface is rarely the root problem. The assumptions underneath it are.

The maths is simple. A fortnight of discovery costs a fortnight. Building the wrong feature costs the build, the maintenance, and everything you didn't build instead.

How we run product discovery

Ours usually takes two to four weeks. It's not a fixed recipe, but the shape is consistent.

1. Write the bet down

Who it's for, what problem, what outcome, and what has to be true for it to work. Sounds basic. Most teams have never written it down, and the first workshop often reveals the founders don't agree on who the customer is. Better to find that out now.

2. Talk to the right people

Six to ten interviews with people in the target segment. Not friends, not existing fans. We're listening for how they solve the problem today, what it costs them, and the exact words they use. Those words end up in your messaging later, which is a nice side benefit.

3. Map what you heard

Journeys, jobs, pain points. Where does today's workaround break? That break is where your product earns the right to exist.

4. Prototype the riskiest part

Not the whole product. The bit you're least sure about. Low fidelity is fine, often better, because people critique a sketch more honestly than a polished screen.

5. Test, then decide

Put the prototype in front of real users and watch what they do. Then make a call: build, change direction, or stop. A stop is a good outcome. It's the cheapest stop you'll ever get.

This is the core of our concept validation sprints, and it feeds straight into the rest of our product design process. When the questions are more about users than about the concept, we lean on user research: interviews, usability testing and prototype validation.

What you should have at the end

• A one-page problem statement the whole team agrees on
• Evidence from real users (quotes, recordings, task results), not opinions
• A short list of what the first release must do, and what it mustn't
• A tested prototype of the riskiest flow
• A clear decision, written down, with the reasons

If you finish with a 60-page report and no decision, it wasn't discovery. It was research theatre.

What it looks like in practice

When Spriggy grew from a pocket money app into a family of products (Schools, Invest, and SPRK for teens), each one came with its own unknowns. Different audiences, different jobs, different expectations about money. As their principal product design partner, discovery wasn't a single phase at the start. It ran ahead of every new product.

Today the platform serves over 1M Australians, with a 4.8-star rating from more than 31,000 reviews. Discovery didn't do that on its own. But it's how each new product started from a problem people actually had, rather than a hunch in a planning meeting.

Product discovery in the age of AI slop

AI has made building almost free. Founders spin up a working app over a weekend with tools like Lovable, v0 or Cursor. Product teams generate screens instead of designing them. Pretty much everyone is building their own UI now.

The result? A flood of products that look fine and feel the same. Same rounded cards, same gradient hero, same chatbot in the corner. That's AI slop: output that's plausible and polished at a glance, built without anyone asking whether it should exist.

Slop is what you get when you skip discovery and point a very fast machine at a guess.

Here's the opportunity. When everyone can build, the scarce thing is knowing what to build and for whom. Discovery is where that comes from, and it's why some products stand out while the rest blend in.

How to use AI well in discovery:

• Prototype more, not less. Generate three or four versions of the riskiest flow and test them all, instead of betting on one.
• Synthesise faster. Let AI cluster interview notes and support tickets, then check the clusters against the raw quotes.
• Test with realistic content. AI makes it cheap to fill a prototype with believable data, which gets more honest reactions than lorem ipsum.
• Don't let it replace the conversations. A model can summarise what your customers said. It can't meet the ones you haven't spoken to yet.

If your team is already building with AI, discovery is how that speed becomes an advantage, rather than a faster way to ship the wrong thing.

Signs you need discovery right now

• You're about to start a build and can't name five real users you've spoken to this month
• Your team argues about features because nobody agrees on the problem
• Activation or retention is flat and nobody can say why
• You're moving into a new segment or market
• Investors are asking for evidence, not vision

FAQ

How long does product discovery take?

For a focused question, two to four weeks. Entering a new market or building a new product line can take longer, but it should still be measured in weeks, not quarters. If discovery drags on, the question is usually too broad.

Who should be involved?

A founder or product lead, a designer and an engineer, at minimum. The engineer matters more than people think: they spot feasibility problems early, before a concept everyone loves turns out to be a six-month build.

Is product discovery the same as user research?

No. User research is one input to discovery. Discovery also includes framing the bet, prototyping and, most importantly, making a decision. Research without a decision at the end is just learning.

Can you run discovery on an existing product?

Yes, and you should, whenever you're adding a significant feature or a key metric stalls. A UX audit is often a good starting point because it shows where the current product is losing people.

The takeaway

Discovery isn't a delay before the real work. It is the real work, done cheaply. Two to four weeks of the right questions will save you months of building answers nobody asked for.

About to build something and want to pressure-test it first? We run discovery and concept validation sprints for founders and product teams. Get in touch.