如何确定是否有必要开发新功能

我和团队日常陷入最多的 hard discussion，可能就是产品功能做还是不做，以及 scope （界限）的问题。遇到这种问题，我经常变得激情澎湃，强势输出，观点们像是一个复杂机器产生的混合物，和平时写东西不一样，他们无组织，无纪律。😂

因为，“直觉”总是比结构化的表达要先出现：以至于很多时候经常出现一坨一坨的车轱辘话，或者让团队的小伙伴觉得我代表了什么鲜明的立场，容易陷入哲学大 battle。

写这篇文章的动机就是想整理一下在这个复杂机器里面，我的判断原则。都是源于个人经历一些非常原始的思考，不是什么 silver bullet。希望能给创业或者做产研 (Product, Eng, Design) 的小伙伴一些启发和思考的角度，我们也可以多多交流。

全文 4400 字，阅读需 12分钟。

在讨论范围内

✅ 创业团队构建从 0-1 的产品以及 GTM 策略，尤其出海

✅ 产品正在从 10-100 扩张，需要建立 product roadmap

✅ Product Lead 或者有规划职责的角色，需要及时识别机会

✅ 个人贡献者在大型组织中推动新项目 (New initiative)

不在讨论范围内

❌ 自上而下由 lead 或者 executive 发起模糊性很小的项目

❌ 离业务目标较远，验证个人或某个独立团队影响力的项目

❌ 以大客户为主，定制化非常强的产品需求

绝对一点来说，我甚至觉得聚焦是个 common sense，无论这个组织的大小。因为资源有限。

资源这里不指是 finacially 的资源，时间也是资源：这时间这一点上，无论创业团队还是大厂都是公平的。

在大多数情况下，我们都基于产品的 target user 范围内，做可拓展，符合我们客户画像最重要的功能：他需要是的是止痛药 (Pain killer) ，而不是维他命(Vitamin)。

做到聚焦，你就会发现，维持清晰的产品价值主张，提升顾客对其理解程度等其他一系列工作变得更加容易和自然。产品稳步走向它的 vision，以健康的方式逐步扩大解决的 problem space，自然有机地生长。

我们不是每一个问题都要解决，保持自己的观点，勇于 say no。

所以我来写一写“这个功能是否值得开发”不同类型的“信号”。

这个是我自创的概念哈哈，”表象“代表的是停留在表面的信号，距离判断是否值得推进这个功能，可以作为参考，但是离决策还有很远的距离。

竞品做了这个功能

先做一个肯定：最近喜欢看政治学，比较和类比是一种政治学研究方法，目的是为了获得”可能性“，这种广阔的视野的确会帮助获得洞察，所以搬到到我们现在讨论的场景，看多多的产品是很有意义的。

但是，熟悉我之前的文章的朋友都知道，我是一个及其抗拒并且反感依赖竞品分析做产品的人。大概是因为，“竞品做了这个功能，我们也要对齐且保持一致的解决方案”几乎成为了推项目的万金油：用战术和执行上的勤奋试图掩盖战略和思考上的懒惰，我相当抗拒和不齿。

从另一方面讲，如果真的要做竞品分析，我自己的习惯会在竞品故意没有做，但是我们要做的功能上谨慎一下。我们主观推演了场景合理，但是为什么竞品没有做呢？是它摆烂没有资源做，还是因为其他原因？其他原因可能包含：

1. 不符合他的价值主张

2. 不符合他的 target user

3. 公司资源有限，以及有不少 legacy

4. 不符合他的战略优先级

5. 当然，不要害怕面对一种可能：我们想多了…

所以竞品分析，他的价值点真的只是一个获得洞察的参考，并不能作为绝对的决策依据。最重要还是在这个竞品调研的过程中获得了哪些具体的 insights 去推动后续的假设，加速最后决策流程 —— 它只是决策中信息获得的一环而已。

运用逻辑和主观的推演场景存在

善于运用用户视角的人，依靠场景还原的思路的确能够进行一轮快速的验证，或者发掘出新场景。但是这个只是一个 hypothsis，还有很多后续的工作要做。

推演出的合理场景很多，如果仅依靠这一个原则，很容易在 PMF 之前把产品做成 all-in-one 的巨无霸，后续的迭代和修改都很被动。

一个简单的类比解法就是把每个推演出的用户场景当作一个创业项目，进行迷你版的 go-to-market 思考，去问自己一些 hard questions，这样可以帮助你带来一些多维度的判断，不仅仅是用户需求和用户体验。

高频用户反馈

高频用户反馈也经常沦为做功能和产品设计的圣旨，多年的蹂躏发现里面陷阱多多，后来我形成了这样的思路：

1. 第一步定义问题，反复 frame the problem。这个过程会有很多纠结， back and forth 和哲学争论，需要一定时间和精力。不要觉得这个过程没有意义，因为讨论过程中会发散和暴露出一些“冰山下潜在”的问题。我和团队之前非常容易在一个事情的对错和解决方案上争个不停，现在会比较有默契的定位我们各自觉得别扭和不舒服的点在哪里，这个过程是非常有价值的。

2. 第二步解决问题，原则是每一个场景只提供一种解决方案。一个典型现象：一个场景，解决方案有 A 有 B，比方说我们提供了 A，用户要 B 怎么办？有几种处理原则：

1. 最优情况，根据定义的问题，诊断是不是 A 真的有痛点，去看看 A 有没有优化空间。观察 A 优化完了，用户是不是还是那么想要 B。

2. 第二种情况，如果 B 只是一个 alternative，且 A 在体验和能力上之前没有遇到没有什么问题，那么大部分情况，置之不理，不去做调整甚至比瞎改都好。这一点在大公司很难做到，甚至会有各方利益者的压力，需要个人有专业判断和相应leadership的支持。但是，我们先去从事情的角度去分析：我们对于客户的敬畏不是无条件满足，而是深入理解问题，有选择地服务好我们最可以服务好的人，因为有一些客观因素我们无法解决：

1. 这个用户极有可能不是你的 target user

2. 这个场景不是核心场景。作为 problem solver，你当前还没有精力去解决它。

3. 用户提出了进阶需求。作为 problem solver，你当前还不够资格去解决它。

4. 用户在 hack 你的一些功能：把你的这个原本解决 A 问题的功能用来解决 B 问题。

识别这些陷阱很重要，不要为不值得的问题付出过度的精力。


3. 唯一需要重视的情况：B 反映出的场景真的是需求，而非作为 A 场景的方案二。在这种情况下，B 方案真的在解决“新诞生的一个问题”，且和我们的产品 vision 和 mission 强相关。
   

这个功能会让产品复杂

这并不是想说，我们因为这是一个复杂而具有挑战性的功能就拒绝解决，而是想要表达一个观点：如果你还相信，做企业服务类的产品注重产品体验，那么产品结构既“复杂全能”又要求“体验简单好用”是不可能的，忽略结构而追求体验属于刷流氓。

并且，复杂的产品带来的伤害是连锁反应，会让自助（Self- serve）变得困难，让 Time To Value 变久。

2B 的工具设计偏哲学一点来说：我理解是要和用户一起建立并养成 mental modal，而非解决单一的任务。这就要求产品架构可以拖得住并且预测用户的行为。产品之所以会变得复杂，往往是无视一致性和系统性的结构，见缝插针地塞需求，通过交互组件地拼凑，让流程跑得通，尽管考虑了很多 edge case，但我称之为“求生欲很强的产品“，而不是用户体验优秀的产品。

所以让产品复杂的功能，从需求到解决方案，都是一个糟糕的信号。

它无法 100% 地帮你 say no，但绝对是一个值得注意且需要明确 trade-off 的关键点。

这个功能会对产品的定位和 storytelling 有害

具体来说，就是做了不符合产品定位的功能：损害并模糊化产品形象。好比我们 Logto 做身份，身份还没做明白呢，后天加了一个分析的营销工具。

之前被 Intercom 的产品原则 inspire，Building product that’s opinionated by default, but flexible under the hood。

耗费大量资源但是难以评估以及感受到收益

其实这一点是非常站在公司和商业原则视角的，对于对专业有信仰的人可能会被冒犯到。几个典型的场景：

1. 某研发团队建立数据中台，提高工程效率

2. 某数据团队每年都要建立一个增长预测模型，但是却迟迟没有落地

3. 某设计团队推动品牌换新，遭遇产品和业务团队的不配合

这三种场景，如果出现在公司相对成熟稳定的运营状态下，是有价值的并需予以鼓励与支持。但是，当业务充满挑战，那么以上三件事不仅要耗费很大的资源，还需要花一定的时间去验证价值，这个事情的出发点就变成了对专业的执着追求，而非一个公司的商业成功，这一刻开始，价值观就出现了分歧。

这个现象一定程度上说明公司的商业目标，往往和个人追求和职业信仰，在特定的时间段内会存在难以调和的冲突。作为较大组织内的 IC，我们天然缺少信息和上位者的视角，对优先级的判断具有天然劣势，也难以和 leadership 产生真正的共鸣。

单纯从事情的角度看，主动推动项目的初衷是一件好事，但是也要清楚：拿着我的锤子找钉子，找完钉子之后，再拿一把尺子去量我的洞打得多深，我的半径打得多大，这件事在宏观上并不重要，但其实雇佣我打钉子的人，需要的只是一个可以挂住一幅画的方式而已，我不需要证明我打钉子打得有多专业。

和产品的 vision，roadmap 相一致

这个是一个很抽象和重要的点，有的时候很难让人有共鸣，如果我反复说 product vision，会给人假大空的感觉。但是最近我悟出了一个非常具像化的判断方式：当我们想要考虑做一个功能的时候，可以反问自己，和反问用户，如果我们的产品没有这个功能，用户会有多失望，他们会离开我们吗？

举例说明，我们的产品 Logto 当前的定位是解决 authentication + authorization + user/organization management 的问题，越是和这些紧密相关的 feature，优先级就越高。如果 Logto 没有这个功能，我们用户会有多失望？如果答案是模棱两可的，说明这个优先级不高。

有一定的验证结论和预测

硅谷喜欢做 User research 和 Opportunity sizing，这两点很能代表海外 2B 产品开发风格的务实和严谨。User research 用来验证推演需求，Opportunity sizing 用来预测结果和影响力。当一个功能具备这两个条件且有积极的结论时，说明这个功能值得尝试。

会赚很多的钱

2B 的最后的业务目标都会变成 ARR，无论是 PLG 还是 SLG，能够被量化的是非常直观的 revenue。所以不要拒绝这个积极的信号。

Why not?

这个 why not 又是我自己编的词哈哈。其实意思就是需要非常小的资源，简单，但是又能带来小的愉悦和收益，做了没坏处的功能。这些岁月静好的 why not feature，时间久了能够建立产品的 personality 和品牌效应。

这个功能是个创新点

上面所有的分析，都是理性的思考。但是我们要允许感性的存在。作为团队中最喜欢拉缰绳的人，大部分时间我都会 push 与我合作的人去思考上面一系列原则和哲学。

但是我也很清晰得表达我的态度，我信任你们对于开发者的理解和直觉，有的时候我们即时没有理性的数据支持，也没有现在市场的证明，如果你确信这就是未来，那我们就探索和做。有的时候我们需要允许一些灵性的发生。

如果还有其他无法归类的功能，那就暂且放回调研和探索阶段，让他自然生长，然后时刻观察信号。

其实在写这篇文章的过程中，我突然想起在做产品、创业环境和面试过程中，经常会被问到以下这些灵魂问题，尤其在硅谷。这些问题无论产品设计，产品经理，还是创业者，在 N 多个场合相信大家都会被问到或者刁难过。

• 我的产品在帮谁？Who will my product help?

• 那么然后呢，有什么价值？So what (for our customers, partners, etc.)?

• 为什么是现在？Why now?

• 为什么是这个方案？Why this? What options did you explore?

• 为什么是我们？Why us?

• 和我们战略相符吗？Does it align with our strategy?

• 我们怎么平衡长期和短期收益？How does it balance short and long-term benefits? Risk? Upside?

上文讨论的内容，部分覆盖了这些问题。这些问题答案，不是可以一统天下的原则或极度抽象本质真理，而是落到每一个产品非常接地气的执行决策和思维过程。如何拆解超级宏大和模糊性大的问题，并且从抽象落到具象，是每一个 builder 职业生涯长期修炼的能力。

希望上面的思路能够对你全面和具体地考虑一个功能做，还是不做，有一丢丢启发。抛砖引玉，欢迎与我交流哦。

相关历史文章

做工具设计的一些观点

什么时候需要抽象，什么时候需要具象

正文结束

---

我是一名在硅谷/北京的产品设计师 - 挂面(年少的我一面试就挂!)，是字节、Dropbox Growth、Yahoo、CMU Alumni。目前在创业，热爱表达，日常喜欢思考抽象和哲学。努力维持理性与感性的平衡中 :)