Most teams treat an MVP as a smaller version of the product they already decided to ship. That leaves the lock in place. In Keyteller language, the door is the constraint worth opening. The lock is why it still will not open. A smaller product does not find the door. It forges keys in front of a lock nobody named.
The expensive habit
When a founder feels late, the instinct is to cut scope and still ship the same object: an app, a platform, a suite. The team reduces quality, delays a module, or labels a demo as learning. The door never gets found. Discovery, if it happens at all, is used to decorate a plan after someone has already started forging.
The failure mode is not shipping too little. It is forging while the door is still locked. A complete product that nobody finishes a workflow in is not a smaller risk. It is a larger one: sunk cost, a public story, and a team defending an object that never opened the lock.
A lock is not a smaller product
Find the door before you forge
The difference is when judgment happens, not how fast the team types.
Core idea: Discovery produces an arguable view of the door and the lock. A reactive MVP produces an object and hopes the market will explain why the door stayed shut.
- Reactive: decide the product, then shrink it until the calendar fits
- Proactive: decide what is true, what is better, and what to build first
- Reactive: treat discovery as a phase you exit at launch
- Proactive: treat Discovery as the engagement that names the lock with founders
- Reactive: park nothing, because everything is "on the roadmap"
- Proactive: park every other key in the open so a locked door cannot hide behind phase two
What "proactive" actually requires
Proactive does not mean generating more ideas. It means a repeatable way to refuse work that does not open the lock. The system has to survive founder enthusiasm, investor narrative, and how cheap it has become to start building. If the only gate is "can we stand up a repo this week," the gate will always open, and the lock will still be there.
Start from the live direction
Use the venture as it actually operates, not the deck version of it.
- Name the lock in business terms: the constraint that still blocks progress
- Name who feels the cost of delay
- Refuse a rebuild of the pitch as if it were evidence
Run the questions before you forge
Nothing gets forged until three answers exist that a founder can argue with.
- What is true: which door is locked in the live business
- What is better: which keys already exist
- What to build first: which key system to forge now
Authorize a key, or a pause
The system is working when pause is a legitimate output, not a failed workshop.
- One first key with a metric that matches the direction
- Everything else parked, named, and visible
- Discovery as the human engagement that holds the standard
This is not a tools problem
Public tools can inspect how the studio runs the questions. They are not the offer. A founder who installs a CLI has not found the door. The work lives in Discovery: evidence, trade-offs, a written override if the founder disagrees, and a prescribed next path. That path may be a program, a scoped project, or no further work yet.
What would disconfirm this
If a team already has a completed, repeated exchange and a clear owner for exceptions, shrinking a known product can be execution, not Discovery. The door is already open. This series is for the moment when the object is still a hypothesis and more forging would hide that. If the constraint is purely delivery capacity on a proven job, this series is the wrong instrument.