产品经理的进阶指南

前言

作为一个从事产品设计六、七年的人，本人做过技术开发、C 端产品设计和 B 端产品设计，并带过整个产品开发团队。也曾经帮助过很多新手产品经理，本文讲讲一个产品经理该如何一步一步成长进阶。

入门 —— 画好原型

大多数产品新人入职后承接的是产品助理类的岗位，通常会要求学习原型绘制工具（一般用 Axure 或墨刀），然后帮助公司的产品经理完成原型绘制。从角色上来说，更多是一个执行者。画原型对于有经验的产品经理来说其实是一个体力活，但对于新手来说却是锻炼的好机会。画原型，看似拖拖拽拽很简单，但实际要画好却没那么容易。下面是一些如何画好原型的建议。

1. 布局合理：布局设计关系到你的界面的信息如何展示给用户。哪些地方更重要，哪些区域是用户最容易注意到的？这些都需要考虑，把最为关键的功能或信息展示在用户最容易注意到的地方，一方面能够提高信息的传达效率，另一方面可以节省用户搜索信息的时间。下面是一个常见的网页热区图，我们可以根据这样的热区图去合理布局我们的原型。

2. 组件化：组件化不仅仅是用在开发环节，在产品原型设计环节也很重要。通过组件化，我们可以提高原型绘制的效率，同时也能够保证产品界面和交互的一致性。很多大公司都会有自己的组件库，如果时间允许，你可以建立一套自己公司的组件库，如果不允许也可以使用第三方的组件库。比如国内广泛使用的 ElementUI（饿了么） 、 AntDesign（蚂蚁） 和TDesign （腾讯） 都提供了 Axure 组件库，而墨刀的素材广场也提供了很多可直接用的组件素材。

3. 交互：不是所有的公司都有交互设计师这个岗位，作为产品经理需要参考学习大量的软件的交互，并对常用的交互习惯了然于心。交互设计最重要的有两点：符合用户习惯和带来愉悦体验。这方面谷歌的 Material Design 给出了很多交互的示例说明，而 AntDesign 也同样提供了一些交互设计原则和指引，推荐产品新人可以阅读 AntDesign的设计原则。

此外，虽然说画原型是一个体力活，但是对于产品新人来说却是熟悉业务的最好机会。画原型的过程中多思考业务功能，会更快地帮助你成长。要知道，要成为一个高级产品经理，前提是你是这个领域的业务专家。

写好文档

互联网广为流传的“产品经理和开发互怼”的事件层出不穷，这其中除了产品需求不明确之外，还有一个很大的问题是文档缺失导致双方出现争议时因为没有文档支撑，导致相互扯皮。一个团队，如果产品经理和开发配合不好，这个产品想要做好可以说是基本不可能。其实文档就像漫画中的“立字据”，起到了一个需求澄清作用。

当然，有的公司会搞所谓的需求澄清会，但是却没有文档，这种需求澄清会其实只是做个大概的解释，而无法深入到细节。缺点是开发环节会存在反复确认（这还是开发比较主动的结果），甚至是上线后才发现众多遗漏。因此，文档其实是必不可少的。首先文档可以帮助我们整理思路，重新站在另一个视角审视我们的设计，在开发之前发现和修正一些问题；其次，可以为开发提供详细的开发需求，降低开发过程中的沟通成本以及减少上线后的问题；最后，文档是产品设计的一个记录，当我们的产品经过几轮迭代后很可能会忘记当时设计的业务规则，而通过回顾文档能够让我们“不忘初心”。

如何写好文档？下面是几点建议：

1. 不要为了写文档而写文档。开发里面有个叫做翻译式注释，就是把代码的英文函数名称和变量名翻译一遍。这种还不如直接把命名弄清晰。同样的，文档一定不是把原型再讲述一遍，而更多地关注业务规则和强调容易疏忽的内容。

2. 文档是写给人看的。文档大部分时候不是给自己看，你需要给开发看，给未来承接你的工作的人看，给未来的你看。因此文档要注重可阅读性。什么是可阅读性？基础的包括层次、格式、字体、布局；再深一层就是文字的表达，讲人话，用易懂的话语表述你的业务需求。这里需要特别强调，千万不要随意造一些新颖的业务名词，光是理解这些新名词就需要耗费相当长的时间。

3. 多用图和类似案例，少打字：有些时候，我们写一大段文字可能不如一张图。譬如业务流程图，我们用文字一个个环节描述很难直观的感受，而使用泳道流程图会非常清晰。下面是一张简单的报销流程图，这样的流程用文字可能需要好上百字才能描述清楚，而使用一张图让阅读者一下就能够知道怎么回事。此外，对于有些不太好描述的内容，也可以使用类比的案例，比如可以参考 xx 的设计。

4. 重内容、轻形式：有些公司的产品需求文档要求有点变态，规定了很多条条框框，然后要求按条条框框填写。这种就是典型的形式主义，阅读起来却非常费劲。我曾经见过一个写了几十页的产品需求文档，内容确实非常详尽，但是形式化非常严重，如果是将这样的文档交给开发，开发估计都没心思看了。这个时候，我们就需要简化形式，比如将功能按模块拆分成不同的文档，便于对应的开发人员阅读。文档最重要的是传达内容，而不是满足某种形式主义的需要。

5. **不断迭代写作技巧：**文档交给开发后，可以询问他们的意见，也可以从他们的“吐槽”中吸取经验。千万不要把开发的吐槽当做是为难，首先承认自己的不足，然后在以后的过程中形成和开发的良性互动甚至达成默契，这样你就能提升你的写作技巧，更好地和开发配合推进产品的开发。而你自己也能在这个过程中得到有效的成长。

理清业务

上面两项达到一定程度后，公司也开始给你单独的模块进行产品设计了。这个时候考验的就是业务梳理能力了。梳理业务的关键点是深入了解业务。通常来说有以下几个渠道去了解业务：

1. 用户调研：用户调研是获取第一手资料的方式，缺点是耗费的时间长。调研的方式有很多种，比如面谈、调查问卷、群体焦点讨论、实际参与等。不论哪种方式，都要提前准备，比如你的调研目的、调研内容。同时，还需要具备很好的沟通技巧，很多时候，用户说不清楚他想要的东西，这个时候你需要引导用户说出他们的诉求。而如果是 B 端的用户调研，则更复杂。因为 B 端参与的角色会涉及管理层、中层、基层等多类角色，这些角色的诉求本就差异很大，如何在多个角色中挖掘出需求并能够整理出合适的解决方案非常考验产品经理的能力。

2. 查阅资料：查阅资料通常适合系统性地熟悉一个业务领域。比如，你要了解供应链管理体系，那么找一本供应链行业推荐的书是一个不错的选择。阅读资料的好处在于你可以对行业有整体的认知，同时在你去进行用户调研时，对话的时候能够听懂他们的专业术语，而从你口中说出来的行业术语也会增加你的专业度，从而提升用户对你的信任感。除了阅读书籍外，关注行业的一些好的公众号、观看视频也是不错的选择。

3. 竞品调研：竞品，尤其是行业内做得好的竞品能够给我们带来很多实质性的参考。很多业务竞品设计得已经很成熟了，这种时候我们可以直接参考。而竞品做得不好的地方我们可以改善。此外，通过竞品调研我们可以知道业务系统的操作习惯，在我们自己设计时可以参考，也可以优化。但是，请注意，更改业务流程的行为，哪怕你是做优化也一定要考虑推广的可能。这一点在 B 端产品上非常明显，B 端产品的用户通常不会太愿意学习新的知识来适应新的流程，因此更改流程一定要获得上层管理者的认可。否则，即便你的产品能够优化业务流程，但因为推广不开而丢失客户。

4. 内部讨论：在团队内部讨论一个业务的时候，能够倾听多方面对业务的理解，从而加深我们自己对业务理解的全面性。比如，技术会从技术可扩展性角度给出意见，这样会使得后期的产品可扩展性更强。再比如，运营会从产品能否推广的角度考虑，从而会促使你考虑设计的易用性和客户的接受度。

此外，互联网产品一般是具备工具属性的，有些是提高效率，有些是带来愉悦，有些是分享知识，在进行业务梳理的时候一定要考虑产品本身的核心价值，宁可做减法也不要轻易做加法，产品聚焦打磨更容易做出亮点和打造好的口碑。

整体产品架构设计

业务层面熟练之后，你已经是能够独挡一面的行业专家。此时，要继续上升的话就需要从架构层面考虑问题了。当然，这种时候往往是产品已经发展到一定程度，相对稳定的状态了。此时，产品可能会面临横向扩展或纵向打通这类问题，需要有一个生态支撑才能够走向更好的发展（当然，有些小而美的产品也能够持续生存很久）。这时产品其实是往平台型方向发展了，产品团队也会扩展成为多条业务线。而把控产品架构设计的往往是产品总监这一角色。如何提升产品架构设计能力？这个时候不仅仅是需要行业专家的知识，视野需要提升到产业领域。你需要了解这个产业有哪些参与者，他们是怎么运作的，你的平台能给他们带来什么价值，他们又能给你的平台带来什么价值。对于一个商业平台，一定是以互惠互利为前提才能够长期共存和发展的。同时，你需要提炼做事情的方法论，需要在日常工作中不断学习和总结，形成一套行之有效的方法论。这样，才可能在面临复杂多变的业务时能够游刃有余，轻松应对。

战略决策

如果能够达到这个阶段，恭喜你，你已经达到了产品经理的巅峰了。这个阶段通常有两类角色：创业者或者产品合伙人。你终于不需要再关注那么多细节，也不需要纠结使用哪个交互。但是，你身上的担子更重了，你需要从公司的战略维度思考问题，并根据社会的大环境来制定产品发展路线。这个时候，单独靠个人的能力其实很难做好这份工作，你需要不断和行业的大咖交流、参加各类论坛、学习标杆企业的做法，不断吸取新的想法、学习新的做法，这样才能够紧跟时代的潮流，让产品具备持续的活力，在日益激烈的竞争中树立门槛，立于不败之地。