Building a product is not building a company.

Feature volume is a poor proxy for venture progress. At the earliest stage, a smaller product can create a better commercial decision than a larger one - if the team knows exactly what the product is supposed to prove.

Every feature carries an assumption

Large MVPs often bundle dozens of untested beliefs together. If customers do not respond, it becomes hard to know whether the problem, proposition, workflow, price, onboarding or execution was wrong. More product can create less information.

Define the decision first

Ask what decision the venture needs to make next. Should we continue? Which customer segment responds? Can the workflow create the promised outcome? Will someone pay? Then build the smallest credible experience capable of generating evidence for that specific decision.

Ask what decision the venture needs to make next.

Fidelity should match the risk

A rough prototype can be enough to test navigation or proposition clarity. It is not enough to test whether a high-stakes finance workflow can be trusted. Spend fidelity where the customer’s decision depends on it, and stay lightweight everywhere else.

Earn complexity

Architecture, workflow depth, permissions and operational tooling should expand as usage and customer requirements justify them. Complexity is easy to add and expensive to remove. Early products should preserve learning speed.

How to find the minimum credible product

Start by writing the customer behaviour that would make you more confident. Then work backwards. What experience must exist for that behaviour to occur? Which parts can be manual behind the scenes? Which integrations, permissions or visual polish are necessary for trust, and which are simply desirable? The result may still require serious engineering, especially in high-stakes workflows, but every component should have a reason tied to the learning objective.

Common failure mode: minimal becoming unbelievable

“Build less” does not mean build something customers cannot trust. If you are testing a financial control, security workflow or operational system, credibility may require realistic data, permissions and reliability. The discipline is not to minimise effort blindly. It is to concentrate effort on the elements that determine whether the customer can make a real decision, while postponing everything that does not.

Signal to watch: if the team cannot name the customer behaviour or decision a feature is supposed to influence, that feature is a candidate for removal or delay. A smaller backlog is not the goal by itself; a clearer relationship between product work and evidence is.

Applied example

A procurement founder wants to build a platform with supplier onboarding, scoring, contract storage and analytics. The real next decision is whether category managers will change supplier choices when presented with a new risk signal. A focused workflow that produces and explains that signal may be enough to test the venture before the rest of the platform exists.