Skip to main content

define-an-mvp

Define the smallest product or service that delivers one real user outcome and tests the riskiest product assumption with explicit exclusions and evidence. Use when a product idea has grown into too many features, a team cannot agree what version one includes, or a validated problem needs a first release boundary.

Quellinformationen

Repository
protosphinx/sphinxstack
Letzte Quellaktivität
29. Juli 2026 um 13:55
Erkannte Sprache von SKILL.md
Englisch
Sterne
3
Forks
0

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

Datei-Explorer
2 Dateien

SKILL.md wird angezeigt

SKILL.md
Quellanweisungen · Schreibgeschützte Vorschau
name
define-an-mvp
category
start
description
Define the smallest product or service that delivers one real user outcome and tests the riskiest product assumption with explicit exclusions and evidence. Use when a product idea has grown into too many features, a team cannot agree what version one includes, or a validated problem needs a first release boundary.
# define-an-mvp Minimize the investment required to learn, not the care required to serve the user. Keep the full critical outcome, remove optional automation and breadth, and decide in advance what evidence changes the next build. ## Inputs - Gather the validated problem evidence, target user, current alternative, assumption map, constraints, and owner. - Name the learning deadline, risk tolerance, budget, privacy, safety, and operational capacity. - Separate required outcome from requested features. ## Procedure 1. Write the target user, situation, current problem, and observable successful outcome. 2. Rank assumptions by uncertainty and consequence. Choose the one the first release must test. 3. Map the complete critical journey from entry through outcome, failure, recovery, and support. 4. Mark the minimum capability needed at each step for the outcome to remain real and trustworthy. 5. Replace automation with a documented manual process where it is safe, honest, and learnable. 6. Remove extra audiences, channels, integrations, customization, dashboards, and scale features. 7. Write explicit included and excluded lists plus the condition that could add each excluded item. 8. Define quality, privacy, accessibility, support, data, and recovery requirements that cannot be cut. 9. Choose the exposure group, success signal, guardrails, duration, stop rule, and next decision. 10. Estimate build and operating effort, then cut again if the learning question can be answered more directly. 11. Review the boundary with delivery and support owners and publish the MVP brief. ## Boundaries Do not call a broken, unsafe, deceptive, inaccessible, or unsupported experience minimal. Never conceal manual work or pretend a prototype is a finished service. Do not add features merely to satisfy internal stakeholders. ## Done - An MVP brief names one user, problem, outcome, riskiest assumption, and complete critical journey - Included and excluded capabilities have explicit decision conditions - Non-negotiable quality, privacy, accessibility, support, and recovery requirements are approved - Exposure, evidence, guardrails, stop rule, owner, and next decision are defined before building Then use start-an-app or build-web-app for implementation and launch-a-product for controlled exposure.
Auf GitHub ansehen