如何确定第一版只做哪些功能
第一版产品最难的部分，不是决定做什么，而是决定不做什么。
几乎所有产品团队在规划第一版时，都会经历一个相似的困境：每个人都有自己的想法，每个想法看起来都有道理，每个人都觉得「这个功能用户肯定需要」。结果就是功能越加越多，上线时间越来越晚，等到产品终于面世时，团队发现自己花了三个月做了 20 个功能，却没有一个功能真正打中了用户的痛点。
这不是执行的问题，而是功能筛选方法的问题。
确定第一版功能范围，本质上是一个从「用户痛点」到「功能清单」的推导过程。它需要系统性的方法，而不是拍脑袋的决策。这篇文章会介绍从用户痛点反推功能的思路、功能筛选的框架、MVP 范围确定的步骤、以及功能取舍的决策方法，帮助你在第一版只做真正重要的事。
一、从用户痛点反推功能
很多团队规划功能的起点是「竞品有什么」。看到竞品的 A 功能，加上；看到 B 功能，也加上。这种做法的问题在于，你复制的是别人的答案，而不是别人解决的问题。
正确的起点是用户痛点。
痛点收集的四个渠道
在产品早期，你不可能做大规模用户调研，但你有四个成本很低的方式来收集痛点。
第一个渠道是用户访谈。 找到 5-10 个你认为可能使用你产品的人，和他们聊 30 分钟。不要问「你觉得这个产品应该有什么功能」，而是问「你现在是怎么解决这个问题的？过程中最让你头疼的是什么？」用户描述的具体场景和情绪，比他们给你的功能建议有价值得多。
第二个渠道是竞品评价。 去 App Store、G2、Product Hunt、Reddit 看用户对竞品的差评。差评里藏着的不是竞品的缺陷，而是用户未被满足的需求。当用户抱怨某个工具「太难用了」「步骤太多」「不支持某某场景」，你看到的是一个可以用更简单方式解决的机会。
第三个渠道是社区讨论。 在你的目标用户聚集的地方——Reddit 的特定 subreddit、Stack Overflow 的相关问题、Twitter/X 上的讨论串、行业论坛——搜索他们提出的问题。用户在社区里主动提出的问题，是最真实的痛点信号。
第四个渠道是自身经验。 如果你自己就是这个领域的用户，把你日常遇到的不便和低效记录下来。很多成功的产品起源于创始人自己的痛点——不是因为这种痛点一定比别人的更重要，而是因为你对它有第一手的理解。
从痛点到功能的推导
收集到痛点之后，不要直接跳到「做什么功能」。中间需要一个转换步骤：把痛点翻译成「用户想要完成的任务」。
比如，你收集到的痛点是「每次写周报都要翻聊天记录找素材，太费时间了」。这个痛点背后的任务不是「一个自动汇总聊天记录的 AI 工具」——这是功能方案。背后的任务是「快速生成一份完整的周报，不遗漏重要工作内容」。从任务出发，你才能考虑多种解决方案：也许是一个 AI 汇总工具，也许是一个工作日志系统，也许只是一个简单的模板。
这个区分很重要。直接从痛点跳到功能，你会锁定在第一个想到的方案上；从痛点到任务再到功能，你能看到更多的可能性。
二、功能筛选框架：用户价值 × 实现成本
有了潜在的功能清单之后，你需要一个筛选机制来决定哪些进入 MVP、哪些延后、哪些放弃。最实用的筛选工具是一个二维矩阵：用户价值（纵轴）和实现成本（横轴）。
理解两个维度
用户价值衡量的是这个功能对用户完成核心任务有多重要。判断标准不是「用户会不会觉得酷」，而是「没有这个功能，用户还能不能完成核心任务」。如果答案是「不能」，这个功能的价值就是高的。
实现成本衡量的是做这个功能需要多少时间和资源。它不仅包括开发时间，还包括设计、测试、第三方服务集成、维护成本等。一个简单的经验法则是用「人天」来估算——这个功能从开始到可用，需要几个人工作几天。
四象限分类
把两个维度交叉，你得到四个象限：
| 象限 | 用户价值 | 实现成本 | 决策 | 示例 |
|---|---|---|---|---|
| 第一象限：快速获胜 | 高 | 低 | 立即做 | 核心流程的必需步骤、用户明确提出的高频需求 |
| 第二象限：重大项目 | 高 | 高 | 拆分后做 | 复杂但必要的功能，需要找到最小实现方式 |
| 第三象限：锦上添花 | 低 | 低 | 有余力再做 | 辅助功能、美化类改进 |
| 第四象限：资源黑洞 | 低 | 高 | 不做 | 技术上很酷但用户不关心的功能 |
第一象限的功能直接放入 MVP。第四象限的功能直接砍掉。真正需要讨论的是第二和第三象限。
第二象限的功能——高价值但高成本——需要做的是拆分。问自己：这个功能的最简实现是什么？能不能只做 20% 的工作量，覆盖 80% 的场景？比如，「支持多种文件格式导出」是一个高成本功能，但 MVP 阶段也许只需要支持 PDF 导出。
第三象限的功能——低价值低成本——不要因为它们「很简单」就提前做。每一个功能都有成本，包括认知成本：界面多一个按钮，用户就多一个选择。MVP 阶段的界面应该是克制的。
价值-成本矩阵的实际应用
以一个 AI 写作助手为例，假设你在规划 MVP：
| 功能 | 用户价值 | 实现成本 | 象限 | MVP 决策 |
|---|---|---|---|---|
| 输入主题生成文章 | 高 | 中 | 第二象限 | 做（核心功能） |
| 文章导出为 Markdown | 高 | 低 | 第一象限 | 做 |
| 多语言翻译 | 中 | 高 | 第二象限 | 不做（延后） |
| AI 对话式修改 | 高 | 高 | 第二象限 | 拆分为简单的文本编辑 |
| 团队协作编辑 | 低 | 高 | 第四象限 | 不做 |
| 文章模板库 | 中 | 低 | 第三象限 | 不做（延后） |
| 生成历史记录 | 高 | 低 | 第一象限 | 做 |
| SEO 优化建议 | 低 | 高 | 第四象限 | 不做 |
最终 MVP 只保留了三个核心功能：生成文章、导出 Markdown、查看历史记录。这已经足够让用户完成「从想法到成稿」的完整流程。
三、确定 MVP 范围的四个步骤
功能筛选解决的是「单个功能做不做」的问题，但 MVP 范围确定还需要考虑功能之间的关联和整体体验。以下是四个具体步骤。
步骤一：定义核心假设
在列功能之前，先回答一个问题：「MVP 上线后，我需要验证的核心假设是什么？」
核心假设通常是一个关于用户行为的陈述，比如「当内容创作者发现 AI 可以快速生成初稿时，他们愿意付费使用这个工具」。你的 MVP 只需要包含验证这个假设所需的最少功能。如果核心假设是关于「用户愿不愿意用」，你不需要做支付系统；如果核心假设是关于「用户愿不愿意付费」，你就必须有支付流程。
步骤二：绘制用户旅程地图
从用户的视角，画出他完成核心任务的完整路径。以一个 AI 头像生成工具为例：
- 用户看到产品介绍（落地页）
- 用户上传一张照片
- 用户选择一种风格
- 系统生成头像
- 用户查看结果
- 用户下载头像
- 用户决定是否继续使用（注册/付费）
这条路径上的每一个步骤，都是一个必须解决的问题。但「必须解决」不等于「必须自己做」。有些步骤可以用最简单的方案：比如第 1 步可以用一个单页面，第 7 步可以先不做注册、用邮箱标识用户。
步骤三：识别最小功能集
在用户旅程的基础上，为每一步确定最小实现方案。最小实现的标准是：这一步的体验不至于让用户放弃整个流程。
| 用户旅程步骤 | 完整方案 | MVP 最小实现 |
|---|---|---|
| 落地页 | 精美的营销网站 | 一个简单的产品介绍页，说清楚产品是什么、怎么用 |
| 上传照片 | 支持多种格式、拖拽上传、预览裁剪 | 支持 JPG/PNG，基础的文件选择器 |
| 选择风格 | 20 种风格、实时预览 | 3 种风格，用示例图展示效果 |
| 生成头像 | 并行处理、进度实时显示 | 串行处理，显示加载动画和预计时间 |
| 查看结果 | 高清预览、对比原图、分享按钮 | 直接在页面显示结果图 |
| 下载头像 | 多种分辨率、多种格式 | 一种分辨率、一种格式 |
| 注册/付费 | 完整的账户系统 + 订阅支付 | 先免费使用，通过 email 收集用户信息 |
步骤四：验证闭环完整性
把步骤三的结果串起来，检查两件事：
第一，核心流程是否完整？从用户进入到最后获得价值，每一步都在吗？有没有断裂的地方？如果用户生成头像后无法下载，流程就断了。
第二，用户能否独立完成？找一个不了解产品的人，让他按照你的设计走一遍完整流程。如果他在某一步卡住了，那一步就是 MVP 需要额外投入的地方——不是加功能，而是加引导。
四、功能取舍的决策方法
当团队对某个功能该不该做争论不休时，你需要一个客观的决策方法。以下是四种常用的方法，各有适用场景。
MoSCoW 方法
MoSCoW 把功能分为四个等级：
| 等级 | 含义 | 判断标准 | 在 MVP 中的位置 |
|---|---|---|---|
| Must Have | 必须有 | 没有它产品就无法运行或无法验证核心假设 | 放入 MVP |
| Should Have | 应该有 | 很重要，但没有它产品仍然可以运行 | 尽量放入 MVP |
| Could Have | 可以有 | 锦上添花，有了更好 | 不放入 MVP |
| Won't Have | 不会有 | 当前版本明确不做 | 放入 backlog |
MoSCoW 的好处是简单直接，适合快速分类。它的局限是对「重要程度」的判断依赖团队共识，容易受个人偏好影响。
RICE 评分法
RICE 是一种量化评分方法，适合需要更客观决策的场景：
RICE 分数 = (Reach × Impact × Confidence) / Effort
- Reach（触达范围）：这个功能在一个时间段内能影响多少用户？
- Impact（影响程度）：对每个用户的影响有多大？（3 = 巨大 / 2 = 高 / 1 = 中 / 0.5 = 低 / 0.25 = 极低）
- Confidence（信心水平）：你对以上估计有多大把握？（100% = 高信心 / 80% = 中信心 / 50% = 低信心）
- Effort（工作量）：需要多少人月？
举例来说：
| 功能 | Reach | Impact | Confidence | Effort | RICE 分数 |
|---|---|---|---|---|---|
| 核心生成功能 | 100 | 3 | 80% | 2 人月 | 120 |
| 导出为 PDF | 80 | 2 | 100% | 0.5 人月 | 320 |
| 多语言支持 | 50 | 2 | 50% | 3 人月 | 16.7 |
| 社交分享 | 30 | 1 | 80% | 1 人月 | 24 |
RICE 分数的优势是把主观判断变成了可比较的数字。但要注意，数字的精确性是假象——如果你对 Reach 和 Impact 的估计本身不准确，算出来的分数也没有意义。RICE 的价值不在于绝对数字，而在于强迫你从多个维度思考每个功能。
Kano 模型
Kano 模型从用户满意度的角度来分类功能：
| 功能类型 | 含义 | 对用户的影响 | MVP 策略 |
|---|---|---|---|
| 基本型需求（Must-be） | 用户认为理所当然的功能 | 有之不喜，无之不满 | 必须做 |
| 期望型需求（One-dimensional） | 做得越好用户越满意 | 越多越好 | 选择性做 |
| 兴奋型需求（Attractive） | 用户没有预期但会觉得惊喜 | 有之大喜，无之不减 | 最多做 1 个 |
Kano 模型的实用价值在于提醒你：不是所有功能对用户体验的贡献都是线性的。有些功能做 60 分和做 100 分，用户感受差别不大；有些功能做到 80 分就能让用户惊喜。在 MVP 阶段，你应该优先满足基本型需求，然后有策略地加入一两个兴奋型需求。
User Story Mapping
User Story Mapping 是一种可视化方法，把用户活动、用户步骤和具体功能组织成一张地图。
它的结构是：
- 横轴：用户活动的流程顺序（从左到右）
- 纵轴：功能的优先级（从上到下）
- 分割线：MVP 的边界线，线上面是 MVP 要做的，线下面是不做的
这种方法的好处是让团队看到功能的全局关系，而不是孤立地讨论每个功能。当你看到某个功能在地图上处于流程的关键位置时，你就知道它不能省。
四种方法的对比
| 方法 | 适用场景 | 优势 | 局限 | 所需时间 |
|---|---|---|---|---|
| MoSCoW | 快速分类、团队对齐 | 简单直观，容易沟通 | 依赖主观判断 | 30 分钟 |
| RICE | 需要量化比较、资源有限 | 多维度量化，可追溯 | 估计值可能不准确 | 2-3 小时 |
| Kano | 关注用户满意度 | 区分不同类型的需求 | 需要用户调研数据 | 1-2 天（含调研） |
| User Story Mapping | 功能关系复杂、需要全局视角 | 可视化，关注用户旅程 | 需要较多团队协作 | 2-4 小时 |
五、两个案例
案例一：AI 证件照生成工具
一个独立开发者想做面向海外市场的 AI 证件照工具。他最初的功能清单有 12 项：上传照片、选择证件类型、AI 抠图换背景、美颜、排版、批量处理、照片审核、多尺寸导出、云端存储、社交分享、API 接口、多语言。
他先用用户价值 × 成本矩阵做了第一轮筛选：
| 功能 | 用户价值 | 成本 | 决策 |
|---|---|---|---|
| 上传照片 | 高 | 低 | 做 |
| 选择证件类型（美签/日签/申根） | 高 | 低 | 做（先做 3 种最常见的） |
| AI 抠图换背景 | 高 | 中 | 做 |
| 美颜 | 中 | 中 | 不做 |
| 排版 | 高 | 低 | 做（自动生成排版模板） |
| 批量处理 | 低 | 高 | 不做 |
| 照片审核 | 高 | 高 | 用第三方 API 替代 |
| 多尺寸导出 | 高 | 低 | 做 |
| 云端存储 | 低 | 中 | 不做（直接下载到本地） |
| 社交分享 | 低 | 低 | 不做 |
| API 接口 | 低 | 高 | 不做 |
| 多语言 | 中 | 中 | 先做英文 |
筛选后保留了 5 个核心功能。然后用 MoSCoW 做二次确认，确定「AI 抠图换背景」是唯一的 Must Have 技术难点，其余都是常规开发。
最终 MVP 上线时间从预估的 3 个月缩短到 6 周。上线后第一个月，4500 名用户使用，转化率 6%。用户反馈中最集中的需求是「增加更多证件类型」——这验证了团队最初的需求判断，也指明了下一步的迭代方向。
案例二：AI 会议纪要工具
一个三人团队想做面向远程团队的 AI 会议纪要工具。最初的讨论中，三个人的意见分歧很大：一个人想做实时协作编辑，一个人想做 AI 自动提取行动项，一个人想做多平台集成（Zoom/Meet/Teams）。
他们先用核心假设法对齐了目标：MVP 要验证的假设是「远程团队愿意使用 AI 工具来生成会议纪要，而不是手动整理」。基于这个假设，核心任务是「把一段会议内容变成一份结构化的纪要」。
然后用 User Story Mapping 梳理了用户流程：
- 用户上传会议录音或文本
- 系统生成结构化纪要（议题、结论、行动项）
- 用户查看和编辑纪要
- 用户导出或分享纪要
基于这个流程，他们做的决策是：
- 实时协作编辑 → 不做（MVP 不需要多人同时编辑）
- AI 自动提取行动项 → 做（这是核心价值，用户最头疼的就是整理行动项）
- 多平台集成 → 不做（先支持上传文件，不做实时接入）
- 编辑功能 → 做基础编辑（文本修改、调整段落），不做高级编辑
- 导出 → 做（支持 Markdown 和 PDF）
最终 MVP 只做了一件事：上传会议录音 → AI 生成带行动项的纪要 → 用户编辑 → 导出。开发周期 4 周，上线后有 30 个团队试用，其中 12 个团队使用了第二次。
六、从痛点到 MVP 功能清单的推导路径
这个流程的关键在于每一步都有明确的筛选标准，不是凭直觉做决策。从痛点到任务、从任务到功能、从功能到矩阵筛选、从筛选到用户旅程验证，每一步都在缩小范围，直到剩下的是真正不可少的部分。
七、常见陷阱
在确定 MVP 功能的过程中，有几个常见的陷阱值得警惕。
陷阱一：「万一用户需要呢」思维。 每当你因为害怕遗漏而加入一个功能时，问自己：「如果 MVP 上线后用户真的需要这个功能，最坏的后果是什么？」在大多数情况下，最坏后果是「用户在反馈中说希望有这个功能」，然后你在下个版本加上它。这不是失败，这是正常的迭代。
陷阱二：「既然做了就多做一点」思维。 当你已经在做某个功能时，很容易顺手加上一些「相关」的功能。比如已经在做注册了，「顺手」把密码找回、邮箱验证、社交登录都做了。这些「顺手」加起来，可能就是两三周的额外工作量。
陷阱三：技术驱动而非用户驱动。 「这个技术很新，我们试试」「这个架构更优雅，以后扩展方便」——这些理由在技术层面可能是对的，但在 MVP 阶段，你需要的不是最优雅的架构，而是最快的验证。如果用户根本不来，架构再优雅也没有意义。
陷阱四：把 MVP 当成最终产品来设计。 MVP 不需要考虑国际化、不需要考虑多端适配、不需要考虑完整的权限系统。这些是产品验证成功之后才需要解决的问题。
八、MVP 功能确定检查清单
在最终确定 MVP 功能清单之前，逐项检查以下内容：
- 能用一句话说清楚 MVP 要验证的核心假设
- 每个放入 MVP 的功能都能直接关联到一个用户痛点或核心任务
- 没有功能是因为「竞品有所以我们也要有」而加入的
- 没有功能是因为「技术上很有趣」而加入的
- 对于每个被砍掉的功能，团队能说出「为什么现在不做」的具体理由
- 核心流程从入口到结果是一个完整闭环，中间没有断裂
- 新用户能在 5 分钟内走完核心流程
- 用 MoSCoW 或 RICE 对所有功能做过优先级排序，且团队达成共识
- 高成本高价值的功能已经尝试过拆分，找到了最小实现方式
- 没有「顺手做」的功能——每个功能都是经过主动决策放入的
- MVP 的上线时间有明确预期，且不超过团队能承受的周期
- 已定义衡量 MVP 成功或失败的具体指标（注册数、使用率、付费率等）
- 团队对「如果 MVP 失败，下一步怎么办」有预案
九、写在最后
确定第一版功能范围，本质上是一种取舍能力。它要求你抵制住「多做一点」的诱惑，接受「少即是多」的现实。
在 AI 产品出海的语境下，这种取舍尤其重要。AI 技术能做的事情很多，但用户愿意为 AI 付钱的场景往往是具体而窄的。你的第一版产品不需要是一个无所不能的 AI 平台，它需要是一个在某一个具体场景下比现有方案好 10 倍的工具。
功能少不是缺点，功能多但每个都平庸才是。把有限的资源集中在真正能打动用户的功能上，做出一个虽小但锋利的第一版产品，然后让真实用户的反馈来指引你下一步的方向。
参考资料
- Eric Ries.《The Lean Startup》. Crown Business, 2011.
- Thoughtbot.「How to define and prioritize features for your MVP」. 2025. thoughtbot.com/blog/how-to-define-and-prioritize-features-for-your-mvp
- Eastern Peak.「Top 11 Methods to Prioritize Features for Your MVP」. 2025. easternpeak.com/blog/top-methods-to-prioritize-features-for-your-mvp
- Lemberg Solutions.「MVP Scope: How to Define Your Minimum Viable Product in 4 Steps」. 2024. lembergsolutions.com/blog/mvp-scope-how-define-your-minimum-viable-product-4-steps
- Toptal.「How to Define an MVP Scope in 3 Hours」. toptal.com/product-managers/product-leader/how-to-define-an-mvp-scope-in-three-hours
- Boundev AI.「How to Define Your MVP Scope: A Product Leader Framework」. 2026. boundev.ai/blog/mvp-scope-definition-guide
- Atlassian.「什么是最简可行产品（MVP）？如何入门」. atlassian.com/zh/agile/product-management/minimum-viable-product
- Ficode.「A Mini-Guide to Picking MVP Features」. ficode.com/blog/a-mini-guide-to-picking-mvp-features