Scoping a product before building it: the 5 questions to ask

Scoping a product means putting in writing, before building, what you want to make, for whom, and how far it goes. It avoids the most common trap: spending weeks building something nobody has really defined. Five questions are enough to start.

The analogy: the map before the trip

You set off on a trip without having decided on the destination or the length. You drive, you stop, you change your mind, you turn back. You may end up somewhere pleasant, but at what cost? With a map, even a rough one, you know where you are going, and you notice right away when you stray.

Scoping is that map. It does not predict everything, but it keeps you from driving blind.

Question 1: for whom?

Who is the person who will use the product first? Not "everyone": one specific person, in their context. The more concretely you describe them (what they do, what annoys them, how they cope today), the more obvious your choices become.

Question 2: what problem, exactly?

Describe the problem in a sentence or two, without mentioning the solution. If you cannot explain it without saying "an app that...", the problem is not yet clear. Also ask how people manage today: that is your real competition, even if it is a spreadsheet or a notebook.

Question 3: what complete journey?

Describe, step by step, what the person does from start to finish to solve their problem. Each step becomes a screen or an action. This journey is the backbone of the first product: whatever is not in it can wait. It is the same reasoning as for an MVP.

Question 4: what are the limits?

This is the question most often forgotten. Write down plainly:

• What is included in the first version;
• What is excluded, deliberately, for later;
• The constraints: deadlines, budget, people available, rules to respect (for example around personal data);
• The dependencies: outside services the product will need (payments, sending messages, login).

A written scope protects everyone: it prevents misunderstandings about what was planned.

Question 5: how will you know it works?

Choose one or two simple signals that will tell you whether the product meets the need: people who finish the journey, who come back, who recommend it. Set them before launching, not after: otherwise you can always find a reason to say things are going well.

What scoping produces, concretely

• A short document: problem, user, journey, scope, constraints.
• An ordered list of what to build first.
• Mockups or simple diagrams, if useful for understanding each other.
• The points that remain uncertain, to check early rather than late.

You do not need a big frozen specification: a living scope, adjusted with what you learn, beats a perfect document that is useless after a month.

Traps to avoid

• Wanting to put everything in the first version. See vibe coding limits for what happens when you build fast without scoping.
• Choosing the technology before understanding the need.
• Scoping alone, without talking to real users.
• Writing nothing, then discovering that everyone had a different idea.

Remember

Five questions: for whom, what problem, what journey, what limits, how to know it works. Writing the answers before building costs a few hours and saves weeks spent heading the wrong way.

And for your product?

If you have an idea and want to scope it before building, our product build support starts with this scoping work, to decide together what gets built first. We can talk it over in a 30-minute call.