mvp-first

MVP First

Prerequisite Protocol

Environment Detection

PROJECT_ROOT=$(git rev-parse --show-toplevel 2>/dev/null || echo "unknown")
BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
COMMIT=$(git rev-parse --short HEAD 2>/dev/null || echo "unknown")

echo "PROJECT: $PROJECT_ROOT"
echo "BRANCH: $BRANCH"
echo "COMMIT: $COMMIT"

Prerequisite Skill Check

# 检查前置工件
GOAL_ARTIFACT="memory/artifacts/goal-oriented/latest.json"
DDD_ARTIFACT="memory/artifacts/ddd-strategic/latest.json"

if [ -f "$GOAL_ARTIFACT" ]; then
  echo "FOUND: goal-oriented artifact"
fi

if [ -f "$DDD_ARTIFACT" ]; then
  echo "FOUND: ddd-strategic-design artifact"
fi

mkdir -p memory/artifacts/mvp-first

MVP First

Overview

MVP (Minimum Viable Product) is not "minimum usable product", but "minimum verifiable product".

Core purpose:Validate key assumptions at minimum cost, to avoid investing large amounts of resources based on unvalidated assumptions.

The goal of an MVP is learning, not delivering a product. Every MVP is answering a key question: do users really need this?

When to Use

digraph when_to_use {
    rankdir=TB;
    node [shape=box, style=filled, color="#c8e6c9"];

    "用户提出新需求" [shape=ellipse, color="#bbdefb"];
    "功能是否复杂?" [shape=diamond, color="#fff9c4"];
    "是否验证过假设?" [shape=diamond, color="#fff9c4"];
    "直接实现" [color="#f8bbd0"];
    "应用 MVP 思维" [color="#c8e6c9"];

    "用户提出新需求" -> "功能是否复杂?";
    "功能是否复杂?" -> "直接实现" [label="否, 简单修改"];
    "功能是否复杂?" -> "是否验证过假设?" [label="是, 新系统"];
    "是否验证过假设?" -> "直接实现" [label="是"];
    "是否验证过假设?" -> "应用 MVP 思维" [label="否"];
}

Trigger scenarios:

The user says "I want to build an XX feature", "help me plan this project"
The feature involves multiple subsystems or a complex architecture
The user has not validated the requirement assumptions

Not applicable scenarios:

Simple bug fixes or configuration changes
The user explicitly requests a complete solution
Project iterations where the requirements have already been validated

The MVP Mindset

Core Questions (Must Ask Before Implementation)

Before giving any implementation plan, you must answer:

What is the core assumption?
- Do users really need this feature?
- Will users use this feature?
- Can this feature solve the user's problem?
What is the minimum validation cost?
- How can the assumption be validated with the least time and resources?
- Can it be done manually first?
- Can existing tools be used instead of development?
What is the criterion for successful validation?
- How many users using it counts as success?
- What data proves the assumption holds?
- How long until a conclusion can be reached?

MVP is NOT

❌ MVP 不是"功能简化版"
   - "保留核心功能，砍掉次要功能" → 这是产品规划，不是 MVP
   - MVP 的目标不是交付产品，而是验证假设

❌ MVP 不是"上线最小可用版本"
   - "先上线再迭代" → 可能浪费数周开发用户不需要的功能
   - MVP 可以不上线，甚至不需要写代码

❌ MVP 不是"快速交付"
   - "1周上线" → 如果方向错误，1周也是浪费
   - MVP 的目标是学习方向，不是交付速度

The Process

digraph mvp_process {
    rankdir=TB;
    node [shape=box, style=filled];

    "识别假设" [color="#c8e6c9"];
    "定义验证目标" [color="#bbdefb"];
    "设计最小实验" [color="#fff9c4"];
    "实施并测量" [color="#f8bbd0"];
    "分析结果" [color="#e1bee7"];
    "假设成立?" [shape=diamond, color="#fff9c4"];
    "继续投入" [color="#c8e6c9"];
    "调整或放弃" [color="#f8bbd0"];

    "识别假设" -> "定义验证目标";
    "定义验证目标" -> "设计最小实验";
    "设计最小实验" -> "实施并测量";
    "实施并测量" -> "分析结果";
    "分析结果" -> "假设成立?";
    "假设成立?" -> "继续投入" [label="是"];
    "假设成立?" -> "调整或放弃" [label="否"];
    "继续投入" -> "识别假设" [label="下一步假设"];
    "调整或放弃" -> "识别假设" [label="新假设"];
}

Step 1: Identify key assumptions

User requirements usually contain multiple implicit assumptions; identify the one with the highest risk.

Example: the user wants a "comment system"

Assumption 1: Users are willing to post comments on the platform
Assumption 2: Users care about other people's comments
Assumption 3: Comments will increase user stickiness
Assumption 4: A review and filtering mechanism is needed

Highest-risk assumption: Assumption 1 - If users do not comment at all, the other assumptions do not hold.

Step 2: Define validation goals

Define success criteria with numbers.

Example: validate whether users will comment

Success criterion: at least 50 users post comments within 1 week
Validation period: 7 days
Failure criterion: < 10 users comment, or the comment content quality is too low

Step 3: Design the minimum experiment

Find the lowest-cost way to validate the assumption.

Common MVP patterns (from low to high cost):

Pattern	Cost	Applicable scenario	Example
Manual service	Extremely low	Validate whether the need exists	Use Google Form to collect comment needs, reply manually
Landing page	Low	Validate user willingness	Make a "comment feature coming soon" page and collect email subscriptions
Fake door	Low	Validate user interest	Place a "comment" button; after clicking, show "feature under development"
Wizard-style	Medium	Validate user experience	Comments are processed manually in the backend, but the frontend looks like a real feature
Single feature	Medium	Validate core value	Only post comments + view comments, no other features

Step 4: Implement and measure

Only build the features necessary to validate the hypothesis.

Code example: fake door MVP (validate whether users want a comment feature)

<!-- 评论按钮 - 假门 MVP -->
<button id="comment-btn" class="btn-primary">
  发表评论
</button>

<div id="feedback-modal" style="display:none;">
  <p>评论功能正在开发中！</p>
  <p>留下您的邮箱，功能上线第一时间通知您：</p>
  <input type="email" id="user-email" placeholder="your@email.com">
  <button onclick="submitEmail()">提交</button>
</div>

<script>
document.getElementById('comment-btn').addEventListener('click', function() {
  // 记录点击次数 - 这是最重要的数据
  trackEvent('comment_button_clicked');

  // 显示收集邮箱的模态框
  document.getElementById('feedback-modal').style.display = 'block';
});

function submitEmail() {
  const email = document.getElementById('user-email').value;
  // 发送到后端记录
  saveEmail(email);
  alert('感谢您的关注！');
}
</script>

Cost: 30 minutes of development + 1 week of observation Learning: Click-through rate > 5% → users really want a comment feature

Step 5: Analyze and decide

Make decisions based on data, not intuition.

Three outcomes:

Hypothesis holds(data meets target) → continue investing in the next layer of features
Hypothesis fails(data does not meet target) → abandon or adjust direction
Insufficient data → extend the validation period or improve the experiment design

MVP Layers (layered validation)

Do not build the complete system all at once; validate step by step by layer:

【示例：评论系统的 MVP 分层】

Layer 0: 验证需求是否存在
- 方式：假门按钮（点击后显示"功能开发中"）
- 成本：30 分钟
- 目标：点击率 > 5%

Layer 1: 验证用户会使用功能
- 方式：只能发表评论 + 显示评论（无审核、无过滤、无回复）
- 成本：1 天开发
- 目标：1 周内 50+ 用户发表评论

Layer 2: 验证用户需要内容质量控制
- 方式：加审核功能（发现垃圾评论时再加）
- 成本：1 天开发
- 目标：审核通过率 > 80%

Layer 3: 验证用户需要互动
- 方式：加点赞功能（观察用户是否想要互动）
- 成本：0.5 天开发
- 目标：点赞率 > 10%

Layer 4: 验证用户需要复杂互动
- 方式：加回复功能（观察单层评论是否不够）
- 成本：1 天开发
- 目标：评论中 @他人 的比例 > 5%

Key principle: each layer is an independent MVP, and only after validating one hypothesis do you move to the next layer.

Common Mistakes

1. ❌ "Keep the core features" is not an MVP

用户需求：评论系统（评论、回复、点赞、审核、过滤）

❌ 错误的 MVP 思维：
"保留核心功能：评论、回复、点赞、审核、敏感词过滤"
→ 这仍然是完整系统，只是去掉了积分等次要功能
→ 开发成本：1 周

✅ 正确的 MVP 思维：
"Layer 0: 假门按钮，验证用户是否想要评论功能"
→ 成本：30 分钟
→ 如果点击率 < 5%，直接省下 1 周开发时间

2. ❌ "Iterate after launch" is not an MVP

用户需求：用户等级系统

❌ 错误的 MVP 思维：
"先上线基础等级系统（5个等级、积分规则、权限控制），后续再加徽章、排行榜"
→ 开发成本：3 天
→ 问题：可能用户根本不在乎等级

✅ 正确的 MVP 思维：
"做一个静态的等级显示（根据注册时间显示等级），观察用户是否在意等级"
→ 成本：2 小时
→ 学习：查看个人主页的用户中，看等级信息的比例 > 30% → 继续投入

3. ❌ An MVP must be code

用户需求：积分商城

❌ 错误的 MVP 思维：
"开发一个简单的商城页面，用户可以用积分兑换虚拟商品"
→ 成本：2 天开发

✅ 正确的 MVP 思维：
"在社区发帖：'积分兑换功能即将上线，大家希望兑换什么？' 收集 50+ 回复"
→ 成本：30 分钟
→ 学习：如果没人回复，说明积分商城不是刚需

4. ❌ An MVP can delay launch

用户需求：个性化推荐

❌ 错误的 MVP 思维：
"开发一个简单的推荐算法（协同过滤），下周上线验证效果"
→ 问题：如果推荐效果差，不知道是算法问题还是用户不需要

✅ 正确的 MVP 思维：
"在热门内容列表中随机插入 1 条'编辑推荐'，观察点击率"
→ 成本：1 小时
→ 学习：编辑推荐的点击率 > 随机内容的 2 倍 → 说明用户需要推荐
→ 下一步：开发真正的推荐算法

Handling User Pushback

Users often oppose the MVP approach for various reasons. Below are common objections and persuasion techniques:

Objection 1: "Competitors already have complete features"

The user's concern: market competition pressure, fear of losing users

Persuasion strategy：

✅ 用数据说话：

"我理解你的压力。但正因为需要快速上线，MVP 更重要：

**时间现实分析：**
- 完整功能：8个模块 × 3-5天 = 24-40天
- MVP：4.5天
- 延期风险：完整功能 100% 延期 3-4周 → 用户流失更严重

**市场风险对比：**
- 方案A（完整功能延期）：上线延迟 3-4周 → 竞争对手领先更久
- 方案B（MVP快速上线）：下周有功能 → 立即获得用户反馈，快速迭代追赶

**建议**：先用 MVP 上线核心功能，获得市场反馈，再快速迭代。"

Objection 2: "We're launching next week, no time for experiments"

The user's concern: time is tight, and they think the MVP will cause delays

Persuasion strategy：

✅ 重构时间认知：

"**MVP 不是拖延，而是加速：**

传统方式：开发 2 周 → 测试 1 周 → 上线发现用户不需要 → 浪费 3 周
MVP 方式：实验 3 天 → 验证失败 → 立即转向 → 节省 2.5 周

**关键**：如果方向错了，开发再快也是浪费。MVP 帮你在 3 天内发现方向错误，而不是 3 周。

**建议**：用 30 分钟做 Layer 0（假门），如果点击率 < 5%，直接省下 1 周开发时间。"

Objection 3: "Users will definitely need this feature"

The user's concern: they trust their own judgment and think validation is a waste of time

Persuasion strategy：

✅ 引用数据/案例：

"**数据显示，70% 的功能用户并不需要：**

- 某社交平台开发私信功能（2周），上线后使用率 < 1%
- 如果先用假门测试（30分钟），能省下 2 周时间

**问题**：你觉得用户需要，但：
- 用户真的会使用吗？
- 使用频率有多高？
- 用户愿意付出什么代价？

**建议**：用半天时间验证假设，成本极低，但能避免数周浪费。"

Objection 4: "Just give me the complete plan, I'll decide myself"

The user's concern: they feel the agent is lecturing and want autonomy

Persuasion strategy：

✅ 提供选择，而不是说教：

"好的，我可以给你两个方案：

**方案A（MVP）**：
- Layer 0：假门按钮（30分钟）
- Layer 1：基础评论（1天）
- 总成本：1.5天
- 风险：极低，随时可以停止

**方案B（完整功能）**：
- 数据库设计：7张表
- 接口开发：15个接口
- 功能开发：8个模块
- 总成本：4-6周
- 风险：高，可能开发用户不需要的功能

我建议方案A，但最终由你决定。你希望我先提供哪个方案的详细设计？"

Objection 5: "The MVP is too crude, the user experience will be poor"

The user's concern: worried that the MVP will affect brand image

Persuasion strategy：

✅ 区分"简陋"和"聚焦"：

"**MVP 不是粗制滥造，而是功能聚焦：**

❌ 粗糙的 MVP：Bug 多、界面丑、性能差
✅ 正确的 MVP：功能少、但质量高、体验好

**案例**：
- Dropbox MVP：只是一个演示视频，没有真实产品
- 结果：7万人排队等候，验证了需求
- 成本：3 天制作视频

**建议**：做一个小但精致的 MVP，核心功能打磨到位，比大而粗糙的产品更有价值。"

Summary of persuasion techniques

Technique	Description	Example
Let data speak	Show a time-cost comparison	"Complete features 4-6 weeks, MVP 1.5 days"
Reframe perception	An MVP is acceleration, not delay	"Discover mistakes in 3 days vs discover mistakes in 3 weeks"
Cite cases	Real failure cases	"70% of features users don't need"
Offer choices	Make users feel autonomous	"I'll give you two options, you decide"
Distinguish concepts	MVP ≠ rough	"Small and refined vs. large and rough"

Core Principles: Understand the user's real concerns (competitive pressure, time pressure, brand image), and persuade with data and logic, not preaching.

Common Rationalization Excuse Identification Table

When users reject an MVP for the following reasons, identify the underlying thinking pattern:

User says	Underlying rationalization	Essential issue	MVP response method
"This feature is very simple"	Underestimating complexity	Not considering subsystems or edge cases	List all subsystems (database, interface, frontend, testing) and show the real cost
"Competitors already have it"	FOMO (fear of missing out)	Imitation ≠ validation	Are the competitor's users the same as our users? First validate whether our users need it
"Users definitely need it"	Substituting assumptions for data	Intuition ≠ fact	Design a minimal experiment (half-day cost) and let the data speak
"Time is very tight"	Urgency masks risk	Fast ≠ right	MVP is acceleration, not delay: discovering a mistake in 3 days vs. 3 weeks
"Launch first, then iterate"	Delaying validation	Launching ≠ validating	If the direction is wrong, launching is a waste. First validate the direction with a fake door
"I know what users want"	Overconfidence	Survivorship bias	You asked active users, but what about the silent users? Test everyone with a fake door
"This is just a small feature"	Ignoring cumulative cost	Small feature × N = large system	Small features also need validation. Use a static implementation to test whether users will really click
"We have already planned it"	Sunk cost fallacy	High planning cost ≠ must implement	A plan is an assumption, not a fact. Validate the assumption at minimum cost

How to use:

Identify the user's type of rationalization (see column 2 of the table)
Understand the essential issue (column 3)
Apply the corresponding response method (column 4)
Persuade with data and logic, not emotional argument

Real-World Impact

Case: A social platform wants to develop a "direct message feature"

Traditional approach (without MVP thinking):

Development cost: 2 weeks (message storage, real-time push, read status, message list, sending interface)
After launch: usage rate among daily active users < 1%
Wasted: 2 weeks of development time + server resources

MVP approach:

Layer 0 (fake door): Place a "direct message" button on the profile page, and clicking it shows "feature in development" (cost: 30 minutes)
Observe for 3 days: click-through rate 0.3% → abandon development
Saved: 2 weeks of development time

Result comparison:

Metric	Traditional approach	MVP approach
Development cost	2 weeks	30 minutes
Learning cycle	2 weeks + 1 week	3 days
Resource waste	High	Extremely low

Quick Reference

User says...	MVP mindset response
"I want to build an XX feature"	"First make a fake door to see if users really want it"
"This feature is urgent"	"The fastest way to validate is: first build the simplest version to verify whether the direction is right"
"First implement the core feature"	"The core feature is also an assumption. Which assumption has the highest risk? Validate that one first"
"Users definitely need it"	"Validate with data. Design a minimal experiment that costs no more than half a day"
"Competitors all have this feature"	"Are the competitor's users the same as our users? First validate whether our users need it"

Red Flags - You're NOT Doing MVP

You are "cutting features" but haven't asked "what is the most core assumption"
Your MVP needs > 2 days of development time
You are planning database table structures instead of planning validation experiments
You are saying "launch first, then iterate" instead of "validate first, then invest"
Your MVP includes "infrastructure" such as review, filtering, permissions, etc.
You haven't defined the numerical criteria for successful validation

Seeing these signals → stop and rethink: what assumption am I validating?

References

The Lean Startup - Eric Ries (originator of the MVP concept)
Running Lean - Ash Maurya (practical MVP methods)
The Mom Test - Rob Fitzpatrick (how to validate demand)

Post-protocol

Artifact output

Save the MVP planning results to the artifact file:

TIMESTAMP=$(date +%Y%m%d-%H%M%S)
ARTIFACT_FILE="memory/artifacts/mvp-first/result-$TIMESTAMP.json"

cat > "$ARTIFACT_FILE" <<EOFJSON
{
  "skill": "mvp-first",
  "version": "2.0.0",
  "timestamp": "$(date -u +%Y-%m-%dT%H:%M:%SZ)",
  "project": "$PROJECT_ROOT",
  "branch": "$BRANCH",
  "commit": "$COMMIT",
  "input": {
    "user_request": "用户的原始请求"
  },
  "output": {
    "mvp_features": [],
    "non_mvp_features": [],
    "mvp_timeline": "",
    "key_assumptions": [],
    "validation_metrics": []
  },
  "next_skills": [
    "pdca-cycle"
  ]
}
EOFJSON

echo "ARTIFACT SAVED: $ARTIFACT_FILE"
ln -sf "$ARTIFACT_FILE" memory/artifacts/mvp-first/latest.json

Target file update

If the target file exists, record that MVP planning is complete.

Suggested follow-up skills

## 后续建议

基于 MVP 规划结果，建议继续执行：

**推荐技能链**：
1. /pdca-cycle - 进入 PDCA 循环实施阶段

是否继续执行？
- A) 执行推荐的技能链
- B) 不继续，结束当前任务

About this skill

Prerequisite Protocol

Environment Detection

Prerequisite Skill Check

Overview

When to Use

The MVP Mindset

Core Questions (Must Ask Before Implementation)

MVP is NOT

The Process

Step 1: Identify key assumptions

Step 2: Define validation goals

Step 3: Design the minimum experiment

Step 4: Implement and measure

Step 5: Analyze and decide

MVP Layers (layered validation)

Common Mistakes

1. ❌ "Keep the core features" is not an MVP

2. ❌ "Iterate after launch" is not an MVP

3. ❌ An MVP must be code

4. ❌ An MVP can delay launch

Handling User Pushback

Objection 1: "Competitors already have complete features"

Objection 2: "We're launching next week, no time for experiments"

Objection 3: "Users will definitely need this feature"

Objection 4: "Just give me the complete plan, I'll decide myself"

Objection 5: "The MVP is too crude, the user experience will be poor"

Summary of persuasion techniques

Common Rationalization Excuse Identification Table

Real-World Impact

Quick Reference

Red Flags - You're NOT Doing MVP

References

Post-protocol

Artifact output

Target file update

Suggested follow-up skills