Before you write a line of code, answer these five questions.

A useful product begins with clarity about the person, the problem, and the evidence.

1. Who has the problem right now?

“Small businesses” is too broad to guide a useful first product. Choose a person in a specific situation: an independent designer consolidating revision requests, for example. A good starting audience is one you can reach and learn from. You can broaden later, after you understand a repeated need.

2. What happened the last time?

Ask about recent behavior rather than hypothetical enthusiasm. Have the person walk through their last attempt, including the tools, handoffs, delays, and compromises. Listen for a concrete cost. A memorable frustration is useful, but repeated friction with a meaningful consequence is more informative.

3. What do they do instead?

Your competitor may be a spreadsheet, an assistant, a group chat, or doing nothing. Study that alternative carefully. It already fits into their day. Your product must make switching worthwhile, which means the improvement needs to outweigh setup, learning, and risk.

4. What would change your mind?

Write your uncertainty before you build an experiment. For instance: “We believe designers will share a real project to test a revision-summary service.” A manual pilot can test that behavior. Decide what result would lead you to continue, narrow the audience, change the offer, or stop. Avoid moving the goalposts after every response.

5. What is the smallest honest promise?

Define a useful result you can deliver reliably. Leave out the long feature roadmap. If your pilot needs manual work, say so. The goal is to understand whether the outcome matters, then make delivery more repeatable. A narrow promise helps you learn without building infrastructure for assumptions.