Product discovery: seven questions before the first line of code

The pull to start quickly is always there. The idea seems clear, the team is ready, and every day of delay feels like falling behind. Yet a few days of asking at the start removes months of building the wrong thing.

These seven questions are the core of the discovery stage in my process.

1. Exactly what problem are we solving?

Not "what are we building" but "what pain are we removing". If the answer begins with a feature name, you haven't reached the problem yet.

A useful test: write the problem in one sentence with no solution in it. "Store customers get no reply after hours and buy elsewhere."

2. Whose problem is it?

"Everyone" is not an answer. Who is the main user, what is their role, and in what situation do they hit the problem? Sometimes the person who pays differs from the person who uses the product; you need to know both.

3. How do they cope today?

No problem is without a current workaround: a spreadsheet, an employee, a competitor's product. The workaround tells you how serious the problem is and what your product must beat.

If nobody does anything about the problem today, it may not be much of a problem.

4. How will we know it worked?

Know what success looks like before building. One measurable indicator that, if it moves, means the product did its job. Without it, every priority debate becomes a matter of taste. See success metrics that drive decisions.

5. What is the smallest version that solves it?

Not the full version; the one that does a single path properly from start to finish. This leads straight to real MVP scope.

6. What could sink the whole project?

Every product has a few major risks. Find them now:

• Value risk: perhaps nobody wants this.
• Usability risk: they want it but can't work with it.
• Feasibility risk: it can't be built within the time and budget.
• Business risk: law, cost or the revenue model won't allow it.

Test the biggest risk first, not last.

7. What constraints do we have?

Time, budget, team, regulation, infrastructure. Constraints aren't the enemy of creativity; they shape the solution. A product for the Iranian market has its own constraints in payments, infrastructure and messaging apps, and ignoring them means designing for a world that doesn't exist.

Where the answers come from

• Stakeholder conversations: the people who decide and the people who use.
• Watching real work: see how the user does the job today.
• Existing solutions: what competitors did and where they fell short.
• Existing data: if a product or process already exists, look at its numbers.

Guessing is cheap and usually wrong. Any answer based on a guess should be labelled as an assumption.

The output of this stage

Discovery produces a "problem map": problem, user, current state, success metric, risks and constraints. That map feeds the product requirements document.

In my process this stage ends with an approval gate: until everyone agrees on the problem definition, we don't move to solutions. The reasoning behind those gates is in why every stage needs a documented output.

The takeaway

Discovery doesn't slow the work down; it is the shortest route to the right product. Seven questions, a few days, one page. After that, every design and build decision has something behind it.

If you have an idea and want it turned into a concrete map, see product discovery and definition.