5 Questions I Ask Every Founder Before Building
The fastest way to waste a software budget is to begin with a feature list that nobody has connected to a real decision.
Before we discuss screens, I want five answers. They do not need to be perfect. They need to be concrete enough to expose what is still assumption.
1. Who Is in the Situation?
“Small businesses” is a market label, not a user. Describe the person, the moment, and what they are trying to accomplish.
For example: “An operations manager receives supplier files in three formats every Monday and spends the morning combining them before the team can work.” Now we can inspect a real workflow.
2. What Happens Today?
If the product does not exist, what does this person do? A spreadsheet, a shared inbox, repeated phone calls, and manual checking are useful evidence because effort is already being spent.
If the honest answer is “nothing,” ask why. The opportunity may still be real, but the product must overcome a strong competitor: continuing as before.
3. Which Outcome Is Worth Paying For?
People do not buy dashboards because dashboards exist. They may pay to find a costly exception before it becomes a mistake, complete a task sooner, or give a client evidence without preparing a report manually.
Translate every important feature into the outcome it enables. If the sentence has no credible outcome, question the feature.
4. What Is the Smallest Trustworthy Test?
Small does not mean careless. Choose the one journey that carries the product’s main promise and make that journey understandable and reliable.
A booking product may first need search, availability, booking, and confirmation. Referrals and advanced reporting can wait. The journey being tested should still give users a fair experience of the value.
5. How Will the First Users Reach It?
“We will do marketing” is not a route. Name the first channel, audience, and action. Perhaps an existing community will receive a guided pilot, or a sales team will introduce the product to ten current customers with the same workflow.
Distribution evidence can also change the product. A tool sold through a high-touch pilot may tolerate manual setup that a self-serve product cannot.
What a Useful Answer Looks Like
- A specific person faces a recurring situation.
- They already spend time, money, or risk on a workaround.
- The product promises one outcome they value.
- The first version tests that outcome without careless execution.
- A real route exists to observe the first users.
A discovery conversation succeeds when it prevents the wrong build as much as when it clarifies the right one.
