scoping-cutting

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Scoping & Cutting

项目范围规划与功能裁剪

Help the user scope projects and cut features effectively using frameworks from 15 product leaders.

借助15位产品负责人总结的框架，帮助用户合理规划项目范围并高效裁剪功能。

How to Help

如何提供帮助

When the user asks for help with scoping:

Understand the hypothesis - Ask what they're trying to learn or validate
Identify the appetite - Determine how much time/resources they're willing to invest
Find the essential core - Help them identify what must be present for the first version
Design for learning - Ensure the scope enables fast feedback, not just fast shipping

当用户请求范围规划相关帮助时：

明确核心假设 - 询问用户想要验证或学习的内容
确定资源投入意愿 - 了解用户愿意投入的时间/资源上限
锁定核心必备功能 - 帮助用户识别第一版本必须包含的内容
为验证学习设计方案 - 确保规划的范围能够快速获取反馈，而非仅仅追求快速交付

Core Principles

核心原则

Use appetite, not estimates

以投入意愿为基准，而非估算时长

Ryan Singer: "We're going to go the other way around and we're going to say, what is the maximum amount of time we're willing to go before we actually finish something?" Set a fixed time budget (appetite) and design a version of the solution that fits within it. Vary scope, not deadlines.

Ryan Singer：“我们要换个思路，先确定‘我们最多愿意投入多少时间来完成这件事？’”设定固定的时间预算（投入意愿），并设计一个能在该预算内完成的解决方案版本。调整范围，而非截止日期。

MVP is a validation tool

MVP是验证工具

Eric Ries: "MVP is simply for whatever the hypothesis is that we're trying to test, what is the most efficient way to get the validation we need about whether a hypothesis is true or not?" An MVP is not a low-quality product - it's the most efficient way to test a specific hypothesis.

Eric Ries：“MVP的本质是，针对我们要测试的假设，找到最高效的方式来验证该假设是否成立。”MVP不是低质量产品——它是验证特定假设的最有效途径。

Cut the list in half, then half again

把功能列表砍半，再砍半

Eric Ries: "Write out the list of features that are necessary in your MVP. Cut it in half and cut it in half again and build that." Founders consistently overestimate what's "minimum." Aggressive cutting is required to reach a true baseline.

Eric Ries：“列出你认为MVP必备的所有功能。把列表砍半，再砍半，然后开发这个精简后的版本。”创始人往往会高估“最小”的范畴。必须大幅裁剪才能达到真正的基础版本。

Fixed time, small teams

固定时间，小团队协作

Jason Fried: "Our appetite for any individual feature is no more than six weeks... So we have to figure out the simplest, most effective version of that to get that done within six weeks and get it done by two people." Constraints force creative solutions. Limit team size to maintain focus.

Jason Fried：“我们对任何单个功能的投入意愿都不超过六周……所以我们必须找到该功能最简单、最有效的实现方式，由两个人在六周内完成。”约束条件会催生创新解决方案。限制团队规模以保持专注。

Build the scooter, not the axle

先做滑板车，而非车轴

Eeke de Milliano: "If you're trying to build the minimum viable product for a car, don't build just the wheels and the axle, build the scooter first." An MVP should be a functional, end-to-end version of a smaller value proposition, not an incomplete piece of a larger one.

Eeke de Milliano：“如果你要为汽车打造最小可行产品，不要只做车轮和车轴，先做滑板车。”MVP应该是一个功能完整、端到端的小型价值主张版本，而非大型产品的不完整组件。

Use Wizard of Oz testing

采用“绿野仙踪”测试法

Crystal W: "It's really this Wizard of Oz experience. We don't have to build anything. I coordinated with a bunch of interns and we were able to validate some of the value prop." Validate value propositions manually before investing in engineering. Use humans to simulate automated features.

Crystal W：“这其实就是‘绿野仙踪’式的体验。我们不需要开发任何东西。我和一群实习生协作，就验证了部分价值主张。”在投入工程开发前，先手动验证价值主张。用人工模拟自动化功能。

Kill projects that don't finish in time

终止未按时完成的项目

Jason Fried: "If there's any work that's left over that's still on the left side of the hill, meaning we're still pushing it up, we don't know how we're going to do it and we're at our time limit, it almost certainly dies." Let projects die if they aren't completed within their allotted time to prevent never-ending work.

Jason Fried：“如果任何工作在时间截止时仍处于推进阶段——意味着我们还不知道如何完成它，那这个项目几乎肯定会被终止。”如果项目未能在分配的时间内完成，就让它终止，避免无休止的工作。

Build the option to pivot into the process

在流程中加入转向选项

Paige Costello: "We added into our product process a notion that we might pivot or cut from stuff that we put on our roadmap because it felt like once it was on the roadmap, it had to be done." Formalize the ability to cut or pivot from roadmap items to avoid the sunk cost fallacy.

Paige Costello：“我们在产品流程中加入了可以转向或裁剪 roadmap 内容的机制，因为一旦内容被列入roadmap，大家就会觉得必须完成。”正式明确裁剪或转向roadmap内容的权限，避免沉没成本谬误。

Questions to Help Users

用于引导用户的问题

"What's the single hypothesis you're trying to validate with this version?"
"What's the maximum time you're willing to invest before shipping something?"
"What would you cut if you had to ship in half the time?"
"Is there a way to test this manually before building automation?"
"If this feature doesn't ship in time, will you kill it or extend?"
"What's the smallest thing that still delivers complete value?"

“你希望通过这个版本验证的核心假设是什么？”
“你在交付前最多愿意投入多少时间？”
“如果必须在一半时间内交付，你会裁剪哪些内容？”
“有没有办法在开发自动化功能前先手动验证？”
“如果这个功能未能按时交付，你会终止它还是延长截止日期？”
“能提供完整价值的最小功能是什么？”

Common Mistakes to Flag

需要指出的常见错误

Estimating instead of time-boxing - Asking "how long will this take?" instead of "what can we do in X weeks?"
Building the axle - Shipping incomplete parts of a larger feature instead of complete smaller features
Never killing projects - Extending deadlines instead of cutting scope or canceling
Over-engineering the MVP - Building too much before testing the core hypothesis
Ignoring the Wizard of Oz - Always defaulting to building when manual validation would be faster

估算时长而非时间框定 - 问“这需要多久？”而非“我们在X周内可以完成什么？”
只做车轴 - 交付大型功能的不完整组件，而非完整的小型功能
从不终止项目 - 延长截止日期而非裁剪范围或取消项目
MVP过度设计 - 在验证核心假设前开发过多内容
忽略“绿野仙踪”测试法 - 总是默认开发，而手动验证会更快

Deep Dive

深入了解

For all 19 insights from 15 guests, see

references/guest-insights.md

如需获取15位嘉宾分享的全部19条见解，请查看

references/guest-insights.md