如果我知道我会死在哪里，我就一定不会去那个地方。
——查理·芒格
对于很多工作1-2年的产品新人来说，可能在不知不觉中就已经踩过了或者现在就身处“坑中央”，希望本文以下的内容可以帮助你脱坑或避免踩坑。
中台产品的四个坑
基于系统1设计“一次性”产品方案
“照抄”思维
解决方案的执行者
避坑指南
丹尼尔·卡尼曼在《思考，快与慢》一书中提到人大脑中有两个系统：系统1和系统2。
无意识的系统1依赖情感、记忆和经验迅速作出判断，它见闻广博，使我们能够迅速对眼前的情况作出反应。但系统1也很容易上当，它固守“眼见即为事实”的原则，任由损失厌恶和乐观偏见之类的错觉引导我们作出错误的选择。有意识的系统2通过调动注意力来分析和解决问题，并作出决定，它比较慢，不容易出错，但它很懒惰，经常走捷径，直接采纳系统1的直觉型判断结果。
对于有1-2年工作经验的中台产品来说，对于自己所负责的系统/工作有了一定的了解，可以相对灵活面对业务方提出的需求了，在这个时候，很容易出现基于系统1去解决问题的场景，基于产品的直觉和惯性思维解决当前的业务问题。
按照这种方式，也许当前的问题解决了，需求提出方也比较认可产品的解决方案。但是在后续的业务扩展、复盘时，会发现当初的产品方案是“一次性”的方案，只能解决当时所面临的业务问题，在后续需要扩展的时候，当初的方案完全无法复用，如果需要扩展只能推翻重来，对于开发、测试成本、产品设计成本，都会成指数倍的增加。
那么如何避免系统1影响产品方案的决策呢？
有两个简单方法：
（1）在需求分析阶段，得出需求分析结论后再问自己一个问题：这个需求产生的本质原因真的是自己分析出来的这个问题么？如果不是，是不是可以再挖掘一下更深层次的原因，到底是什么导致了当前问题的产生？
（2）在方案设计阶段，产品方案完成后再问自己一个问题：这个方案可“成长”么，即这个方案具不具备后续扩展性，针对未来可能出现的场景，当前的方案能否轻松应对呢？这个方案是否可以在未来形成一种对外的服务能力进行输出呢？
回答完上述两个问题，理论上你设计的产品方案就具备成长性了，但是能成长多少，还是和每个人的经验、认知有一定关联性，如果对自己回答问题不满意，可以寻求有更多经验的产品的帮助。同时在日常实践中学会思考、复盘与总结，可以帮助你更好的提升可“成长”产品方案设计能力。
当需求方提出一个需求：需要实现一个功能或者一套完整流程的时候；很多产品经理来会定义这个功能归属与哪一个系统模块，然后由这个业务模块的产品经理去承接；基于功能定义产品边界，是ok的。但是，在业务场景没有清晰，业务流程没有明确前，先去定义这个功能放在哪个模块去做是不适合的。
为什么这么说呢？
不管是系统也好，产品也好（本文中产品主要指中台产品），都是为业务服务的，是将线下业务的线上化，本质目的是通过业务系统化、流程化提高原有线下流程的效率，如果抛开业务场景聊产品设计方案，那么即便做出来一个很好用的功能或流程也可能是和业务场景不契合的，这样的方案也不会是完美方案。
业务模块的职责需要有明确的边界，即什么模块需要承担什么样的角色。但是在涉及到业务流程的运转、系统模块的交互上一定要贴合实际业务场景，基于业务流程决定系统间的交互流程，不能因为当前这个业务流程实现的业务场景，与自己所负责的模块没有关系就抱着一副事不关己高高挂起的态度。在设计产品方案上，要兼顾产品边界与业务场景两个方面，保证产品方案是符合业务的、是合理的。
3. “原样照抄”与“重新做”的权衡
这里说的原样照抄，其实有两种场景，一种是你的产品没有一个功能，但是竞品有，需求提出需求也要有这样一个功能；另外一种是内部业务的融合，涉及到兼并另外一条业务线，在兼并过程中，原有业务线的业务逻辑、功能、流程是不是原样照抄过来就可以了。
这两种场景其实都会涉及是“原样照抄”还是“重新做”的权衡，在做决策前，一定要对原有功能、逻辑、流程有充分的调研和分析，即为什么要这么做，这么符合当时的业务场景，但是对当前的业务场景同样适用么？只有对竞品或者原有业务有充分的分析，才能知道这个逻辑是保持不变还是要重新做。
如何判断哪些重新做，哪些原样照抄呢，这里给出几个参考条件：
（1）原有功能/逻辑/流程是否有时间、空间上的特殊性，还是普适方案；
（2）原有功能/逻辑/流程是否具备对当前或未来业务扩展的支持能力；
（3）原有功能/逻辑/流程是否足够简洁，是否可以继续精简，达到效率的最优。
充分了解原有方案的优势与劣势，并结合当下以及未来的发展诉求，做出正确的权衡。
4. 做有独立思维的产品，而不是方案的执行者
刚工作1-2年的产品新人，缺乏独立产品思考能力的时候，往往容易遇到两类问题：与技术沟通产品实现方案时，已技术提出意见作为最终解决方案，不思考方案合理性。在与业务方沟通需求过程中，被动接收产品方案，不做设计而是单纯执行。
这两类问题都是我在与产品新人打交道过程中发现的，技术同学在开发代码过程中考虑的是开发的复杂性以及实现成本的最优化，但是这种实现不一定是符合业务场景的或者现实逻辑的。
以一个电商类平台都会遇到的用户申请发票的场景为例：用户在商品订单详情页申请发票时，进入发票填写页所需要展示的信息需要从商品订单详情页代入。但是开发为了减少代码开发复杂性，向产品提出在进入页面前调用发票详情接口查询需要代入的信息，产品没有思考就同意了这种方案。
这个方案合理么？
无论是现实世界还是线上业务场景，如果一个订单都没有申请发票，就不会存在发票详情页的概念，这个现实业务场景和开发实现方案完全背离，很明显不合理的实现方案，对于产品经理来说竟然没有发现，这是非常不应该的。
再来说产品方案执行者，从产品经理岗位职级描述上来看，执行者应该是产品助理，在没有独立产品规划能力前，根据产品经理规划的方案去执行。但是对于产品经理来说，不经过自己思考和设计，直接做一个方案的执行者，这种方式是不可取的，这种方式永远无法让你提升。
产品经理最大的能力体现就是将需求经过自己的设计、规划形成产品落地，如果把这最重要一步省略了，那么你也就失去了做产品经理的意义。
这四个容易踩的坑是笔者基于产品工作中与产品新人沟通或对自己以往工作复盘的思考与反思中总结得来，希望可以帮助你尽可能的不要踩坑，产品经理就是在不断填前任留下对的坑，多实践多思考多总结，踩坑不可怕，可怕的是同一个坑踩了很多次。
