产品要想得够虚，才能做得更实

不知道你发现了没？

在工作中我们总有一些应激反应：上级指派任务下来后，立刻调资源排计划；接到一个新需求，二话不说拉会探讨方案；团队定了OKR，撸起袖子迅速拆解任务。

这还算好的，不少人在接到一个任务，尤其是重要任务时；默不作声就开始搬砖，走一步看一步，折腾一段时间后再憋个招，至于啥时候放大招就不一定了。

速度快不等于效率高，快速执行不代表你能快速交付。

从旁观者的角度切回自己身上时，我也在想，我的应激性思考是什么？在接到一个新指示时，“怎么执行”——这个问题是否会占据上风？对于这个任务背后的思考够不够充分，这些思考是否能作为我下一步动作的指导？

我们每天摄取的信息都过于直接和具象化，在思考层面也倾向于找个实打实的支点——它很直观，无需太费力就能获取；但它过于扁平，无法让你冲破现象与底层逻辑的壁垒，甚至在多数情况下你并不知道自己遇到了天花板，还误以为这就是“真相”。

“真相”就是：目标是清晰的，计划是明确的，资源也到位了，还有什么不妥？

说不上来，总觉得好像还差一点……如果有突发情况怎么处理？下次接到这类任务怎么应对？还有优化的空间吗？这就是全部了吗？

今天我想聊的正是这一点，做产品要讲究虚实结合；这就像在练太极拳，旁人看来你是在含胸拔背地扎马步，但其实你在虚领顶劲，气沉丹田，“至虚极，守静笃”。

一、怎么就虚了？

老老实实办事，勤勤恳恳搬砖，这恐怕是绝大多数社畜的写照。

想努力，努力成为一名更一流的社畜，我们会非常关注一个方案是不是可落地的，计划是不是可执行的，成效是不是可衡量的……

虚，这个字似乎总有一股贬义的意味，这里我想重新定义下“虚”。

还是在练太极，以有形之躯，演无形之法；你出的每个实打实的拳脚背后，都蕴含着无形的章法和招数：物我两忘是虚，刚柔并济是虚，谋定而后动。

回到标题，产品要学会想得虚一点——不是空想，也不是乱想；它需要你有大局观，思维发散、思路缜密，你脑中始终有一盘棋，哪怕走错了哪一步也不碍事。

1. 漏斗式发散

发散思维，你肯定听说过这个词。

想得虚，首先你要学会发散；你有很多的想法，并且能把一个新想法跟另一个意想不到的知识点联系起来，碰撞出更多的想法；最常见的手段就是召集一群人开个脑暴会，各抒己见，穷举想法。

但其实，大多数的头脑风暴，很多时候都变成了一种偷懒或推卸责任的好办法，每个人都指望从别人的讨论中得到一些灵感，但实际上大家都在互相指望；到头来任意发散而忽略聚焦，甚至只发散不聚焦。

而漏斗式的发散是先聚焦，再发散；锚定核心抓手，再向外延伸。

比方说你去报健身房，一来就被健身教练叫去热身、举铁、深蹲、高抬腿，这合理吗？

健身教练肯定要先了解你的健身诉求，测试你的生理状况，再针对性给你安排课程和饮食计划，再定期测量和检验成果。

注意，发散不是目的，发散是为了容纳更多的情景和信息，让产品的决策有更多的依据。

2. 产品架构思维

有了足够发散的想法后，还不够，你还要有顶层的架构框住你的idea；盖房子前先规划架构，否则盲目开工会造成巨大的浪费和损失——这个道理大家都懂，但实际执行却总是步履维艰。

我在看王丁老师的《产品设计思维》里，他提到对产品架构的理解：

合理的产品架构，是从功能层面抽象出合理的自运转系统，能让这些系统更高效、简单地运作，它是一种抽象的逻辑。——王丁《产品设计思维》

为什么会出现一个需求推翻重来多次依然无法满足客户的预期？产品已经做得很辛苦了，每个KA项目的需求也认真调研了，但交付的时候依然差了那么一点。

放过你眼前的这个需求吧，先放一放；尽可能去搜罗信息，了解客户核心的业务场景，基于反馈人的立场和客户的业务倒推他提出这个需求的出发点，再去提炼产品架构的核心点、围绕核心的主要子系统有哪些、子系统之间可能拥有什么样的联系。

你会发现，难点不是需求文档怎么写，流程图怎么画，原型怎么设计……如何摸清业务场景，理解业务场景过程与角色的作用成了头等大事。

在我们团队内配置了产品架构师的角色，基本上都有数十年的业务架构和技术架构的经验。

他们对于业务场景的望闻问切，掌握场景与商业规则的核心，基本上都有一个共性：

从市场和客户需求里去挖掘和理解，这个理解并非源自细节的视觉表现、交互表现或功能点；而是对业务场景的角色互动过程、与其他场景之间的联系，以及在场景中各类角色的职能与定位的深度理解；然后再通过关键场景的逐个梳理，由小到大去搭建完整的产品框架，且构建出的产品架构体系具备一定的生态结构。

以零售的产品结构为例，核心主场景分为三大中心：交易中心、运营中心、渠道中心。

交易中心里细分为采购、仓储、导购、商品、预定、订单、支付、物流等环节，每个环节都需要系统去做支撑。

明确这些支撑系统之后，随着业务的扩张，也能以较小的代价满足商业模式的需要：既能横向扩展，实现跨领域的品类扩增；也能支撑上下游的延伸发展，深入管理供应链。

这样的架构符合SOA的分离与松耦合设计理念，即：支持不断地拆分独立的生态产品系统，将其通过一定的运作逻辑线连接在一起，从而为整体的业务发展提供足够的支撑。

下次别急着写需求文档了，请先慢下来，思考下你的用户场景，从场景倒推你想实现的核心能力，将能力做原子化拆解，揉碎再重组，由小至大去搭建产品框架，充分支撑上层的业务场景。

3. 识人

够虚了吗？你有足够发散的想法，你摸清了想法背后的逻辑架构，这个事就妥了吗？

我们都知道，企业内大规模的合作是时下的主流，我们因为各怀心思，在某个合适的时机凑在了一起，朝着一个共同的方向前进。

而据我观察，很多人在合作过程中并不清楚合作方人员的配置，甚至对于自己所处的组织架构都不了解；包括你所在组织运行的模式，所在岗位对应到整个生产过程中具体的位置和权责。

听起来不可思议，但对于大公司来说，这种情况还真不少。

我们在讨论事情的时候目标清晰、任务明确，而一旦涉及到职责边界时总是闪烁其词。

一个会议结束，方才还在谈笑风生的合作方是哪个部门哪个中心下的什么人，可能都记不得；事后回溯时总喜欢大而化之地指代一个团队，对于其中的分工也习惯性地含糊其辞；不是不愿说，是没意识到人在事情推动上的重要性。

为什么很多时候我们会觉得事情运作起来容易失控，可能是源头出了问题，你聚焦在事情本身而忽视了背后关注这件事的那群人。

这些人是谁，什么环节起作用，他们之间的利害关系是什么，他们和你们之间的合作关系是否可靠？

与其了解目标，不如了解意义；与其索要计划，不如索要信息——这些都只有在你充分了解合作团队内的人员之后才能捕获到。

二、虚实结合，深入浅出

虚是发散，是架构，是识人；想得够虚，你才能做得更实。

由虚到实，从发散到收敛，从架构到需求，从识人到辨事——这是一个深入浅出的过程。

1. 从发散到收敛

一个产品决策的过程就是发散与收敛。

何项俊老师总结过一个抖音网红百万公式：

大网红=赛道+人格+场景+关系

赛道是确定方向，找到一个机会；人格是找标签，将人扁平化，是打开机会的姿势；场景是让标签鲜活起来，里面包涵着破局点；关系是让标签丰富起来，是破局后的推动力。

• 赛道和人格，是发散，是抽象，是做加法，是尽可能找到这个市场的潜在机遇，找到你的机会母体；
• 场景和关系，是收敛，是具象，是做减法，是聚焦于寻找最适合你发展的最优解，释放你的母体原力。

在开展工作的时候，我们不缺一鼓作气的魄力，但缺乏四两拨千斤的巧力。光发散不行，你需要将信息收敛出一个结论；光收敛也不行，你的想法里没有容纳更多的情景和信息。

而收敛的过程一般包括找线索、揪问题、抓病因、提方案、最优解、做校验、做优化这七点。

• 找线索：从松散的信息里找到这些信息之间的关联，哪怕是碎片也可以聚类，把这些信息串成线索；
• 揪问题：按线索带入个人的感受过一遍全流程，把你认为不爽的、有问题的点都列出来；
• 抓病因：试着去挖掘这些问题的本质、共同点和异同点，找出主要矛盾；
• 提方案：这个矛盾有哪些处理方式，有哪些可行的解决方案；
• 最优解：没有最好的方案，只有最满意的方案；
• 做校验：校验这个方案是否达到预期效果，市场的反馈是什么，是否还有进一步提升的空间；
• 做优化：根据市场的反馈、公司战略的指导，去调整和优化这个方案。

以Nike为例，在传统的观念里他只是一个户外运动服饰品牌，而早在前几年，各大品牌纷纷开展线上数字渠道的铺展和营销，手段五花八门，消费者应接不暇。

就在这时，Nike采用了行为指导策略，将自己定位为健康和健身教练，而非仅仅是制鞋商。

尤其在今年特殊背景下，线下户外运动的场景受影响，他主动邀请客户加入虚拟跑步俱乐部并追踪他们的跑步数据，由此预判客户下一次健身的时间；并通过自己的应用软件，邀请不同运动达人，做室内运动训练课程，为客户提供健身音频指导和方案。

有了这层关系，客户也更愿意听从并获益，而这一举措也让Nike收获了亮眼的线上渠道销售数据：报告期内的线上销售额增长75%，占整体销售额的30%，很好地为消费者创造了新的运动场景，激活消费者对于运动服装等需求——这场“自救运动”成功地守护了没有运动的“繁荣”。

2. 从架构到功能

前面提到，一个好的产品架构对一个产品而言就像骨架之于人，框架之于房子，起到支撑、引导、承重的作用，具备易用性、稳定性和可拓展性。

而产品架构毕竟是内里，你真正交付给客户的是一个血肉之躯，一个装潢得当的楼盘。

那么，当你设计好产品架构后，如何才能将这个框架在产品设计里落实下来？

也许我们经常会遇到一种情况，产品经理梳理好产品架构后，就火急火燎地开始设计原型；然后拉上设计、开发和测试去过需求，完了之后又发现有些问题没考虑进去，补充进去后又发现有个逻辑有出入，来回横跳多次后终于把产品需求和界面原型定下来。

并不罕见，相反大多数情况下产品经理与开发的博弈正是在这反复多次的返工和确认中愈演愈烈。

我简单总结成以下几点：

1）定需求

客户需要什么，期望什么，这不是需求。

需要是你对某样东西感到不满足的一种状态，比如你渴了想喝水，累了想休息；而期望是有明确的指向性和选择性，比需要更具体，比如你渴了想喝一瓶农夫山泉，累了想回家睡个觉。

需求呢？它是对有能力购买且愿意购买的某个具体产品的欲望，本质是动机。

你要通过客户的反馈、投诉等，深挖言语背后的本质需求，也许客户想要的不是一匹更快的马，而是更快地到达目的地。

2）建框架

在分析好需求之后，你要建立一个复用性和拓展性强的产品架构。

在《用户体验要素》一书里，Jesse James Garrett阐述了互联网产品的几个典型产品信息架构模型：层级结构、自然结构、线性结构、矩阵结构。

层级结构：顾名思义，在该结构里节点与其他节点之间存在父子关系，这种结构也是最常见的。

自然结构：基本不会遵循任何一致的模式，没有太强烈的分类概念，对于探索一系列关系不明确或是演变频繁的产品是比较合适的；比如各大视频APP、新闻网站等，用户要么是带着明确的资讯目标去分类查找，要么是毫无目标地随机浏览——这种结构比较适合娱乐休闲类的产品。

线性结构：就像是在写一个流水账，你通过一个故事线贯穿全流程，是一种线性的体验；比如一些流行的外教网课、教学视频等。

矩阵结构：允许用户在两个及以上的节点之间移动，由于每个用户的需求都可以跟矩阵中的一个轴联系在一起；因此矩阵结构通常能满足带着不同需求而来的用户，它需要将信息进行分层，再精准地匹配到对应的用户。

3）定流程

定好产品架构后，明确产品的业务流程，梳理产品流程图，是非常有必要的；我之前在分享专利申请书编制的经验时，最经常提到的一个tip就是：像计算机一样思考，像剥洋葱一样表达。

像计算机一样思考，思考数据在这个业务场景下的流转过程：输入什么，经过了哪些模块，每个模块之间是什么关联，数据得到了什么处理，最终输出什么，实现了什么效果。

比如你打开打车软件，一般会有这样的操作过程：

定位个人位置——查找目标地——选择车型——生成订单——享受服务（上车、到达目的地）——支付订单——生成行程单等。

这些流程在你规划产品功能细节时要先想清楚，确保用户的体验是闭环的。

4）抠细节

当你明确好需求、搭好框架并对齐流程之后，之后的功能原型设计和需求文档编写就是水到渠成的事了。

在这过程中依旧免不了跟开发的pk，但这时候再去抠细节，就会更有章法，不至于捡了芝麻丢了西瓜，在此不加赘述。

3. 对人再对事

不少产品经理对于团队内的协作非常熟稔，当面临重大事件时，也能在无授权的情况下调遣团队内的设计、研发、测试、运维等资源，将整个事情推动得风生水起。

而当产品经理需要跨团队协作时，尤其在双方没有感情基础的情况下开展合作时，往往在一开始就会碰到事情推动不起来、怀疑合作方不给力、套路跟你不一样的局面；想要求对方跟你步调一致，但又不好意思提，跟自己的上级反馈的话又不知道从何说起；剪不断理还乱，最后卡在某些环节不了了之。

这是跨部门合作的常态，你以为你对事情的来龙去脉了如指掌，但是你对投入到这个项目的干系人一点办法都没有；你甚至根本不知道具体有哪些干系人，走一步算一步。

那么，不妨试着先锁定和你对接的那位同事，以他为一个突破口，了解他所在的团队内各个关键的角色，摸底对方与你们合作的动机；甚至是了解他们的kpi压力，为了达成这次合作他们能付出的最大成本是什么。

基于对人的了解之后你再去审视手头上的这些事，兴许会明白得更透彻。

多提一句，其实不仅限于合作团队，你完全可以对日常你所看到的各色人群进行建模，观察群体的共性和个性，不断去推翻和重建颅内的固有认知。

在此引用下我老板提过的一个命题：做产品就是做人。

深以为然。

三、小结

环顾四周，行色匆匆埋头苦干的人实在太多，大放厥词一味空谈的人也不少。

我们太习惯陷在一个事情里看不清圈外的战况，固有的认知根植在我们的脑海里，很难跳出去，甚至完全没意识到自己被困住了。

一提到虚，我总想到雾，那是最接近被云拥抱的距离；一提到实，我回到了地面，那是我们稳步前进的支撑。

做产品的确需要虚实结合，想得虚，做得实；从发散到收敛，从架构到功能，从识人到辨事；二者互为辅助，兴许能让你想得更清楚，做得更轻盈。

在局内人的世界里做一个局外人。

参考文献：

王丁《产品设计思维》

梁宁《增长思维30讲》

Jesse James Garrett《用户体验要素》

赖京露《产品之旅：产品经理的方法论与实战进阶》

《哈佛商业评论》2019年5月

#作者#

林壮壮，微信公众号：健壮的大姐姐（ID: is_strong）。腾讯高级产品经理，专注于To B服务项目管理和行业分析，欢迎各路好汉一起探讨。

本文

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！