How to run product discovery before you build the MVP

Most MVPs fail before a line of code is written, because the team skipped the part where they find out whether the problem is real, who has it, and whether anyone will pay to make it go away. Product discovery is that part. I don't mean a workshop or a persona poster. I mean a few weeks of trying to disprove your own idea before you spend money on it. Here is the process I run at ProductGurus before any build starts, and the three moments in recent projects where it changed what got built.

Start by writing down what would have to be true

Before talking to anyone, write the idea as a set of claims you could be wrong about. "Renters need a trust score" is not one of those. "Newcomers to Canada get rejected for rentals because landlords can't verify them, and they would share bank data to fix that" is, because it names a person and a behaviour you can go and check. If you can't write it that way, what you have is a feature you like.

For Dwell, the original claims were a three-pillar design: verified identity, verified rent history, verified references. Those claims looked solid on paper. Two interviews later, one of them was missing a pillar and another was pointing at the wrong customer.

Interview the people who have to say yes

The mistake I see most often is interviewing enthusiastic users and calling it validation. The people worth an hour of your time are the ones who would have to change how they work or actually pay for the thing. For a two-sided product that means both sides, and whoever sits in the channel between them, who is usually the person nobody thought to call.

In Dwell's discovery, the renter interview did its job: Ashmita had viewed twenty rooms over six months, "mostly dingy homes," and that one detail exposed that a verified renter had no way to know whether a listing was worth their time either. The product gained a fourth pillar, a Property Trust Score, from a single sentence.

The interview that mattered more was with a real estate agent who rented rooms through Facebook Marketplace. His objection was blunt: marketing there is free, so how would you charge the individual owner? The plan had billed small landlords $15 per unlock. He was describing exactly the people who would never pay it. The real B2B gatekeepers turned out to be property management companies. That flipped the monetization model and added a whole interview segment, all before a screen was designed.

Ask about the last time, not the next time

People are bad at predicting what they'll do and surprisingly good at describing what they did. So the questions I rely on are about the past. When did this last happen to you? What did you do about it? What did it cost you? What have you already tried? "Would you use an app that…" only ever produces polite answers, and I have stopped asking it.

The Squint discovery is a good example. Agencies didn't say they wanted a website audit tool; they said manual audits took four to eight hours per prospect, so nobody did them at outreach scale, so cold emails stayed generic and converted below one percent. That reframed the product from a dev QA utility, a crowded and free category, into a pitch generator whose real asset is the persuasive report. Same technology, different product, because we asked about last Tuesday instead of next year. That one reframing removed a whole category of features from the build.

Check the physics before the pitch

Some ideas fail on constraints that no interview will surface, and this is the part of discovery people skip because it doesn't feel like talking to customers. GridSentinel was originally pitched as an electricity-theft detector for the grid edge. During technical discovery it became clear that the energy-balance equation needed to prove theft doesn't close on a medium-voltage feeder; it only works at the low-voltage transformer secondary. The headline feature couldn't work where it was being sold.

The right move was not to build it anyway and hope. We re-scoped the first product around what utility operations teams actively want and have no reason to refuse: automatic outage detection and fault localization. Theft detection moved to a later low-voltage variant where the maths actually works. I count that as a discovery outcome, even though no customer was in the room when it happened.

The three questions that end discovery

You are done when you can answer three questions with evidence rather than opinion. Is the problem frequent and expensive enough that someone already spends time or money working around it? Who specifically pays, and have you heard them describe the budget it would come from? And is there some constraint (technical, legal, or in the sales channel) that makes the obvious version of the product impossible? If the answer to any of them is "we think so," keep going. If any of them is a clear no, you have just saved yourself an MVP, which is a better outcome than it feels like at the time.

Dwell is currently at two of nine planned interviews, with the monetization question deliberately flagged as unresolved. That is what honest discovery looks like on a status page. Instead of a green tick, there is a list of what still has to be true, and the build waits until the list is short.

Sources and further reading

• The Mom Test, Rob Fitzpatrick. The clearest statement of why questions about the past beat questions about the future.
• Continuous Discovery Habits, Teresa Torres. Weekly customer contact and opportunity trees; the model this process borrows from.
• Dwell case study. The two interviews described above, with the interview notes.