An early startup faces several uncertainties at once. The customer may not experience the problem as expected, the proposed solution may be awkward to adopt or the buyer may lack a reason to pay. NSF’s I-Corps program provides background on connecting invention with practical impact. The process below is our interpretation of how a founder can organize learning before committing to a full product.
An experiment should answer a defined question. It should not be designed only to produce an encouraging result. Before beginning, record what evidence would strengthen the idea and what would require a change. That discipline makes disappointing information useful rather than something to explain away.
1. Describe a narrow customer and a recent problem
Start with a person in a recognizable situation. A hypothetical small distributor struggling with returns is more useful than a description such as every business that wants efficiency. Ask about the last relevant event and reconstruct the current process.
Identify who notices the problem, who carries the cost and who can authorize a change. Those roles may belong to different people. A solution can appeal to an end user while failing to satisfy the buyer or the team responsible for implementation. The early research should make that relationship visible.
2. Test the problem separately from the proposed interface
A polished prototype can draw attention toward the founder’s preferred solution. First establish whether the underlying problem is frequent or consequential enough to motivate action. Look for existing workarounds, resources already committed and the consequences of leaving the issue unresolved.
Record the evidence consistently. Separate what a participant did from what they predict they might do. A compliment is not the same as a purchase decision, but it can still identify a useful question for the next test. The objective is a more precise understanding rather than a binary verdict from one conversation.
3. Offer a bounded version of the outcome
A manual service, simple prototype or limited pilot can test whether the proposed result is valuable. Choose a format that exposes the important uncertainty without requiring the entire future product to exist. Be clear with participants about what is experimental and what support they can expect.
The trial should not conceal work the eventual product will be unable to provide. If the founder personally resolves every difficult case, record that effort and examine which parts would need to become a repeatable capability. Otherwise, the test may validate a bespoke service while the plan assumes scalable software.
4. Ask for a meaningful commitment
Depending on the context, useful evidence might include payment, implementation time or access to necessary information. The commitment should be proportionate and transparent. Its purpose is to learn whether the customer will take a real step, rather than to pressure a participant into validating the idea.
Observe the barriers. A customer may value the outcome but lack authority, budget or operational capacity. Those findings can change the target segment, the sales process or the product itself. They should influence the model rather than be dismissed as isolated objections.
5. Decide what to change next
Review the result against the original question. Continue when the evidence supports the next investment, revise when a specific assumption fails and stop when the problem no longer justifies the effort. Keep a short record of the reasoning so the team can understand how the idea evolved.
Early progress is not limited to features shipped. A stronger understanding of the customer, a rejected assumption or a simpler delivery model can be valuable outcomes. The process earns its cost when it reduces uncertainty about the business the founders intend to build.
