“Minimum viable product” has come to mean a rough version built fast. That isn't what I'm after. The point of a small first build isn't speed for its own sake. It's learning.
I don't believe in spending months building an elaborate system before testing its most important assumptions. If the core assumption is wrong, everything built on top of it is wasted, however well it's engineered.
Write the hypothesis down
Every implementation is a set of beliefs that can be tested. I try to write the main one plainly: changing X should produce Y, because of Z. If I can't say it that simply, I don't understand the problem well enough to build yet.
Then I decide, before building, what result would prove me wrong. Without that, almost any result can be read as success.
Find the riskiest assumption
A hypothesis rests on several assumptions, and they don't carry equal risk. Some are almost certainly true. One or two carry most of the uncertainty. That's where the first build should go.
For a recruiting system, the tempting first build is an autonomous recruiting department. The useful one is much smaller. First test whether an AI-assisted workflow can identify appropriate prospects, hold an initial conversation, qualify against defined criteria, escalate when it should, and keep the history. If that works, expand it. If it doesn't, you've learned that cheaply.
For Dealer Flywheel, the riskiest assumption was that a store's own CRM export holds enough evidence to show where leads are being lost. So the first build is a diagnostic on that export, not new software for the store.
Focused, but credible
Small doesn't mean careless. A minimum viable implementation isn't a cheap version of the final product. It's what I can build that still tests the assumption honestly. That usually means:
- It runs inside the real operating environment, or as close to it as possible, not as an isolated demo.
- It's reliable enough that a failure means the idea failed, not the build.
- It records what happened, so the evidence exists afterwards.
- It leaves the decisions that need judgment with a person.
Then let the evidence decide
My preferred cycle is simple: hypothesis, minimum viable implementation, real usage, measurement, learning, iteration. Compare what actually changed with what was expected.
If it works, understand why. If it doesn't, understand why.
Either result should increase what we know about the system, and that's what makes the next build better than the last.