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
Forks
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 查看