mvp-planning

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

MVP Planning

MVP规划

Overview

概述

An MVP is not a product with every feature you can imagine stripped down. It is the smallest thing you can build that tests your core business hypothesis and delivers real value to real customers. If you build too much, you waste time on features nobody asked for. If you build too little, you launch something that doesn't actually solve the problem. This playbook defines the line precisely and gives you a repeatable process to find it.

MVP并非是砍掉所有你能想到的功能后的产品，而是你能构建的最小体量产品，它可以验证你的核心商业假设，并为真实客户交付实际价值。如果开发过多功能，你会在没人需要的功能上浪费时间；如果开发过少，你发布的产品将无法真正解决问题。本指南明确界定了这个边界，并为你提供一套可重复的流程来找到这个平衡点。

Step 1: Restate Your Core Hypothesis

步骤1：重述你的核心假设

Before scoping anything, write down the single hypothesis your MVP must test. Everything you include must serve this hypothesis. Everything that doesn't gets cut.

Format:

IF we build [specific product that does X for Y customers],
THEN [specific outcome we expect — e.g., Z% will pay, W% will return weekly].

Example: "IF we build an automated client progress report tool for freelance developers, THEN at least 30% of beta users will use it weekly within the first month, and at least 10% will convert to a paid plan."

The hypothesis has two parts: a behavior signal (usage) and a revenue signal (payment). Both must be measurable. If you can't measure it, you can't learn from it.

在确定任何范围之前，写下你的MVP必须验证的唯一假设。所有包含的功能都必须服务于这个假设，不相关的全部砍掉。

格式：

IF we build [specific product that does X for Y customers],
THEN [specific outcome we expect — e.g., Z% will pay, W% will return weekly].

示例： “如果我们为自由开发者构建一款自动化客户进度报告工具，那么至少30%的测试用户会在第一个月内每周使用它，且至少10%的用户会转化为付费用户。”

这个假设包含两部分：行为信号（使用情况）和收入信号（付费情况）。两者都必须可衡量。如果无法衡量，你就无法从中学习。

Step 2: Define What "Viable" Means for Your Specific Situation

步骤2：定义你的特定场景下“可行”的含义

"Viable" is not universal. It depends on your hypothesis. Map your hypothesis to the minimum experience needed to test it.

Ask these questions:

What is the absolute minimum a customer needs to experience to decide "this is valuable" or "this is not"?
What is the one core interaction that delivers the value proposition?
What can be manual, ugly, or missing and still test the hypothesis? (These things get cut or faked.)
What CANNOT be missing without the product feeling broken or useless? (These are non-negotiable.)

Label every feature as:

🔴 Must-have: Product is meaningless without this. Hypothesis cannot be tested without it.
🟡 Nice-to-have: Improves experience but hypothesis can still be tested without it.
🟢 Cut: Not needed for the hypothesis at all. Build later if validated.

“可行”并非通用概念，它取决于你的假设。将你的假设映射到验证它所需的最低体验。

思考这些问题：

客户需要体验到什么最基础的内容，才能判断“这有价值”或“这没用”？
哪一个核心交互能传递价值主张？
哪些功能可以手动实现、做得粗糙或缺失，但仍能验证假设？（这些功能将被裁剪或模拟实现）
哪些功能绝对不能缺失，否则产品会显得破碎或无用？（这些是必不可少的）

为每个功能标记：

🔴 必备功能： 没有它产品就毫无意义，无法验证假设。
🟡 锦上添花功能： 能提升体验，但没有它仍可验证假设。
🟢 裁剪功能： 完全与假设无关，验证通过后再考虑开发。

Step 3: Feature Ruthless-Cutting

步骤3：功能严格裁剪

Take your full feature wishlist and run every item through this filter. Be brutal. Solopreneurs have limited build time — every unnecessary feature is time stolen from the core value.

The Four Cuts:

拿出你的完整功能愿望清单，用以下过滤器逐一筛选。要狠下心来。个体创业者的开发时间有限——每一个不必要的功能都是从核心价值上偷走的时间。

四个裁剪原则：

Cut 1: The Hypothesis Cut

裁剪原则1：假设裁剪

Does this feature directly serve testing your core hypothesis?

Yes → Keep (for now, pending further cuts)
No → Cut. No exceptions.

这个功能是否直接服务于验证你的核心假设？

是 → 暂时保留（待后续进一步裁剪）
否 → 裁剪，没有例外。

Cut 2: The "Fake It" Cut

裁剪原则2：“模拟实现”裁剪

Can this feature be faked or done manually for the first N customers without them knowing or caring?

Examples of things you can fake:

A "dashboard" that's actually a shared Google Sheet for your first 10 customers
"Real-time" updates that are actually sent on a 1-hour delay
"AI-powered" recommendations that are actually you manually curating them for beta users
An "API integration" that's actually a scheduled script running every few hours

If you can fake it convincingly for beta scale, fake it. Build the real version only after you've confirmed people actually want it.

对于前N个客户，这个功能是否可以被模拟实现或手动完成，且客户不会察觉或在意？

可模拟实现的示例：

所谓的“仪表板”实际上是给前10个客户使用的共享Google Sheet
“实时”更新实际上是每小时发送一次延迟消息
“AI驱动”的推荐实际上是你为测试用户手动整理的内容
“API集成”实际上是每几小时运行一次的定时脚本

如果在测试阶段你能令人信服地模拟实现它，那就这么做。只有在确认人们确实需要它之后，再开发真实版本。

Cut 3: The Sequencing Cut

裁剪原则3：排序裁剪

Is this feature something that MUST exist at launch, or can it be added in v1.1 (within 2 weeks of launch)?

If it can wait 2 weeks and the product is still usable and testable without it → cut it from MVP scope. Move it to "Week 2" backlog.

这个功能必须在发布时就存在吗，还是可以在v1.1版本（发布后2周内）添加？

如果它可以推迟2周，且没有它产品仍可使用和验证 → 从MVP范围中裁剪，移至“第2周”待办事项。

Cut 4: The Delight Cut

裁剪原则4：愉悦感裁剪

Is this feature a "delight" — something nice but not expected?

Delights are great for retention but terrible for MVPs. Cut them all. Your MVP should be functional and clear, not delightful. Delight is a v2 luxury.

After all four cuts, you should have a dramatically smaller feature list than you started with. If it still feels like a lot, cut again. The most common MVP mistake is building too much.

这个功能是“愉悦感”功能——不错但非必需的功能吗？

愉悦感功能对留存很有帮助，但对MVP来说是大忌。全部裁剪。你的MVP应该实用、清晰，而不是带来愉悦感。愉悦感是v2版本的奢侈品。

经过这四个裁剪原则后，你的功能列表应该比最初大幅缩减。 如果仍然觉得很多，继续裁剪。最常见的MVP错误就是开发过多功能。

Step 4: Define Your MVP Scope Document

步骤4：定义你的MVP范围文档

Write a single-page document that locks the scope. This prevents scope creep and gives you a clear "done" line.

MVP SCOPE DOCUMENT
==================

HYPOTHESIS: [from Step 1]

CORE VALUE DELIVERED: [one sentence — what the user gets]

MUST-HAVE FEATURES (🔴):
  1. [Feature] — because [why it's essential to the hypothesis]
  2. [Feature] — because [why]
  3. [Feature] — because [why]

FAKED / MANUAL FEATURES (🟡 deferred to real implementation):
  1. [Feature] — faked as [how] — real build in [when]
  2. [Feature] — faked as [how] — real build in [when]

CUT FROM MVP (🟢 — revisit after launch):
  1. [Feature]
  2. [Feature]
  ...

LAUNCH CRITERIA (all must be true before you call this "launched"):
  - [ ] [Criterion 1]
  - [ ] [Criterion 2]
  - [ ] [Criterion 3]

WHAT SUCCESS LOOKS LIKE (measured in the first 30 days):
  - [Metric 1]: target = [number]
  - [Metric 2]: target = [number]

撰写一份单页文档来锁定范围。这可以防止范围蔓延，并为你明确“完成”的界限。

MVP SCOPE DOCUMENT
==================

HYPOTHESIS: [from Step 1]

CORE VALUE DELIVERED: [one sentence — what the user gets]

MUST-HAVE FEATURES (🔴):
  1. [Feature] — because [why it's essential to the hypothesis]
  2. [Feature] — because [why]
  3. [Feature] — because [why]

FAKED / MANUAL FEATURES (🟡 deferred to real implementation):
  1. [Feature] — faked as [how] — real build in [when]
  2. [Feature] — faked as [how] — real build in [when]

CUT FROM MVP (🟢 — revisit after launch):
  1. [Feature]
  2. [Feature]
  ...

LAUNCH CRITERIA (all must be true before you call this "launched"):
  - [ ] [Criterion 1]
  - [ ] [Criterion 2]
  - [ ] [Criterion 3]

WHAT SUCCESS LOOKS LIKE (measured in the first 30 days):
  - [Metric 1]: target = [number]
  - [Metric 2]: target = [number]

Step 5: Build vs. Buy Decisions

步骤5：自研vs外购决策

For every piece of technology your MVP needs, decide: build it yourself, buy/use an existing tool, or use a no-code/low-code solution.

Decision framework:

If this is...	Then...
Your core differentiator	BUILD. This is what makes you unique. Outsourcing it = outsourcing your advantage.
Commodity infrastructure (hosting, payments, auth, email)	BUY. Use established tools (Stripe, Auth0, SendGrid, Vercel, etc.). Building these yourself wastes months.
A workflow you'll do 100+ times but isn't your core product	AUTOMATE with no-code (Zapier, Make, n8n). Build only if the automation tools can't handle it.
Something you need once or very rarely	BUY or use a freelancer. Don't build a tool you'll use once.

Solopreneur rule: The fewer custom-built components, the faster your MVP ships. Ruthlessly use existing tools for everything except the one thing that is uniquely yours.

对于MVP所需的每一项技术，决定：自研、购买/使用现有工具，还是使用无代码/低代码解决方案。

决策框架：

如果这是...	那么...
你的核心差异化优势	自研。这是你的独特之处，外包它就等于外包你的竞争优势。
通用基础设施（托管、支付、认证、邮件）	外购。使用成熟工具（Stripe、Auth0、SendGrid、Vercel等）。自研这些会浪费数月时间。
你会重复100次以上但不属于核心产品的工作流	用无代码工具（Zapier、Make、n8n）自动化。只有当自动化工具无法处理时才自研。
你只需要一次或极少使用的功能	外购或雇佣自由职业者。不要为只用一次的工具自研。

个体创业者规则： 自定义组件越少，你的MVP发布得越快。除了你的核心独特功能外，尽可能使用现有工具。

Step 6: Estimate and Schedule the Build

步骤6：估算并规划开发进度

For each must-have feature, estimate:

Build time (hours — be honest, then add 50% buffer)
Dependencies (does feature B require feature A to be done first?)
Complexity risk (is there a part you're unsure about? Build that part FIRST to de-risk)

Build order rules:

Build the riskiest technical piece first. If it turns out to be impossible or takes 3x longer, you want to know now — before you've built everything around it.
Build the core value loop second. This is the single interaction that delivers your value proposition. Everything else connects to this.
Build supporting features last. Auth, onboarding copy, polish — these come after the core works.

Timeline:

Set a hard launch date (create external pressure — tell someone, set up a waitlist).
Work backward from launch date to today. Does the build time fit?
If it doesn't fit, cut more features (back to Step 3) or extend the date. Do NOT compromise on the core value loop to hit an arbitrary deadline.

为每个必备功能估算：

开发时间（小时 — 如实估算，然后增加50%的缓冲时间）
依赖关系（功能B是否需要先完成功能A？）
复杂度风险（是否有你不确定的部分？优先开发这部分来降低风险）

开发顺序规则：

优先开发技术风险最高的部分。如果它被证明不可行或耗时是预期的3倍，你希望现在就知道——而不是在围绕它开发完所有其他功能之后。
其次开发核心价值循环。这是传递价值主张的唯一核心交互，所有其他功能都围绕它展开。
最后开发辅助功能。认证、引导文案、优化——这些都要在核心功能正常工作之后再做。

时间线：

设置一个明确的发布日期（制造外部压力 — 告诉别人，建立等待列表）。
从发布日期倒推到现在。开发时间是否足够？
如果不够，继续裁剪功能（回到步骤3）或延长日期。不要为了达到一个随意的截止日期而妥协核心价值循环。

Step 7: Launch Criteria Checklist

步骤7：发布标准检查表

Step 8: Post-Launch Learning Loop

步骤8：发布后学习循环

The MVP is not the end — it is the beginning of a learning loop.

Week 1 post-launch:

Talk to every single early user. Not a survey — a real conversation. What confused them? What delighted them? What did they expect that wasn't there?
Watch them use the product if possible (screen share, session recordings). Where do they hesitate? Where do they drop off?

Week 2-4:

Measure your success metrics (from the scope document). Are you on track?
Identify the single biggest gap between what you built and what users actually need.
Decide: iterate on the current MVP, or pivot the hypothesis?

Decision rules:

If usage metrics are strong but revenue is weak → pricing or conversion problem. Iterate on that.
If usage metrics are weak → the core value isn't landing. Potentially a pivot situation.
If both are strong → you have product-market fit signals. Scale up (more users, more marketing, more features).

MVP不是结束——而是学习循环的开始。

发布后第1周：

和每一位早期用户交流。不是调查——是真实的对话。他们对什么感到困惑？什么让他们满意？他们期待但没有得到的是什么？
如果可能，观察他们使用产品（屏幕共享、会话录制）。他们在哪些地方犹豫？在哪些地方流失？

发布后第2-4周：

衡量你的成功指标（来自范围文档）。你是否按计划推进？
找出你构建的产品与用户实际需求之间最大的差距。
决定：迭代当前MVP，还是调整假设？

决策规则：

如果使用指标良好但收入指标不佳 → 定价或转化问题。对此进行迭代。
如果使用指标不佳 → 核心价值未落地。可能需要调整方向。
如果两者都良好 → 你获得了产品-市场匹配的信号。扩大规模（更多用户、更多营销、更多功能）。

MVP Mistakes to Avoid

需避免的MVP误区

Building features because they're fun to build, not because they test the hypothesis.
Launching to your friends first. Friends are too polite to give useful feedback. Launch to strangers.
Perfecting the UI before confirming the value. A ugly product that solves a real problem beats a beautiful product nobody needs.
Treating the MVP as the final product. It isn't. It's a learning machine. Expect to rebuild 60-80% of it in v2.
Not shipping. The best MVP is a shipped MVP. An unshipped MVP teaches you nothing.

开发功能是因为开发起来有趣，而不是因为它能验证假设。
首先向朋友发布。朋友太客气，不会给出有用的反馈。向陌生人发布。
在确认价值之前就完善UI。一个能解决真实问题的丑陋产品，胜过一个没人需要的精美产品。
把MVP当成最终产品。它不是。它是一个学习工具。预计在v2版本中会重写60-80%的内容。
不发布。最好的MVP是已发布的MVP。未发布的MVP无法教会你任何东西。