「定义产品边」中台产品不该踩的4个“坑” 场景|方案|原

如果我知道我会死在哪里，我就一定不会去那个地方。
——查理·芒格

文章图片
对于很多工作1-2年的产品新人来说，可能在不知不觉中就已经踩过了或者现在就身处“坑中央”，希望本文以下的内容可以帮助你脱坑或避免踩坑。
中台产品的四个坑

基于系统1设计“一次性”产品方案
脱离业务场景定义产品边界
“照抄”思维
解决方案的执行者

避坑指南
1. 基于产品“慢”思维，设计可“成长”的产品方案
丹尼尔·卡尼曼在《思考，快与慢》一书中提到人大脑中有两个系统：系统1和系统2。
无意识的系统1依赖情感、记忆和经验迅速作出判断，它见闻广博，使我们能够迅速对眼前的情况作出反应。但系统1也很容易上当，它固守“眼见即为事实”的原则，任由损失厌恶和乐观偏见之类的错觉引导我们作出错误的选择。有意识的系统2通过调动注意力来分析和解决问题，并作出决定，它比较慢，不容易出错，但它很懒惰，经常走捷径，直接采纳系统1的直觉型判断结果。
对于有1-2年工作经验的中台产品来说，对于自己所负责的系统/工作有了一定的了解，可以相对灵活面对业务方提出的需求了，在这个时候，很容易出现基于系统1去解决问题的场景，基于产品的直觉和惯性思维解决当前的业务问题。
按照这种方式，也许当前的问题解决了，需求提出方也比较认可产品的解决方案。但是在后续的业务扩展、复盘时，会发现当初的产品方案是“一次性”的方案，只能解决当时所面临的业务问题，在后续需要扩展的时候，当初的方案完全无法复用，如果需要扩展只能推翻重来，对于开发、测试成本、产品设计成本，都会成指数倍的增加。
那么如何避免系统1影响产品方案的决策呢？
有两个简单方法：
（1）在需求分析阶段，得出需求分析结论后再问自己一个问题：这个需求产生的本质原因真的是自己分析出来的这个问题么？如果不是，是不是可以再挖掘一下更深层次的原因，到底是什么导致了当前问题的产生？
（2）在方案设计阶段，产品方案完成后再问自己一个问题：这个方案可“成长”么，即这个方案具不具备后续扩展性，针对未来可能出现的场景，当前的方案能否轻松应对呢？这个方案是否可以在未来形成一种对外的服务能力进行输出呢？
回答完上述两个问题，理论上你设计的产品方案就具备成长性了，但是能成长多少，还是和每个人的经验、认知有一定关联性，如果对自己回答问题不满意，可以寻求有更多经验的产品的帮助。同时在日常实践中学会思考、复盘与总结，可以帮助你更好的提升可“成长”产品方案设计能力。
2. 基于业务场景，定义产品边界
当需求方提出一个需求：需要实现一个功能或者一套完整流程的时候；很多产品经理来会定义这个功能归属与哪一个系统模块，然后由这个业务模块的产品经理去承接；基于功能定义产品边界，是ok的。但是，在业务场景没有清晰，业务流程没有明确前，先去定义这个功能放在哪个模块去做是不适合的。
为什么这么说呢？
不管是系统也好，产品也好（本文中产品主要指中台产品），都是为业务服务的，是将线下业务的线上化，本质目的是通过业务系统化、流程化提高原有线下流程的效率，如果抛开业务场景聊产品设计方案，那么即便做出来一个很好用的功能或流程也可能是和业务场景不契合的，这样的方案也不会是完美方案。
业务模块的职责需要有明确的边界，即什么模块需要承担什么样的角色。但是在涉及到业务流程的运转、系统模块的交互上一定要贴合实际业务场景，基于业务流程决定系统间的交互流程，不能因为当前这个业务流程实现的业务场景，与自己所负责的模块没有关系就抱着一副事不关己高高挂起的态度。在设计产品方案上，要兼顾产品边界与业务场景两个方面，保证产品方案是符合业务的、是合理的。