Strategy and planning
Pivot, persevere, or kill
Pre-declare the signals that mean continue, change the job, or stop — a clean kill is a successful MVP.
After the learning vehicle is live, look for evidence — not vibes. Decide in advance what would cause a pivot, persevere, or kill. Kill is underrated: stopping a false path is a successful MVP. Persevere means deepen the wedge (better reliability, adjacent jobs) — not instantly expand to every persona on the vision slide.
Concept
Connect this to feedback loops and keep discovery weekly so the roadmap's Next column stays honest.
Signals to watch
| Signal | Encouraging | Concerning |
|---|---|---|
| Retention / return | Users come back unprompted | One-shot curiosity |
| Payment / commitment | Money, LOIs, usage quotas hit | "Looks cool" and ghosting |
| Pull vs push | Users ask for access / invites | You beg for feedback meetings |
| Specific complaints | "I wish X worked for Y" | Vague "not for us" |
| Organic sharing | Referrals, internal champions | Only works when you are on the call |
Walking through meeting notes
You ran a concierge MVP for "AI meeting notes for sales calls" with 12 design partners for four weeks. Pre-declared rules:
- Persevere if ≥6 pay a pilot invoice and ≥8 reopen notes weekly without you nudging.
- Pivot if they love notes but only when you manually fix CRM fields — maybe the job is CRM hygiene, not transcription.
- Kill if fewer than three pay and interviews show the pain is "nice to have" behind a real priority.
Hitting kill criteria is not embarrassment. It is cheap insurance against a nine-month build.
Four lines before any "MVP" project
Write: (1) the assumption under test, (2) the smallest experience that can falsify it, (3) the metric or qualitative evidence you will accept, (4) the appetite in weeks. If you cannot write those four lines, you are not scoping an MVP — you are starting a build.
Put those four lines at the top of the PRD or pitch. When someone asks you to "design an MVP for X," name assumptions, pick a type, define success/fail criteria, then describe what you would build second if the signal is good. Say when you would not use an MVP framing because the risk is already resolved.
Common mistakes
- Deciding from vibes. Pre-declare numbers. "They seemed excited" is not a signal.
- Persevere by expanding the vision. Deepen the wedge first.
- Treating kill as failure. A clean kill is the MVP working.
Check yourself
Six of 12 partners pay; eight reopen weekly. Pivot, persevere, or kill? Persevere. Both pre-declared bars cleared. Deepen the wedge; do not add every persona.
They love the notes only after you fix CRM fields by hand. What now? Pivot. The job may be CRM hygiene, not transcription. The concierge revealed it.
Key takeaways
- Predefine pivot / persevere / kill; treat a clean kill as success.
- Watch retention, payment, pull, specific complaints and organic sharing — not compliments.
- Four lines on the pitch: assumption, smallest test, evidence, appetite in weeks.
Further learning
Eric Ries at Talks at Google on Lean Startup, validated learning and MVPs:
Map: MVPs and scoping.
Related
MVPs and scoping
Building the smallest thing that tests the riskiest assumption, and iterating.
Iteration and feedback loops
Turning feedback, support tickets and data into continuous improvement and kill decisions.
Types of MVP
Concierge, Wizard of Oz, single-feature wedge, or glued tools — pick the cheapest honest signal.