Minimum Idea State: A Practical Way to Test Risky Assumptions

A team can spend six months making the wrong idea reliable.

That is the uncomfortable gap between good engineering and good product judgement. Once an idea enters a delivery system, the word viable starts collecting requirements: authentication, integration, support, security, accessibility, reporting and the architecture needed to survive success. None of those concerns is frivolous. Together, however, they can turn a learning exercise into a small production programme before anyone has shown that the underlying idea deserves one.

The Minimum Idea State offers a harder question: what is the smallest honest test that would tell us whether somebody will act on this idea?

It sits before a Minimum Viable Product. The point is not to replace an MVP with a cheaper acronym. It is to separate two decisions that organisations routinely compress into one:

• Is there enough behavioural evidence to keep investigating the idea?
• Can a real product deliver the promised value safely, reliably and repeatedly?

The first question may need a landing page, a manual service or a deliberately limited invitation. The second may need working software. Confusing them is where engineering hours disappear.

The MVP was never supposed to be a small production release

Eric Ries defines a Minimum Viable Product as the version that produces the greatest amount of validated learning about customers with the least effort. He is also explicit that an MVP is not simply a minimal product. The original discipline is about learning, not shipping a thin version of every feature on a roadmap.

Yet the word viable is vulnerable to organisational gravity.

A founder may hear “enough to learn”. Security hears “safe enough to expose”. Operations hears “supportable”. Architecture hears “capable of scaling”. A senior sponsor may hear “something we can demonstrate”. Each interpretation is reasonable within its own boundary. Added together, they create a release that is too expensive to discard and too early to trust.

This is not an argument against engineering quality. It is an argument for putting engineering quality behind a stronger evidence gate.

If the uncertainty is whether people understand the proposition, production code is an unnecessarily expensive research instrument. If the uncertainty is whether a workflow can meet a regulated service level, a button on a landing page proves almost nothing. The test has to match the uncertainty.

Minimum Idea State moves the decision forward

Mark Pincus describes a Minimum Idea State as “the smallest atomic unit” that can show whether people like an idea. His example from Zynga is intentionally raw: expose a link, observe whether players click, then invest a little more only if the behaviour warrants it.

The useful part of the concept is not the speed. It is the sequence of commitments.

An MIS does not ask a potential customer whether a proposed feature sounds useful. It gives them an opportunity to do something: click, join a waiting list, book a call, upload a file, place a refundable deposit or attempt a transaction. Behaviour carries more information than polite enthusiasm because it imposes at least a small cost.

That does not make every action equivalent. A click costs almost nothing. A deposit involves money and trust. A completed manual transaction shows that somebody experienced enough value to continue through a real process. The strength of the claim must rise no faster than the strength of the behaviour.

This is also why the phrase Minimum Idea State is helpful despite its imperfect name. It reminds a team that the idea—not the product—is still on trial.

The label is new. The discipline is not

Minimum Idea State belongs to a longer family of methods designed to make uncertainty cheaper.

The Lean Startup supplied the validated-learning logic. Alberto Savoia’s pretotyping work asks teams to establish whether they are building the right “it” before building it right. The UK Government Service Manual tells teams to use prototypes to explore and test designs before committing to a build, and to choose the kind of prototype that fits the question—from a sketch to realistic code.

These approaches share a principle:

Build evidence in increments before building capability in bulk.

MIS sharpens one particular edge of that principle. It targets the moment before a prototype or MVP, when the team is still trying to establish whether the proposition can provoke meaningful action.

That is a useful correction to the way MVP is often practised. It is not a claim that discovery began in 2026.

This distinction matters because novelty can distract from method. Renaming a landing-page test does not make it rigorous. The team still needs a falsifiable assumption, a relevant audience, a pre-agreed signal and a decision it is prepared to take when the result arrives.

A click is evidence—but evidence of what?

The cleanest mistake in product discovery is to treat one visible number as if it answered every question.

A high click-through rate may show that the wording attracted attention. It may indicate an unmet need. It may also reflect novelty, ambiguity, accidental clicks or an audience that will never pay. Microsoft Research has documented cases where an apparent increase in clicks came from people becoming confused and clicking repeatedly. The metric moved. The product did not improve.

Behavioural evidence should therefore be read as a ladder:

• A click supports a claim about initial interest.
• A sign-up adds a small amount of intent and a willingness to share information.
• A time commitment—such as booking an interview or configuring a trial—shows effort.
• A refundable deposit or pre-order introduces financial commitment, but not proof of satisfaction.
• A completed manual transaction demonstrates that value can be delivered once.
• Repeat use begins to show that the value was not accidental.
• Retention or renewal supports a claim about sustained value.

Each rung earns a different next step. None should be promoted into a stronger claim simply because a steering meeting needs certainty.

A click can justify another test. It cannot justify a product roadmap.

The purpose of a Minimum Idea State is not to prove product-market fit. It is to obtain enough directional evidence to decide whether the next, more expensive uncertainty is worth testing.

DoorDash: evidence from doing the work

DoorDash is often reduced to the story of a simple landing page and a phone number. That description is accurate but incomplete.

The early team did not stop when somebody expressed interest. They took orders, collected food and completed deliveries themselves. By the time the company applied to Y Combinator, it still had no app and only a basic website, but it had completed 217 deliveries. The founders were talking directly to customers, restaurants and potential drivers while experiencing the operational constraints first-hand.

That progression is the important part:

1. A simple proposition exposed demand.
2. A manual service tested whether value could be delivered.
3. Repeated transactions exposed the real operating system that software would later need to support.

The landing page was not a cheap version of DoorDash. It was a gateway into the work.

One order would not have validated the marketplace, acquisition cost, courier supply or economics at scale. It did justify another experiment. This is the same discipline behind the argument in How to Build Products People Love: One Risky Bet: increase investment only as the evidence improves.

The enterprise version is harder

Consumer examples make MIS look easier than it is inside a large organisation. Demand is not always the riskiest assumption.

A user may want an automated decision, while the organisation remains unable to explain it to a regulator. A business unit may want a shared view of a customer, while the data cannot lawfully cross the required boundary. Operators may value a new control, while its dependency on a third-party platform makes the recovery model unacceptable.

In these settings, the Minimum Idea State should be one test in a portfolio of uncertainty, not a universal shortcut.

Before choosing the experiment, name the risk:

• Desirability: will the intended people take a meaningful step?
• Usability: can they understand and complete the task?
• Feasibility: can the technology, data and integrations perform the job?
• Viability: can the operating model fund and sustain it?
• Safety and compliance: can it operate within legal, security and risk boundaries?
• Reliability: can it recover, scale and remain supportable under real conditions?

A smoke test is well suited to desirability. A prototype can expose usability and workflow problems. A technical spike may be the right instrument for integration or performance risk. A controlled pilot may be needed to test operating procedures, accountability and recovery.

The answer may involve several tests running in parallel, each intentionally small. This is where product discovery meets value-stream leadership: fund the evidence needed to make a decision, not activity that happens to fit an existing team boundary.

It also guards against a familiar transformation failure. Making delivery faster does not help when the system keeps accelerating ideas that should have been challenged earlier. As argued in Why Most Digital Transformations Fail to Deliver Impact, local speed cannot compensate for an end-to-end decision bottleneck.

When a smoke test becomes deception

Raw experiments are not exempt from the obligations applied to finished products.

The ethical line is crossed when the test depends on people believing that something exists when it does not, particularly when they surrender money, personal data or sensitive information. “Coming soon” is different from a functioning purchase button that fails after payment. A research invitation is different from a fake clinical or financial service.

The US Federal Trade Commission’s guidance on “dry testing” is instructive even for teams operating elsewhere: advertising must be truthful and non-deceptive, and promotions for planned merchandise must disclose that it may never be shipped. In the UK, the Information Commissioner’s Office requires clear, concise information about how personal data will be used when it is collected.

A responsible MIS should therefore:

• state honestly that the proposition is being explored;
• collect the minimum information needed for the decision;
• explain how that information will be used and retained;
• avoid taking money unless the payment, refund and fulfilment position is clear;
• protect participants from operational, financial and reputational harm;
• close the loop if the idea is abandoned.

Deception also damages the experiment itself. People who feel tricked behave differently, complain, abandon the process or warn others. The test may produce a number, but it has contaminated the relationship it was meant to understand.

Speed without trust is not learning. It is borrowed time.

A practical operating rule

The strongest way to use Minimum Idea State is as a decision protocol rather than a deliverable.

1. Write the assumption as a claim

“Customers want this” cannot be tested cleanly. “Finance managers who reconcile more than 500 exceptions a month will upload a sample file to see an automated classification” is specific enough to challenge.

2. Identify the weakest evidence that would change the decision

Do not ask what can be measured. Ask what result would cause the team to invest, revise or stop. Define the threshold before the data arrives so enthusiasm cannot move it afterwards.

3. Choose the smallest honest behaviour

Match the commitment to the claim. A click may be sufficient to compare two propositions. It is weak evidence for willingness to pay. If the risk concerns adoption effort, ask for effort. If it concerns value, deliver the outcome manually to a small number of people.

4. Record what the test cannot prove

Every experiment needs an evidence boundary. State explicitly that the MIS has not tested retention, accessibility, integration, economics, security or scale unless it genuinely has.

5. Make the next investment conditional

The result should unlock a named next test, not an open-ended build. This preserves the economic purpose of the method: making the cost of being wrong proportional to what is actually known.

The friction between MVP and MIS is therefore not engineering versus product. It is a disagreement about when engineering becomes the right instrument.

Engineering turns an idea into dependable capability. Minimum Idea State helps decide whether that capability is worth pursuing. Used together, they allow teams to be both faster and more serious: cheap where uncertainty is high, rigorous where consequences become real.

MIS does not make success certain. It makes being wrong cheap enough to keep learning.