终局思维：让你的产品架构自己从业务里长出来 / 开普饭

编辑导语：产品经理在日常工作中会接收到各个方面提出的需求，我们必须要对需求有所选择以及思考，才能做出正确的判断；对于一些较为复杂的需求，也要抓住需求最重要的点进行表达，让他人清楚；本文作者分享了关于产品架构的思考，我们一起来了解一下。

分享一个我很喜欢且受用的“终局思维”——当你知道你所负责的产品最终将长成什么样，那你第一步如何开始就不再无处下手了。

产品经理一定需要学会如何把复杂的问题讲清楚的能力，如果你无法一句话讲清楚你负责的某个系统或者某个产品模块，那你就很难抓到它的本质（业务本质、产品本质），也很难思考清楚它的终局形态会是如何？

没有这个作为里程碑式的参考目标，你就很难拆分版本规划，很容易被业务牵着鼻子走；而如果你已经在脑海中描绘了蓝图，什么时候迭代到什么版本，一个版本实现一个什么用户故事，就容易得多了，不至于迭代几次之后就开始迷茫。

在大多数创业公司，业务驱动是必然的，你无法选择，除非你去一家像滴答清单、Notion 这样的产品驱动型公司，否则产品必然要接收大量来自业务的需求。

面对诡谲多变的业务，如何更合理地规划你所负责业务的产品架构、产品形态，在此基础之上去跟业务推销你的产品方案；在每一次的业务需求中夹带着自己走向“终局”的“私货”，会让你的成就感更强烈一些，不至于沦落为“ PRD 民工”或者“需求工具人”。

王诗沐在《幕后产品》里说，往不同思考、往重点思考、往上层思考、往本质思考更是在强化这一点；日常多去思考问题的本质，多去思考这个问题最终会演变成的终局，能够帮助看清很多此前迷惑的东西。

比如，往宏观看，做在线教育，那教育的本质是什么？教育行业最终会演变成什么样？

比如，往微观看，在运营环节中，引入用户触达的本质是什么？我们为什么要做触达？触达的目标、形式、时机是否会因业务变化而变化？用户触达最终的终局会是如何？你所处项目的业务线将如何发展？当前这个需求最终将迭代成什么形态？

那如何才能找到这个问题的终极呢？我的方法是，从本源出发——从用户中来，到用户中去。

任何互联网产品形态的存在，必然是有某一个或者某一类需求需要得到满足；回到当前手上项目本身，我所负责产品的终局，取决于我最终想要彻底解决掉什么用户在什么场景下的什么需求？而在满足这个用户价值的基础上，我能否搭建出一条健康的商业价值链路，以及它是什么？

需求价值三角

如上图，按用户价值、商业价值和技术可行性3个维度尝试划分产品的终局形态：

同时满足用户价值+商业价值+技术可行性的，才是正确的产品生存形态；我们需要做的，就是尽可能找到你当前业务中，满足这套模型框架的一个又一个机会点。

在此基础上，明确好你的目标，基于这个目标，和业务发展的最终设想，尝试盘点当前的资源现状，和目标的差距；在此基础上设计好产品架构，拆解出多个大版本的 Roadmap。

以上，有了这些思考过程和沉淀的结果物，你再回过头看当前的产品形态，就能清晰地知道下一步该怎么走，不至于因为竞争对手、业务方拍脑袋等变化导致需求方向走偏。

同时，你在向老板、研发等团队成员推销你的产品方案也不至于因为各种细节问题而被拍回来。

关于产品经理如何把复杂问题讲清楚？如何把复杂的东西，给一个完全不了解它的人讲明白；本质的问题在于，你如何让对方在自己的认知范围内，将这个复杂的问题转译成自己能理解的语言。反过来，如何快速听懂别人给你讲一个陌生的东西，抓住重点，也是如此。

注意，关键词——转译！

产品经理是最强的连接器，团队各个角色之间的路由器，基于此，抓重点能力的习得会让你的工作效率大幅度提升。

分享一个曾经我在求职面试时遇到过的案例，当时面试官向我提问：你该如何向一个60岁的老太太解释数据库这个概念？我当时第一反应是数据库是什么？以及60岁的老太太如何才能理解数据库是个啥？先对问题的定义进行确认，然后再设定好问题边界，这两步能让问题讨论有一个明确的范围。

我尝试引入在老年人认知概念里通俗易懂的菜市场的摊贩位置布置来举例（一开始尝试用超市里的商品货架举例，但还是担心不够通用）；一个数据库就像一个菜市场，数据里可以有很多表来才存储数据，就像菜市场里有很多摊位用来摆放菜品卖菜的，基于此案例展开更多细节来解释何为数据库主键、数据库索引等概念，就很具像了。

总而言之，不管是需求评审，还是方案设计，产品经理作为一个强说服力工种，你的日常工作就是和各种角色（老板、运营、研发、测试、设计等等）就某个问题达成共识，然后对你提出的解决方案达成共识。

因此，为了避免沟通陷入僵局，你需要不断练习自己将复杂问题讲清楚的能力——抓住重点，提炼本质，一句话说清楚你的需求。

本文由 @蚂蚁先生原创发布于人人都是产品经理

题图来自 Unsplash，基于 CC0 协议

终局思维：让你的产品架构自己从业务里长出来