Guide · Dubai · MENA

Product discovery for founders: find out what to build before you build it

Most founder discovery is confirmation seeking. A founder believes in the idea already, so each interview becomes a search for people who agree, and an ambiguous answer gets read as a yes. I have sat in on early customer calls where the founder asked "would you use something like this?" and treated the polite "sure, maybe" that followed as validated demand. That answer was a stranger being kind, not evidence of demand.

Real discovery interrogates the problem instead of confirming the idea. It asks whether the problem is painful enough, frequent enough, and expensive enough that someone will change their behavior to fix it. That question survives contact with a skeptical customer. The confirmation-seeking version does not.

A 2-3 week discovery sprint sized for one founder

You do not need a product team to run discovery well. You need a fixed window, a short list of questions, and a rule for when to stop.

Run the sprint in three stages across two to three weeks:

1. Week one: problem interviews. Talk to 10-15 people who live with the problem daily. Ask what they do today, what it costs them in time or money, and what they have already tried. Do not describe your idea. A founder who pitches during a problem interview stops learning and starts selling.
2. Week two: assumption mapping. List the beliefs the idea depends on: who has the problem, how often, what they pay to solve it today, and why nothing on the market already works. Rank the list by how much the whole idea depends on each assumption being true. The riskiest assumption sits at the top, not the one you feel most confident about.
3. Week two to three: testing the riskiest assumptions. Design the smallest test that could prove the top assumption wrong. That might be a landing page measuring signups, a paid pilot offer, or a manual version of the product delivered by hand to five users. Set a pass or fail threshold before you run the test, not after you see the number.

Set kill criteria before you start, in writing. Decide what result would make you stop the idea, and hold yourself to it. Without a written threshold, a founder in love with an idea finds a way to read a weak result as encouraging.

The three artifacts discovery should produce

A discovery sprint should end with three concrete things, not a feeling.

• A one-page problem brief. Who has the problem, how they solve it today, what that costs them, and the evidence that the problem is real rather than assumed. One page forces you to cut the parts you cannot back up.
• A ranked riskiest-assumption list. The assumptions your idea depends on, in order of how much damage being wrong about each one would do, with a note on which ones you tested and what you found.
• A first-version scope that fits six to eight weeks. Not the full product. The smallest version that tests the core assumption with real users, sized to a timeline a small team can hit.

These three documents are what a technical co-founder, an early hire, or an investor should be able to read and understand why you are building what you are building, and what would change your mind.

When AI is the product, discovery changes

Discovery for an AI feature or an AI-native product needs one more step before you write a line of production code: proving the model can do the job on your actual data.

A founder pitching an AI feature often skips straight to build because a demo with three cherry-picked examples looked convincing. That demo tells you the model can work. It does not tell you the model works often enough to ship. Before committing to the build, run a small eval on messy, real, representative inputs, the kind your actual users would send, not the kind that make a good screenshot. If the model gets it right on your curated examples and wrong on the messy ones, you have a discovery finding, not a shipped feature. Treat that eval as part of discovery, not as a step you get to after the build starts.

What founders skip, and what skipping it costs

Across more than 60 founders I worked with inside a Bahrain venture studio, the same shortcuts came up again and again, and they carried a real cost later.

The most common was skipping problem interviews and building straight from belief, because the founder already knew the answer. Teams that did this shipped a working product nobody asked for, then spent months bolting on the features that should have come out of week one.

The second was running interviews that only talked to friendly contacts: warm intros, other founders, people who wanted to be supportive. Friendly contacts rarely say no, so the founder walked away with a stack of encouraging conversations and no real signal.

The third was skipping the written kill criteria. Founders who set no threshold in advance kept moving the goalpost each time a result came in weak, and some of them spent six more months on an idea the evidence had already answered.

The founders who cleared discovery in two to three weeks wrote down what would change their mind before testing began, then let it, regardless of how strong the idea looked going in.

Run it yourself, or bring in outside help

A founder with time, a willingness to hear no, and the discipline to write things down before testing them can run this sprint alone. What stops founders is the honesty required to read a weak result as weak, about an idea they have already told investors and friends about.

That is where outside product help earns its keep: someone with no emotional stake in the idea, running the same sprint, who will tell you when the riskiest assumption failed its test. If you want a second pair of eyes on your discovery before you commit six to eight weeks of build time, zero21's 0-to-1 product launch work starts at this stage.

Book a call

If you are heading into discovery on a new product and want a structured sprint instead of a string of friendly conversations, book an intro call. For weekly writing on AI and product from zero, read the Scalable newsletter.