被浪潮卷起的产品经理，须苦练看不见的基本功

关注并将「人人都是产品经理」设为 ★ 星标

每天早上更新，与你一起成长

2015年移动互联网红利期，大家认为产品经理是CEO的后备军；

2019年互联网下半场言论开始兴起后，产品经理的热度似乎有所减退；

到最近两年，大环境下的裁员潮，开始让更多产品经理开始讨论起「新出路」这个话题。

身在漩涡中，自然也能感受到一些微妙的变化。

在宏观层面，招聘需求的锐减是直观的。

前段时间，我字节的小伙伴跟我说，他准备跳槽，试着在网上挂了简历，本来以为先拿一些面试机会练练手，最后发现几乎没有HR找他，这跟他上次跳槽形成了鲜明对比。

在公司内部，晋升周期变长，普调逐渐取消，专家岗大头兵明显增多，低P员工生存环境越来越卷。

在个人层面，副业、个体、身心灵等话题吸引了越来越多的人。

我总觉得，似乎大家忽略了对工作本身的研究。产品经理曾经被传得很厉害，但它终究是一份工作，是工作的话就有它的基本功。

虽然很多想找新出路的产品经理，因为找不到路而焦虑，那在焦虑的时候，是不是更应该专注基本功的修炼，尤其是那些不被重视过的基本功。

产品经理到底在创造怎么样的价值，这是我们应该去思考的第一个问题。

我的理解是：产品经理完成了产品的第一次创造。

任何新事物从无到有，无非经历两个过程：规划和实现。

规划属于第一次创造，主要是想好怎么做，可以是建筑图纸、可以是脑海里的想法、可以是原型图、也可以PPT。

规划的目的，就是在当前和目标之间规划一条路径，并想尽办法证明，按照这个路径走，就能实现目标。

实现属于第二次创造，按照规划好的路径，以各种现实中的方式去实现目标。无论是工程队造房子，还是工程师焊接电路，或者是程序员编程，最终都是实现了第一次创造的结果。

当然，这是理想情况。

事实上，规划和实现间可能有巨大的差异，也可能在实现过程中不断调整最初的规划。

但不管怎样，新事物的创造离不开这两个阶段。

对产品经理来说，每天都在「创造新事物」打交道。

无论是一个完整的产品，还是产品中的一个模块，甚至是一个很小的需求。产品经理都会负责它的从0到1 —— 也叫做功能上线。

而在这个创造过程中，产品经理尤其要对第一次创造负责。

需求调研、竞品分析、方向讨论、方案细化，直至最后的需求文档产出，一切的一切都是为了形成一个共识——这个需求应该怎么做。

是的，产品经理最核心的交付物，需求文档，就是为了明确所有人的共识：关于这件事应该怎么做。

后续设计师会依据需求文档进行交互和视觉设计，软件工程师会依据需求文档进行编程，一旦共识有问题，就会影响后续的所有工作。

基于上述这个答案，我们可以得出产品经理有几个非常重要的能力象限。

除此之外，还有一些软性能力，沟通能力、学习能力、同理心等等。

但今天我并不想讨论它们，况且讨论它们的文章太多了。

我想聊的是一些非常实在的东西，这些东西存在于产品经理每天的工作中。

我曾经问过一些研发和设计师，在他们的职场经历中，合作过特别愉快的产品经理都有什么样的共性呢？

我以为会得到一些与上述几个能力象限相关的评价，但最后发现，得到的答案都非常具体：

首先，需求单能写得清楚和明白；其次，该考虑的点都可以考虑到，别漏东西。

初听起来，这样的要求也太零碎了吧？但细想，这样的要求真的很难啊。

回到那个问题，产品经理本质上做的就是第一次创造，他们给下游同学直接交付成果就是需求单。

清晰而完备的需求单，就是产品经理做好的作品。

进一步的，我在想，无论外界对产品经理或者互联网多么看衰，踏踏实实地写一份清晰而完备的需求单，应该是产品经理关注的首要工作。

再联想到马斯克收购推特之后，现场检查研发高管们的编程能力，我坚定的认为：

环境越是波动，越应该修炼好那些不被看重的基本功。

在具体介绍这些基本功之前，我想再聊聊，如何衡量产品的第一次创造的价值。

我的答案是，减少二次创造过程的损耗。

很多人问，为什么不是看数据呢？

因为我渐渐发现，产品经理无法100%决定产品的数据表现。好的数据会依赖于「老板想清楚了」，依赖于「运营给力」，甚至有时候依赖于一点点运气。

但二次创造过程的损耗，却是产品经理几乎可以100%决定的。

如果你是开发、设计、运营，你有没有觉得，跟某些产品经理配合得很舒服，几乎无需太多来回的拉扯，但跟某些产品经理合作得就很痛苦，不是这里表达不清楚，就是那里逻辑不正确。

俗话说，尽人事、安天命。

产品经理的「人事」，就在这「规划到实现」的路程上。而这个过程，100%体现了产品经理的基本功。

第一项基本功，是产品方案表达清晰，没有歧义。

有人会觉得这也太小了，值得说么？我觉得太值得了。

记住，一次创造的最大问题，在于它并不具体，一个不具体的东西，1000个人就可能有1000种理解。

有时候我们作为产品经理，看着自己的需求文档，以为说得很清楚了，但拿给其他人一看，可能理解完全不同。

举一个最常见的例子，微信公众号文章左下角有阅读数据。如果当初设计这个文章详情页的产品经理这么描述：在这个位置（位置在图示中说明）展示文章的阅读数据。

仅仅这一句话，就有如下需要明确的问题：

当然，在实际研发过程中，可能还会有更多问题。

有人会问了，既然我已经创造了微信公众号这个伟大的产品，还有必要抠这些细节么。

有，非常有。只有把这些问题都想到了，都定义清楚了，才是真正交付了一个作品。有时候，对于细节问题的定义，在我眼里甚至是具有美感的。

毕竟，代码是不含糊的，不清不楚的东西，在代码那里，是要出问题的。

第二项基本功，是方案闭环，不出现逻辑错误。

在美团内部有一句名言，所有问题的解决，第一步都是「解」。所谓「解」，就是分解。做好分解，后面就会顺利得多。

我们都知道，分解的原则是MECE，不重复，不遗漏。

不重复确保唯一性和确定性，不遗漏确保闭环。

举个例子，如果某个资源位要实现分层运营，针对不同用户的身份跳转不同页面，那么在方案的考虑上就一定要考虑到所有身份，不能有遗漏。

例如：普通用户，会员用户以及未登录用户。

我看过一些新人产品经理的需求文档，经常会遗漏掉未登录用户。

负责任一些的研发，会默认给你做一个逻辑，未登录用户点击资源位时自动唤起登录。

如果这个研发就在这里写了一个逻辑：未登录用户点击后报错。你可能会觉得这个研发脑子有问题，但要我说，还是因为你作为产品经理，没有考虑到所有情况，导致逻辑没有闭环。

不重复的情况很少发生，但也会有。

例如在需求文档的前半部分说，这个资源位点击后跳转A页面，后面又说点击后跳转B页面，那在代码里，就很容易出现问题。

除了这两个，当然还有很多其他方面的基本功需要去培养。

但我认为，这两个基本功直接关乎完备而清晰的需求单，是所有其他基本功的前提条件。

如何培养这些基本功呢？

首先是无歧义的表达。

必须认清，语言是有歧义的。要消除歧义，那就尽可能用结构化工具去表达复杂的逻辑和信息。

大家都知道，原型图是一个很好的工具，但原型图不能代替所有逻辑表达。

例如用户的登录逻辑，其实包含了短信服务、发送和验证，这些在原型图中是很难清晰表达出来的。

我的建议是，复杂的逻辑尽可能用流程图表达。

流程图这个工具，本身就包含了开始节点、结束节点、判断、分支、串行、并行等常见的逻辑内容。

流程图的优势就是可视化的流程走向，一读就明白。可有时候，产品逻辑没有那么多纵向节点，但是有很多横向判断。

比如用户在不同身份下，访问当前页面时，需要展示什么要素。

这种结构化程度非常高的信息表达，我建议大家多用表格。

当我们用表格的时候，无形中就在做逻辑归纳。表格中的第一行就是维度，以上述例子而言，用户身份是一个维度，页面展示要素是一个维度，可能还有页面交互以及补充说明这两个维度。

于是一个4列N行的表格，就完全可以表达「不同身份用户访问页面」这个需求点的所有内容，这比一大段文字要清晰多了。

对一个需求文档而言，图、文、流程图、表格，我觉得足以表达很多复杂的逻辑。

但我遇到过的很多情况都是，针对我弄清楚的逻辑，我可以想办法进行无歧义的表达，但问题往往出在我不清楚的逻辑。

这就要说到第二点，如何考虑到所有点，不出现逻辑漏洞。

首先得说，需求文档不出现逻辑漏洞，就跟代码不出现bug一样困难，几乎是不可能的事情。

要不然测试就不用写用例了，以及后续的开发过程中也就不会存在那么多的沟通成本了。

但追求无逻辑漏洞的产品方案设计，应该成为每个产品经理的目标。尤其是在增长缓慢的大背景下，产品经理更应该注重修缮屋顶、修炼基本功。

虽然这个目标很难，但并不意味着没有方法接近它。

我的建议是，多多跟研发和设计沟通，收集他们平时会问到的高频问题，从而看看你的方案到底哪里有问题。

换句话说，从一个开发者的角度，来进行产品方案的设计，这样就可以在一开始考虑到尽可能多的情况。

我做过C端产品、也做过B端产品，姑且聊聊我积累的一些设计经验吧，这些经验已经成为了我做产品设计时的潜意识。

C端产品设计，常见的考虑要素包括页面和模块两个维度。

页面维度常见的考虑维度：

模块维度常见的考虑维度：

从后台页面搭建的角度看，后台产品有常见的三个要素：表格、表单和详情页。

先说说表格。

表格常见的考虑点包括：

1）表格数据源：展示是哪个对象，这个对象和其他对象之间有怎样的关联关系，这是后台设计第一步需要考虑的问题。

2）表格的字段描述：逐个说明每个字段的含义、数据源以及展示方式。

3）表格查询区域说明：相对复杂的表格都有查询功能，往往是基于某些重要的字段做查询。查询需要说明，每个查询控件的名称、控件类型（选择类注意单选和多选区分开），查询方法（查询控件与表格哪个字段匹配，如何匹配）

4）表格操作列说明：操作列是表格记录的操作区，一般进行状态控制或者删除操作，这部分功能的说明一般带有逻辑判断，例如满足什么条件的记录会出现哪些功能按钮。出现这样的情况就建议用流程图或者数据表格去说明功能，结构化程度更好。

5）其他功能：包括创建、导出、刷新、翻页器等等。

再说说表单。

表单是管理后台产品的核心模块。任何一个系统，只要涉及到数据输入，就一定会用到表单功能。

表单常见的考虑点包括：

1）表单字段说明

每个字段对应什么输入控件、代表什么业务含义，都需要说明。

复杂的表单字段间往往有联动逻辑，例如单选字段的值为A时展示X输入框，值为B时展示Y输入框。

顺便说一句，业界已经有非常成熟的输入控件库和对应的标准设计，基本不需要产品经理去创造一种新的输入控件。

2）表单校验逻辑

这是我见到很多人做后台设计时容易忽略的部分。数据输入是一个很谨慎的过程，如果没有很充分的校验，会导致数据表中有非常多的脏数据，给后续的处理带来不可估量的风险。

校验有两种，by字段的和字段间有联动的。by字段的校验，就是看每个字段控件内的输入内容是否正确，不正确的话需要定义对应的错误文案。字段联动校验，就是看多个字段之间的输入是否满足某种组合公式。

字段校验的错误文案一般展示在字段控件下方，字段联动校验的错误文案一般展示在整个字段区下方。

每一个错误文案跟一条校验逻辑匹配，所以逻辑之间往往具有优先级，这一点也记得要说明。

3）表单提交后的工作流

很多人在做表单设计时，只关注字段，却忘记说明数据提交后的工作流。事实上，我们很多在用的表单，都有其下游逻辑，是提交后刷新数据库，还是提交后打开另一个联动表单，或者是提交后打开某个新页面，这些都是工作流的范畴。

管理后台设计，跟业务逻辑耦合程度非常高，我曾经不知道该如何梳理要注意的逻辑漏洞，但在字节做过低代码产品后，我对这块就产生了肌肉记忆。

所以啊，做产品的每一步，只要好好做过，都算数的。

再次说明，我个人的经验毕竟有限，如果有更多补充，欢迎大家在评论区友善留言。

最后从细致的具体的内容中抽离出来，聊聊我为什么要写这篇文章。

前面说到，行业是有生命周期的，而宏观周期的变化，对个体产生的影响是不可估量的。

我见过很多优秀的同学，怀揣着改变世界的梦想做产品，成为螺丝钉之后，满脑子都是郁闷和抱怨，失去了当初的一点热情。

甚至身边有小伙伴正在经历裁员、失业、不知道下一站在哪里。

吴军老师写过闻名遐迩的《浪潮之巅》，但没有人告诉我们，当我们处于浪潮之谷，甚至被漩涡卷入深渊的时候该怎么办。

我也不知道怎么办，但我觉得，这说白了就是一份工作，踏踏实实做好，总结、复盘、改进，把基本功练扎实——

是我能想到的能穿越周期的办法之一。

在见识、理解、人脉、把握趋势等不确定性面前，完备而清晰的需求单，是难得的确定性。