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.

소스 정보

저장소
protosphinx/sphinxstack
최근 소스 활동
2026년 7월 29일 13:55
감지된 SKILL.md 언어
영어
스타
3
포크
0

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
2 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
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.
GitHub에서 보기