做出人们真正需要的东西本质上不需要花很长的开发时间，拖慢产品团队的可能是其他因素：繁琐的流程、决策者与执行者之间的距离、冗长的规格说明等。
Ned O'Leary 是 SSOReady（YCW24） 联合创始人兼 CEO，近期他在博客字分享了公司如何通过减少需求、简化设计、快速迭代和购买现成解决方案来提高产品开发速度的经验和方法。
我们对作者制定的产品快速迭代的基本原则做了整理和翻译，希望可以给到大家一些思考和启发，原文内容可以通过点击「阅读原文」链接进行查阅。
01 少即是多
在产品迭代的过程中，速度和质量之间存在权衡。大多数时候，如果要求速度更快，那么在质量上就需要一些妥协，两者之间，总有某个环节会被削减。
但并不一定所有产品需求都要一视同仁。我们可以取消一些不那么重要的需求，让工程师做更少的事情，解决核心的问题。当产品需求变得明确，并限制在一定的范围内，工程师通常可以更加快速构建出高质量的代码。
大多数公司会设定需求、确定截止日期，并将质量视为结果。我们倾向于反其道而行之。问自己，在给定的质量标准下，我们能在 60 天内交付什么？
02 简单方案通常更有效
我们非常喜欢“ midwitmeme ”这张图所表述的含义。简单地说，midwitmeme 这张图展现的是一个智商不高的白痴和一个天才在一个简单的解决方案上达成一致，而一个智力正常的人却在抱怨问题的复杂性，设想各种完美的解决方案。
在公司成立初期，我们挑战自己尽可能用“傻瓜”模式运作。当我们犯错时，通常是因为过度思考。我们常常通过问自己“如果我是个傻瓜，我会怎么做”来找到可行的解决方案。
03 专注于真正重要的问题
只有少数问题是非常重要的。例如，我们必须非常认真地对待安全问题。绝对不能在这方面偷工减料。但我们可以选择忽略某些其他不那么重要的事情。例如，我们知道我们的前端页面在移动设备上看起来不太好。可预见的未来，我们只需要客户不要在移动设备上使用即可，没有人真正介意。
显然，我们希望软件在各个地方都看起来很棒，但我们选择不在PC 端的布局上花费更多时间。我们也绝不会在近期内推出页面的暗黑模式耽误我们核心问题的进展。
04 把产品直接做出来
我们没有产品开发流程。我们不做 Figma 原型图，不写产品需求文档，没有设计系统，不搞敏捷开发，也没有OKR（目标与关键成果）。我们甚至没有一个明确的产品路线图，当然，我们也没有A/B测试。
最重要的是把产品先做出来，看看人们是否喜欢，然后再根据用户的反馈快速迭代或改进产品功能。
05 必要时重构产品
当产品存在很多遗留的代码问题时，大多数公司通常认为，如果尽可能推迟代码重构的时间，他们会进展的更快。这有时是奏效的，但在适当的时候，我们更愿意对代码进行重大重写以处理历史遗留问题。
我们认为构建正确产品的最快路径是这样的：
写了错误的代码 意识到它是错误的代码 用正确的代码替换错误的模块
06 付费选择外包服务
在某些情况下，我们会选择从外包服务商那里购买产品解决方案，而不是自己在内部构建。例如，我们使用一家名为 Fern 的供应商来生成我们的 SDK，他们做得相当不错。当然，使用外包服务会有显著的前期成本，这些服务通常很昂贵，也会一定程度上限制我们的自由。
考虑到我们的工程师成本，付费选择外包服务通常是正确的选择。我们的工程资源非常有限，而且非常昂贵，一个工程师一周的时间成本大约是 5000 美元，相比于自己研发服务商已经做的成熟的东西，我们会考虑把工程师的时间花在其他更有价值的事情上。
07 团队不要轻易招人
公司 CEO 不要指望增加人手就能提高团队的产出。公司人员招聘是一个既缓慢又困难的过程，入职培训和人员管理都需要耗费大量时间。即使是已经适应公司文化的员工，大量的人员协作起来也会带来更多的额外成本。因此，尽管我们有足够的资源组建一支庞大的工程团队，但我们还是尽一切可能保持小规模。这让我们的工作和生活都变得更加轻松。
08 总结全文
在过去，我们并没有清晰地意识到产品开发其实不应该花费太长时间，为此走了很多弯路。作为一只创业团队，我们需要专注于产品中真正重要的问题，避免不必要的复杂性，这是实现产品快速交付的关键。
📮 更多阅读
