Before You Build: 5 Ways Founders Can Test Demand

JAKARTA—Jakartaweekly.com. For many early-stage startups, the founder is the company’s operating system.

The founder knows the customers, understands the product, remembers why decisions were made and often knows which problems need attention before anyone else does. That proximity can help a young company move quickly.

But as a startup grows, relying on one person’s judgment, memory and follow-up becomes increasingly difficult to sustain.

For Elisabeth Kurniawan, Business Advisor, one of the most important transitions in a startup’s development is the move from founder-led to system-led operations.

The principle is not about removing the founder from the company. Instead, it is about turning the founder’s best judgment into knowledge, principles and systems that can be used by the wider organization.

That thinking also applies to one of the earliest and most expensive decisions a founder makes: whether to build a product in the first place.

Before committing months of engineering time, founders can take several steps to establish whether customer demand is strong enough to justify the investment.

1. Separate Conviction From Evidence

Founders are expected to believe in their ideas. Conviction can be an important source of energy, particularly when a company is trying to build something new.

But conviction is not the same as evidence.

A founder may strongly believe that a particular customer has a problem, that a product will solve it or that a market is ready.

The more useful question is what customers have actually demonstrated.

Have they changed their behavior? Have they committed time? Have they provided information, introduced other decision-makers, signed up, paid, or taken another meaningful action?

The distinction matters because positive feedback can be easy to collect. Evidence requires something more.

2. Define One Customer and One Problem

Broad product ideas can make it difficult to determine whether demand actually exists.

Instead of asking whether “the market” wants a product, founders can narrow the question to one customer, one problem and one proposed outcome.

This makes the product bet more precise.

It also makes it easier to determine what evidence would support the decision to build.

A founder who cannot clearly identify the customer or problem may still be at the stage of defining the opportunity rather than testing demand for a specific product.

3. Ask What Would Make the Customer Act

One of the most important questions before building is simple:

What would a customer actually do if this problem mattered enough?

Customer conversations can provide useful information, but action can provide a different level of evidence.

The relevant action will depend on the product and customer. It could involve committing money, time, access, data, a pilot, an introduction or another meaningful resource.

The objective is not to create an arbitrary test. It is to identify an action that demonstrates that the customer considers the proposed outcome valuable enough to act.

4. Set the Threshold Before You Build

Another risk for founders is changing the definition of success after seeing the results.

A stronger approach is to establish the evidence threshold before conducting the test.

How many customers need to act?

What type of commitment counts?

What result would justify moving into development?

And what result would mean the idea needs to be changed or reconsidered?

Writing these criteria down creates a clearer decision framework.

It also prevents founders from relying entirely on how they feel about the idea after receiving feedback.

5. Turn the Decision Into Company Knowledge

The final step is documenting what was tested, what customers did, what evidence was collected and what decision followed.

This is where product validation connects with the broader transition from founder-led to system-led organizations.

Founders often carry years of context in their heads: why a product was built, why a market was rejected, why a customer segment was selected or why an earlier strategy failed.

If that knowledge remains with one person, the organization repeatedly depends on the founder to explain its history.

Documenting important decisions turns individual memory into company memory.

The same principle applies to product bets.

A documented build decision creates a record that the team can revisit rather than relying on founder memory or hindsight.

From Founder Judgment to Repeatable Decisions

The move toward a system-led company does not mean replacing human judgment with bureaucracy.

Instead, it means identifying which recurring decisions can be made clearer through principles, evidence and operating systems.

For founders, product development is one of the areas where this discipline can have significant value.

Rather than asking only, “Do I believe this product will work?” the question becomes:

“What evidence would make this product worth building?”

That shift can change how a startup approaches its earliest engineering commitments.

It also creates a more structured basis for deciding when to move forward, when to modify the idea and when to stop.

A 72-Hour Framework for the Build Decision

These principles form the basis of Kurniawan’s 72-Hour Build Bet framework, designed for founders who are days or weeks away from committing significant engineering resources to a product idea.

The framework is organized around five areas: defining the Build Bet, separating belief from evidence, identifying meaningful customer commitment, establishing a defensible evidence threshold and documenting the final decision.

The resulting Build Bet Brief includes a Build Bet Definition, Belief-to-Evidence Sort, Customer Commitment Test and Build Threshold Rule.

It is designed specifically for the moment before an expensive build commitment—not as a broad customer-discovery course, but as a focused decision-making framework for determining whether an idea has earned the next step.

For founders considering what to build next, the question may not be whether they have enough confidence.

It may be whether they have enough evidence.

Want to test your product demand before spending months building?

Explore the 72-Hour Build Bet: Test Demand Before You Build framework and learn how to turn a broad product idea into a specific demand question, test meaningful customer action and establish a threshold before development begins.

Explore the 72-Hour Build Bet framework

This positioning makes Elisabeth’s experience the credibility behind the advice, while keeping the article focused on practical lessons for founders rather than making it read like an advertisement.