Founder mvp

Purpose

Make the MVP a complete, usable test of one value proposition—not a feature pile, architecture project, deceptive demo, or low-quality excuse.

Give the founder a decision, the evidence behind it, the strongest contrary case, and the smallest executable next step. Do not produce generic encouragement or a long menu of tactics.

When to Trigger

Use this skill according to the frontmatter description. If the stated issue is a symptom of an earlier broken link, say so and route to founder-debugger or the owning retained skill.

Inputs Needed

• Specific target user and painful job
• Current alternative and success outcome
• Riskiest product and demand assumptions
• Safety, legal, trust, and reliability constraints
• Time, people, cash, and technical dependencies
• Manual steps founders can perform
• Existing tools, APIs, components, and services
• A named first-user list and launch date

Ask only for missing inputs capable of changing the decision. For reversible actions, make assumptions explicit and propose a bounded test instead of blocking on perfect data.

Questions to Ask

• What single function must the product perform?
• Can a real user receive the outcome end to end?
• What is the smallest vertical slice through the complete workflow?
• Which parts can be manual behind the scenes?
• Which assumptions require a real product rather than a prototype?
• What can be removed without breaking the promise?
• What trust, safety, or correctness bar cannot be cut?
• Who will use it first, on what date?
• What behavior will decide continue, revise, or stop?
• Are we building generality before encountering the second real case?

Mental Models

• One leading function.
• Vertical slice over horizontal layer.
• Viable is fixed; scope is variable.
• Manual backend, honest frontend.
• Prototype tests feasibility; MVP delivers value.
• Speed is learning rate.
• Reversible technical shortcuts.
• Launch date as a forcing function.

Use these models as competing lenses. Select the one that best explains the observed behavior, state what evidence would falsify it, and convert it into a decision rather than repeating it as a slogan.

YC Principles

• Build something ridiculously simple that can deliver any value to the first target users.
• Launch in weeks and resist the complete-solution fantasy.
• Use manual work that does not scale when it safely delivers the promised outcome.
• A real MVP has users; a private codebase or polished prototype does not.
• Cut features until the leading function is obvious.
• Instrument the core path from the first release and talk to users immediately.

Paul Graham Principles

• Launch fast and let contact with users evolve the idea.
• Recruit early users manually and make them happy.
• Do not mistake scalable infrastructure for progress before demand.
• Preserve the ability to change direction by keeping the first system small.

Garry Tan Principles

• Move quickly without producing slop: craft the core value path and remove everything else.
• Use AI and modern tools to compress build time while retaining founder understanding and evaluation.
• Never fake capabilities whose failure would violate user trust.

Decision Frameworks

MVP sentence

1. For [specific user]
2. who needs to [painful job]
3. the product will [single function]
4. so they achieve [observable outcome]
5. using [smallest complete path]
6. and we will continue only if [behavioral threshold].

Scope knife

1. Must be real: core outcome, trust boundary, data integrity, safety, and the measured behavior.
2. Can be manual: operations, matching, research, onboarding, support, and exceptional cases.
3. Can be bought: commodity infrastructure and non-differentiating components.
4. Can be deferred: settings, roles, integrations, automation, scale, polish outside the core path, and speculative edge cases.
5. Must be removed: work with no connection to user outcome or current assumption.

MVP type

1. Concierge: humans perform the service while learning the workflow.
2. Wizard-of-Oz: a truthful interface hides manual operations; never misrepresent consequential capability.
3. Single-player wedge: solve one user's job before collaboration or network effects.
4. Paid pilot: narrow scope and explicit success plan for B2B.
5. Heavy MVP: isolate the smallest technical milestone that proves the riskiest scientific or hardware assumption while still connecting to user value.
6. AI MVP: define an evaluation set, failure handling, human review, latency, and cost per successful task.

Step-by-Step Process

1. Choose one target user and collect direct problem evidence.
2. Write the MVP sentence and success threshold.
3. Map the complete current workflow.
4. Select the smallest vertical slice that delivers the outcome.
5. Classify every component as real, manual, bought, deferred, or removed.
6. Define non-negotiable trust and safety constraints.
7. Classify enterprise controls such as RBAC as core only when required by law or safety, or when at least two qualified buyers with authority make a concrete purchase contingent on the same narrow control; otherwise provide a manual workaround or defer it.
8. Choose existing components before custom infrastructure.
9. Set a short launch date and named first users.
10. Instrument activation, time-to-value, outcome success, repeat behavior, cost, and failures.
11. Launch with founder onboarding and observe use.
12. Debrief behavior and interviews within 24 hours.
13. Iterate the core path; do not broaden until the narrow path works.

Checklists

Viability

• A user can complete the core job.
• The outcome is real, not a promise.
• Failure is visible and recoverable.
• Trust, safety, and data integrity meet the required bar.
• Manual steps are operationally possible.

Minimum

• One target user and leading function.
• No speculative platform or generality.
• Commodity parts are bought.
• Every feature is required for the first outcome or test.
• Launch date and first users are scheduled.

Red Flags

• The MVP description is a list of features.
• The first user is not named.
• The team is building permissions, scale, or integrations before the core path.
• The product cannot deliver value without explaining the roadmap.
• A prototype reaction is counted as product validation.
• Manual work is rejected because it will not scale.
• AI output has no evaluation set or failure handling.
• Safety or trust is cut under the banner of speed.
• Launch waits for visual completeness outside the core outcome.

Common Mistakes

• Confusing minimum with incomplete.
• Confusing prototype with product.
• Building the architecture for imagined success.
• Testing many assumptions in one large release.
• Allowing one design partner to turn the MVP into custom software.
• Launching to friends instead of target users.
• Failing to instrument or observe the first use.

Metrics

• Days or weeks to first real user
• Activation into the core job
• Time to first value
• Core outcome success rate
• Repeat use at natural cadence
• Paid or workflow commitment
• Founder/manual minutes per outcome
• Cost per successful outcome
• Failure and correction rate
• Scope removed before launch
• Learning decisions per release

For every metric, define the unit, numerator, denominator, cohort, segment, cadence, source event, and owner. Prefer decision thresholds and cohort movement over universal benchmarks.

Example Scenarios

Scenario 1

An enterprise security product appears to need twelve integrations: select one system and one audit workflow for a paid design partner; perform evidence collection manually while keeping findings correct and secure.

Scenario 2

An AI agent works 70% of the time: narrow to one high-value task, create a real evaluation set, add human review and failure disclosure, and price the delivered outcome or pilot.

Scenario 3

A marketplace lacks liquidity: constrain geography and category, recruit supply manually, and fulfill early matches operationally before building marketplace automation.

AI Prompt Templates

Template 1

Turn this idea into an MVP sentence, smallest vertical slice, real/manual/bought/deferred/removal table, launch date, first-user plan, and behavioral threshold.
End with a decision, owner, deadline, metric, threshold, stop rule, and strongest contrary case.

Template 2

Cut this MVP scope by at least half without breaking the promised outcome, safety, trust, or decisive learning.
End with a decision, owner, deadline, metric, threshold, stop rule, and strongest contrary case.

Template 3

Design an AI MVP evaluation plan with representative cases, success criteria, human review, failure disclosure, latency, and cost per successful task.
End with a decision, owner, deadline, metric, threshold, stop rule, and strongest contrary case.

Related Skills

• founder-talking-to-users
• founder-retention
• founder-prioritization
• founder-distribution
• founder-pricing
• founder-debugger

Further Reading

1. Startup School Week 2: MVP — The primary YC MVP lecture: launch a ridiculously simple product that delivers any value to a first user.
2. One Order of Operations for Starting a Startup — Moves from problem to cofounders to a stripped-down, manually supported MVP.
3. Practical Design: MVP Spec — Separates product from prototype, leading function from features, and minimum from incomplete.
4. The Art of Shipping Early and Often — Diagnoses launch delay caused by fear, perfectionism, diffuse work, and weak problem understanding.
5. Michael Seibel: Building Product — A direct Startup School treatment of building something people want.
6. How to Build a Product — Firsthand product-building lessons from Reddit and Twitch.

Source Links

• Startup School Week 2: MVP — Michael Seibel. The primary YC MVP lecture: launch a ridiculously simple product that delivers any value to a first user.
• One Order of Operations for Starting a Startup — Michael Seibel. Moves from problem to cofounders to a stripped-down, manually supported MVP.
• Practical Design: MVP Spec — Dominika Blackappl. Separates product from prototype, leading function from features, and minimum from incomplete.
• The Art of Shipping Early and Often — Y Combinator. Diagnoses launch delay caused by fear, perfectionism, diffuse work, and weak problem understanding.
• Michael Seibel: Building Product — Michael Seibel. A direct Startup School treatment of building something people want.
• How to Build a Product — Steve Huffman and Emmett Shear. Firsthand product-building lessons from Reddit and Twitch.
• Do Things That Don't Scale — Paul Graham. Manual recruiting, over-serving early users, and direct observation as the path to discovering what should later scale.
• What I've Learned from Users — Paul Graham. Tests whether founders are paying attention by asking what, specifically, they have learned from users.
• YC's Essential Startup Advice — Y Combinator. The early-stage order of operations: launch, talk to users, iterate, and delay scaling until people want the product.
• The Scientific Method for Startups — Michael Seibel. A disciplined hypothesize-test-conclude-repeat loop supported by instrumentation.