面对变化的环境和袭来的各类浪潮，产品经理要怎么把握确定性，穿越周期？或许最根本的事情，就是把基本功练扎实。那么，产品经理需练好的基本功有哪些？产品经理又该如何培养基本功？不妨来看看作者的总结。

不可否认，大多数行业都存在生命周期，互联网也不例外。

于是产品经理的命运也随生命周期而浮动。

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

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

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

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

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

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

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

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

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

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

01

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

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

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

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

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

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

当然，这是理想情况。

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

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

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

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

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

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

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

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

02

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

首先是对业务的理解，确保是沿着正确的道路在做事情；

其次是基于用户体验的审美能力，保证产品是友好易用的；

接着是项目管理能力，确保工作成果可以按时交付；

最后是数据分析能力，确保以正确的方式去分析产品的迭代。

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

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

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

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

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

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

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

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

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

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

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

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

03

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

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

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

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

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

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

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

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

04

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

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

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

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

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

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

1. 阅读数据是指阅读人数还是阅读人次？
2. 数字展示到底是如何展示，非常大的数字也需要精确展示么？（现在我们知道，微信公众号创造了10万+这个概念）
3. 数据更新机制是怎么样的，是每次刷新都去获取一次数据，还是每天定时更新？

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

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

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

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

05

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

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

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

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

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

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

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

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

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

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

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

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

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

如何培养这些基本功呢？

06

首先是无歧义的表达。

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

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

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

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

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

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

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

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

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

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

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

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

07

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

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

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

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

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

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

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

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

08

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

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

1）页面框架是什么，原生、H5还是小程序

2）用户浏览该页面的条件，游客、登录用户、或者是条件更严格的其他身份。

3）页面流，入口有哪些，下级页面是哪些。在页面流中，最容易被忽略的是逆向逻辑的考虑。

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

1）模块数据源：是后台传过来的数据，还是前端写死的数据，还是系统自动记录并展示的数据（例如时间戳）

2）模块内要素的数据源：如果模块的数据源来自后台，那就要进一步考虑模块内的每个控件分别来自后台表格中的哪个字段。最常见的遗漏是，前端页面定义了要展示哪些内容，却发现需求单里没有定义这些内容到底从哪里取到。

3）字段级别的限制条件：为了美观的显示、流畅的加载、系统的容量等，很多字段都需要有限制条件。例如说明文案字数限制、图片大小限制等。这种限制既包括后台配置的限制，也包括前端显示层面的限制，都需要考虑到并明确。

4）兜底逻辑：大多是空数据的处理，包括网络异常带来的数据获取为空，或者是很多初始化场景下带来的数据为空。

5）逆向操作提示：用户做一些解绑、删除等逆向操作时，需要考虑一些提示逻辑，主要是防止误操作。

09

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

先说说表格。

表格常见的考虑点包括：

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

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

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

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

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

再说说表单。

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

表单常见的考虑点包括：

1）表单字段说明

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

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

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

2）表单校验逻辑

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

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

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

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

3）表单提交后的工作流

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

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

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

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

10

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

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

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

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

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

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

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

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