At the early stages, it’s especially important to scope projects. Design projects so that they can be completed in 1–3 weeks with a team of 1–3 people. Smaller fixes or additions should take only hours or a day.
在早期阶段，明确项目范围尤为重要。设计项目时，应使其能在 1-3 周内由 1-3 人的团队完成。较小的修复或补充应该只需要几个小时或一天。
Shorter projects force you to prioritize the most important feature set. They also get you into the habit of shipping continuously, which creates quick feedback loops with customers. Smaller teams help you move faster and reduce the management and communication overhead. When you’re early in the product building stage, you don’t know enough to predict whether a project will be impactful or not so it’s better to avoid massive projects. If there is no way to scope down the project, then break it down into stages.
较短的项目迫使你优先考虑最重要的功能集。它们还能让你养成持续交付的习惯，从而与客户形成快速反馈。较小的团队可以帮助你更快地前进，并减少管理和沟通的开销。当你在产品的早期阶段，你无法预测一个项目能产生多少影响，所以最好避免大规模项目。如果没有办法缩小项目范围，那就把它分解成几个阶段。
For example, we shipped the first versions of Cycles and Projects in the first couple of months of starting Linear. The MVP version of both of these features took us about two weeks to design and build. We shipped the early versions to ourselves and private beta users in the first week and started collecting user feedback immediately and fixing them in the following weeks. We’ve made a lot of improvements to Cycles and Projects since and both of them are now the major features of the product.
例如，我们在启动 Linear 的头几个月里就交付了 Cycles 和 Projects 的第一个版本。这两个功能的 MVP 版本花了我们大约两周的时间来设计和实现。我们在第一周就向自己和内测用户上线了早期版本，并立即开始收集用户反馈，在随后的几周内对其进行修复。此后我们对 Cycles 和 Projects 进行了大量的改进，现在这两个功能已经成为产品的主要功能。