不知不觉正儿八经做产品两年多了，title 也从「顾问」变成「经理」了。但是说来惭愧，似乎从来没好好复盘过。所以决定小诹一文，回顾一下自己踩过的坑，和一些不成体系的感悟。

1 场景，场景，还是场景

在做产品初期需求评审的时候，boss 经常会打断我，问我一些问题：为什么做这个功能？为什么要这么做？核心业务流程和场景是什么？有没有更好的方案？

我时常会被问的捉襟见肘，回答也经常被质疑。几经磨练后，我悟出一个道理：要立足于真实的场景去看需求。对于 PM 来说，可能「需求」是最重要的东西，然而所有需求都是基于用户场景的——用户是在什么场景下、如何使用你的产品，是产品设计师必须不断思考和牢记于心的一件事。

以那个著名的马和汽车的故事来说，其本意是想讲挖掘用户真正的潜在需求，但是仔细审视一下，这是一个典型的将「需求」和「场景」剥离的案例。

举例来说，有个用户来到马厩，说要在明天前赶往某地，需要一匹比平常更快的马。你总不至于说，好的，我们理解您的深层需求，请您耐心等待十年，我们会研发出一种叫「汽车」的机械载具，来满足您的需求。

当然，和缺少背景的原故事一样，这只是一种寓言式的简单叙述。实际的情况，往往比这要更复杂。

我之前做过一个客服知识库的项目，业务提出说，在服务客户时，客服如果要查询知识库内容，需要切出操作页面，在新页面中打开知识库，搜索内容。为了提升客服处理效率，想在客服操作页面上，集成一个查询插件，方便他们搜索。

于是我们做了这个功能，但是上线一段时间后，发现使用量寥寥无几，更别提效率提升了。去现场调研后，我发现客服通常会将知识库的页面常驻一个标签页，遇到问题会非常顺手地切过去检索。在与顾客通话过程中，点开和使用区域较小的查询插件，反而会影响他们的操作效率。

而之所以会产生这样的问题，是因为我错误地理解了需求的真实场景，把「客服切出操作页面」的场景和「提供查询插件」的方案建立了因果关系。

实际上这个需求，真实的场景是：客服在操作页面上，遇到了某些无法获取答案的「问题」，导致需要切出页面检索信息。那很显然，找到这些「问题」，在操作页面上提供相关信息，才是正解。问题是错的，自然给不出正确的答案。

至于如何把握真实的场景呢，没有什么捷径，只能实地去体验，去做场景观察和调研。不过当然，充足的经验多少也能保证方向上的正确。

2 MVP不是造轮子

两年时间里，我做过最为失败的一个项目，是一个业务自动排班系统。

业务方对系统的预期很高，希望实现的功能，包括对小时业务量的预测、满足各种约束条件的自动排班，和员工考勤以及遵时的监控。几乎每一个单独功能模块，都需要克服很多技术难题，而且需要长时间的优化迭代。

但是坑爹的地方在于，项目周期很短，几乎是赶鸭子上架。我在殚精竭虑了几个礼拜后，终于拿出了一套自认为行之有效的 MVP 方案。

我先是对业务流程进行拆解，认为「自动排班」是当前最大的痛点，所以准备最先实现这部分功能。我们花了大力气研究算法，解决运算资源问题，调优运算结果，好不容易勉强达到了「能用」的地步。

然而，上线后的效果却令人难堪——不仅排出的结果有各种问题，业务在一次试用后，也完全没有再想日常使用的迹象。

在之后的调研和复盘中，我意识到了问题所在——要把一个完全在线下完成的排班流程线上化，第一步绝不是解决我所谓的「痛点」。提供录入功能，将信息在不同系统间打通，实现线上流程闭环，在此基础上，再去提升各环节的效率，进行智能化的应用，这才是正确的产品演进策略。

而我所谓的「MVP 方案」，实际上是造了个轮子，还是个不圆滑的轮子。而轮子不是 MVP，独轮车才是。这是一个做产品很普遍且常见的坑，但却被我完美地踩了个遍。

知易行难，干这行真的是体会特别深。

3 技术选型会影响产品形态

产品经理需不需要懂技术，这种「日经」话题被讨论太多次了，通常政治正确的结论是：可以不懂，但是懂的话会有很大帮助。但是我的经验是，对一个合格的 PM 来说，前半句是不成立的。

我有时会听到同侪与开发之间，发生如下的对话：

开发：「要实现这个功能，可以用 A 技术，但是会有 a 影响；如果用 B 技术的话——」

产品：「哎呀，怎么实现我不管，技术方案你们自己评估。」

开发：「……好吧。」

其实原则上来讲，产品出 PRD，技术籍此评估技术方案，这么分工没什么毛病。但是实际工作中，却总会出各种差错。这是因为，通常开发和产品对需求的理解不是 on the same page。

之前我们业务需要上线一个数据分析看板，涉及实时和离线的数据，开发计划使用 Druid 来实现。Druid 本身是一个成熟的解决方案，但是它有一个弊端——在去重统计时，会有不小的精度误差。碰巧这个需求对离线数据去重精度要求很高，因为涉及业务的绩效和薪资发放。

但是由于负责的产品对技术方案完全不关心，也没有把「精度要求很高」这样一个隐性需求传达到位，理所当然地觉得不会有问题，导致上线后，统计结果离预期偏差很大。而且，因为一开始的技术选型错误，改动和修正需要耗费大量的资源。

其实这个问题很容易避免，只需要在评审时，仔细听一听开发说的技术方案优、缺点，选择最符合需求、最能保证产品扩展性的方案。

这点对 2C 的产品也是一样。比如说，一个前端页面该用什么框架，不是开发随便选一个就完事了，会存在诸如：是不是要做成单页应用，要不要考虑 SEO，等等，影响因素。

所以产品懂技术，不是要真的上手写代码（当然懂点 SQL 之类的还是很有帮助的），是需要了解自己产品所属领域的技术方案，和其优缺点、扩展性。因为它们是可能对产品形态产生本质的影响的。

4 用有限的资源做正确的事

有段时间帮部门负责人一起面试，有些面试者是转岗的，我通常会问一个问题，你认为产品经理的核心职责是什么。当然，开放性问题，答案不唯一，我自己的答案是：用有限的资源做尽可能正确的事。

如果拥有无限的资源，那做产品太容易了，穷举所有可能性，都做一遍，选择效果最好的那个（实际上不少大公司就是在这么玩）。正因为资源有限，做正确的事才显得格外重要，毕竟产品决策失误，是会浪费大量企业的人力和财务资源的。

所以有的时候，要敢于对一些不合理的需求说「不」。而且有些事可能看上去无比正确，但是时机不对，资源不到位，就不该去做。

不久前看到苏杰的一篇博客说「内部乙方没有真正的产品经理」，深有同感。对企业而言，PM 等级的高低，就体现在他处于产品开发的哪个环节。越是前期，就越偏战略层，等级就越高。

如果仅仅是做产品架构、系统需求的梳理，是很难触碰到核心价值的。充其量，只是在打磨战术。2B 产品的出路，应该是参与业务决策，影响业务决策，甚至倒逼业务决策。如果需求的主动权掌握在业务方手中，产品的价值就会被不断压缩。

当然，这点不是仅由 PM 自己所能决定的了，更多的，可能还是受企业管理者的影响。

5 尾巴

四件事说完，好像又什么都没说，感觉不过讲了一些正确的废话。

但是，总结和复盘，本身是产品工作一个重要而不可或缺的环节。所以，尽管本文可能对读者毫无益处，但至少于我，写些来就有其价值了。