Before a team deserves to forge a key, three questions need answers a founder can argue with: what is true, what is better, and what to build first. That is the method. What is true finds the door. What is better names keys that already exist. What to build first chooses the first key system. Founders should keep the questions. Studio jargon can wait.
What is true
Which door is actually locked in the live venture, not in the pitch? Truth here is not a brand story. It is a claim about a participant, a costly current workaround, and a result that would change a decision or a completed task. If the team cannot name that door in one paragraph, more product is activity, not progress.
What is better
Is there already a key? Better can mean an existing vendor, a manual process the team already runs, a narrower offer, or not doing the work. The question is not whether your idea is clever. It is whether a stronger key is already on the table and being ignored because it is less exciting to forge.
- Name the current substitute the participant actually uses
- Name the option that would win if the team were not attached to the product shape
- Write the override in the open if you still choose to forge
- Treat "no one else does this" as a warning until you know why
What to build first
Which key system opens the lock now? The first key is not the homepage, the mobile app, or the platform. It is the smallest system that would change a live workflow on trustworthy data. Everything else waits. If the ranking cannot produce a counter-argument, the door has not been judged.
The first key
The output of the three questions is one authorized key system, or a pause.
Core idea: Forge only the key that survived both the truth test and the better-options test, with a metric that matches the live direction.
- The first key completes a job someone already has, not a hypothetical user journey
- The metric is a finished workflow or a changed decision, not a download count
- Every other key is parked in language the team can see
- A founder can disagree, but the disagreement is written, not implied
A synthetic case, labeled as such
Stated goal: a patient-facing mobile app for a clinic operator. After the three questions, the lock was the record write path plus the clinician task queue. That was the first key. The app was deferred. Downloads are not completed clinical workflows on trustworthy data. The example is synthetic. It teaches the sequence. It is not a client win and not a clinical claim.
How Discovery uses the questions
Discovery is where the questions become an engagement. A founder brings a live direction and the evidence they have. The work restates the situation, finds the door, names the lock, and prescribes the first key, or a pause. The three questions are the judgment standard inside that work, not a self-serve replacement for it. The master key is what remains: constraint, evidence, ownership, and the next move.