Before you build your product, try selling it

You share your idea with people around you. The reactions are encouraging. “I'd use that.” “We really need something like this.” “Let me know when it launches.”

It feels good to hear. But nobody has changed a habit, set aside time or reached for their bank card yet.

Before spending several months on a product, look for a commitment that goes a little further than a compliment.

Talk about the last problem they had

“Would you use an app to manage quotes better?” invites a yes. It tells you almost nothing about someone's working day.

Try this instead: “Tell me about the last time a quote cost you time.”

Ask how they dealt with it, who got involved and what they already use. Listen to disappointing answers too: if the problem takes two minutes to solve once a quarter, it may not warrant a new subscription.

Start with a few people who actually face the situation. Friends can offer encouragement; potential customers can show you what matters.

Deliver the result on a small scale

Imagine a service that helps tradespeople follow up on outstanding quotes. You could begin with a shared spreadsheet and manual support, with their approval of the follow-ups.

The customer gets the promised outcome. You discover the information required, the exceptions and the moments when your help is valuable.

Be clear about what exists: a pilot service, partly delivered by hand, with a stated scope and price. Nobody should think they are buying finished software.

This first trial will not prove that the future product can be profitable. It will give you facts to inform the next decision.

Ask for an action that costs something

A commitment might be payment for a pilot, but it could also be a working session with the right person or time spent testing the solution on a real case.

These signals carry different weight. An email address shows curiosity. A real trial shows more interest. A payment tells you something about willingness to pay.

Strategyzer explores this distinction: observing what customers do provides stronger evidence than relying on what they say.

Set your criterion before the trial. For example: offer a pilot to five relevant businesses and look for two paying commitments. That is a decision threshold for this example, not a universal rule.

Build on what you have learned

If nobody commits, find out why. The problem may be a low priority, the promise unclear, the price wrong or the person unable to make the decision.

If customers try the service but do not return, look at what gets in their way. Adding random features will not answer that question.

If the service proves useful, you can define an MVP, or minimum viable product: an initial usable version limited to delivering the value you have already observed. Repetitive steps in the pilot will point to what you should automate first.

You then start development with a better understanding of the problem, involved users and a shorter list of priorities.

---

Have an idea you want to test in the real world? We can help you define a first experiment and the version to build afterwards. Let's talk.