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.

Datos de origen

Repositorio
protosphinx/sphinxstack
Última actividad en el origen
29 de julio de 2026 a las 13:55
Idioma detectado de SKILL.md
inglés
Estrellas
3
Forks
0

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Explorador de archivos
2 archivos

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
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.
Ver en GitHub