产品经理是一个令人向往的角色，许多人想做出跨时代的产品。因为多数产品经理对产品没有决定权，这个角色也饱受争议。那么产品经理的定义究竟是什么？怎么理解这个岗位？一起来看看本文的分析吧。
对于产品经理这个职业或者说岗位的认识，最早来自于知乎的系列回答，在很早之前就萌生了对这个职业的向往。毕业之后从运营转岗产品，从新媒体到金融行业，一步步走向未知的领域，探索更多有意思的业务。
在前人的肩膀上和实践中，我产生了许多新的认知，一时心血来潮，想要在知乎更新产品经理专栏系列文章。So，这就是我写作的初衷。
产品经理是一个令人向往的角色。许多人想成为产品经理，如同 Steve Jobs 或者张小龙一样做出 Apple 或者微信这般跨时代的产品。这个角色同样饱受争议，因为多数产品经理对产品没有决定权，这导致了一种普遍观念，认为产品经理无非是链接业务和开发的工具人。但是这件事并没有那么简单，正因为产品经理被要求同时具备了广度和深度，这注定了这个角色在很长的一段时间内都会被人误解。
什么是产品经理？在我的理解中，我一直认为：
产品经理的特质在于拥有产品思维，利用产品思维去解决问题是产品经理的职能。
产品经理是一个跨领域的专业，需要解决很多新的问题，如果固化自己的知识体系和发展方向，就不太可能在产品经理这个领域有太高的成就，拥有产品思维是解决未知问题很好的武器。即便未来不从事产品相关工作，但产品思维依旧存在价值。
产品经理主流的称谓叫做 PM，Product Manager。很少有人知道产品经理还有另一个称呼：PD，Product Designer，意即产品设计师。
从字面上可以窥见端倪，PD 和 PM 并不相同。PD 更为纯粹，PM 则像是在 PD 的基础上多增加了一层管理的含义。这要求不仅能设计好产品，还要管理好产品，为产品负责。我相信很多人都想成为 PD 而非 PM，梦想着自己设计的产品能够改变世界，而不是因为管理执行取得成功。
这些历史性的创新不断地激励着我去成为一个更优秀的产品经理。但是也要看到并非所有的产品依靠创新的设计就能获得成功。
在我看来，产品的设计能力和管理运营能力都同等重要。孰优孰劣，这是一件很难有定论的事情。所以在踏上产品经理这条道路那一刻就需要思考未来是想成为 PD 还是 PM，这决定了应该积累哪些能力以及发展的路径。
不过国内的互联网环境存在偏差，国内互联网产品都偏向于 PM，PD 的职能更多地被 UI 设计师们所承接。企业都希望招来的 PM 能从产品生命周期的各个方面做到极致，但较低的岗位入门门槛又使得这个职业 “鱼龙混杂”，所以出现了我在前言部分所说的被误解的情况。
产品经理在产品生命周期需要做的事情：
除了这些能力，产品经理如果还能够掌握代码、销售、财务和融资的职能，那几乎等同于一个 CEO 了。这也是我为什么一直认为超级个体只会诞生在产品经理这个群体。预想一个暴论：
在未来 AI 加持的前提下，产品经理一个人几乎可以解决所有问题和需求。
回过头来讲这些基础能力。如果决定了走 PM 或者 PD 的道路，那么有没有办法专注于某些能力发展，就像给游戏中不同职业的角色加上技能点呢？在我看来，这种培养专精技能的环境并不存在。所以在刚入行的时候要尽可能地去了解和实践，在掌握基本素养之后，才有可能成为一名优秀的产品经理。就像大部分中学生需要接受九年义务教育，让心智更成熟之后才有可能选择更适合的院校和专业。
不过，这个逻辑在产品经理这个岗位上并不成立。在研发领域，有许多中大型企业有 “技术架构师” 的职能，负责推进公司技术架构的迭代和演进，但是 “产品架构师” 这种职能似乎从没听说过。也许原因可能是研发领域经过了长足的发展，技术架构存在一个方向，有更多经验用于沉淀和运用。但是产品很少有明确的方向，大部分产品 Leader 仍需要对业务和营收负责，这种情况在小厂尤为明显。
因此，在考虑写这本手册的时候，除了满足自己输出免费内容的初衷，也在不断思考产品设计有哪些通用的方法论。有些想法可能不是原创，但是通过重新组合和整理，希望能够帮助大家走得更远。
从宏观角度看，“产品思维”可以被理解为一种深入挖掘问题本质并重新组织生产力的策略。为了深入了解，我们可以将其解构为以下几个方面：解构、抽象、重组、新科技的应用、面向未来的视角以及克制的迭代策略。接下来，我们将逐一探讨这些方面。
开始这个小节之前，先来看这么几个场景，在后文会进行详细说明：
产品经理需要训练一种肌肉记忆，保持好奇心和优化意识。察觉到生活中的诸多现象，思考现象背后原因的同时，尝试去拆解对象，删除低效环节，重组成更有效的新对象。
可能一开始并没有很多机会去拆解工作上的业务，但是可以通过解构、抽象、重组自己的日常生活、学习和工作进行练习：
示例：顺风车产品对私家车出行的重构
不知道大家有没有过在节假日坐过顺风车回家或者拼车上下班的经历。顺风车的作用是乘客以比较便宜的价格购买私家车的一段行程，帮助司机赚回一点油费，让乘客达到目的地。古早时期的顺风车并没有现在通过滴滴出行预约来得方便。在以前，司乘双方主要通过论坛、贴吧等途径发帖来寻找同路人，效率较低，安全性也不能保证。
作为产品经理，可以尝试通过运用解构、抽象和重组的产品思维对顺风车产品进行优化。假设有一个场景：司机 A 周五晚上 8 点从上海恒隆广场回到苏州和风雅致小区，车上有 3 个座位。解构后的信息为：
乘客甲周五晚上 9 点下班，希望搭一辆顺风车跨城回到苏州老家。解构后的信息为：
完成需求解构之后，将司乘双方的需求进行抽象，让复杂的信息变成结构化的模块，最终完成匹配。
当然，现实情况并没有那么简单。把这个例子的复杂度提高，这更符合现实情况。以滴滴出行作为例子，乘客甲是 V7 里程会员，对顺风车的舒适度有一定要求，周五晚上他可能加班到 9 点之后，也有可能在 9 点之前就下班。司机 A 是接过 500 单顺风车的老司机，他再接了 1 个人拼车，到达苏州火车站。那么经过细化的信息就变成了：
出行应用的顺风车产品设计要远比这个示例图来得复杂，但复杂并不是要强调的重点。在这个例子中，原有的 5 个信息变成了 12 个，但这些模块仍被框定在抽象出来的 3 个模块中。如果在后续需要不断增加信息，产品顶层设计抽象出来的模块也能够进行良好匹配，而不至于面临重新设计的挑战。倘若在产品设计初期的抽象不到位，那么每次进入需求的深入探索都要大幅修改已有的产品功能，这并不是产品思维，而是信息化。
对产品进行解构、抽象、重组的过程像是给楼房打地基，地基是否稳固决定了建设高度和使用年限。
产品思维被广泛地提及，很大程度上是因为互联网产品的大量出现。由术及道，分析一个产品做的好不好，要看产品经理是如何进行思考的。现在回头看这一节开头提出的场景也许会更有感触：
产品经理在接收需求的时候，会图懒，用户说什么就做什么。对于需求必要性思考显得格外没有意义，A 需求不做，还有 CDEFG 等着你。这种思维比较危险，这等同于你抛弃了思考，选择了执行。对产品来说最重要的事情不是画原型，不是找到方法，而是去定义好那个问题。基于这个背景再去思考为什么要有产品经理？为什么开发不直接跟业务部门对接？一个很重要的原因就是产品经理会在中间发现各种各样伪装成需求的解决方案、伪装成需求的提案、伪装成需求的要求。
产品经理需要找到需求背后的人和问题，甄别、洞察之后，再去考虑找解决方案。
归结于一点就是要有解构对象的能力，而不是说我有一把锤子，满世界找钉子。
第二个例子是解构之后进行的抽象。正常情况下，作为宝爸（产品经理）可能翻箱倒柜找饼干。但在这里，首先需要思考一个问题，“想要吃饼干” 这件事是解决方案还是用户需求呢？答案是前者，饼干是用户提供的解决方案，而真实的用户需求是 “宝宝饿了”。宝爸在这个时候只需要喂宝宝能够填饱肚子的食物，而不是掉进在家里找饼干的陷阱。
用户提出一个诉求时，你不能简单地满足诉求，或者简单的把诉求稍微修饰一下就转发给开发。产品经理的第一职业素养就是不能把业务部门发来的需求直接转发给开发。当用户喊着想要饼干时，多问问自己为什么，为什么半夜要饼干？是不是饿了？一定要饼干吗，其他食物是否也能满足？…
第三个例子和重组相关。这个例子就不细说了，在举顺风车出行的例子中已经提及过。重组的前提是抽象，只有抽象做的好，产品设计才不会重复进行变更。
善于解构、抽象和重组的思维是成为合格产品经理的第一步。
尽管对现实问题的解构、抽象和重组不一定总是提高效率，但这种思考问题的方法能够深化我们的理解并可能降低机会成本。更为引人注目的是，当这种方法与新技术，如互联网技术结合时，可以发生有趣的化学反应。互联网技术提升了二进制数据的传输速度，这种高效的传输能力为众多现实生活中的数据传输场景带来了批量化的改进。
互联网传输能力为所有可以被抽象成信息传递的行为赋予了新的生产力。就像上图所示，直至现在，我们还能持续发现新的应用场景来进一步放大这种传输能力的价值。随着5G的普及，高速网络不仅仅开启了文字和语音的传递，现在还可以高效地传输 4K 画面，这为我们带来了更多的可能性。
比如前几年融资火热的生鲜业务，以往你需要去到线下菜市场或者超市，对比不同商店的菜价，选择不同店铺的蔬菜，这个过程可能需要耗费 2-3 个小时，最终才能买好一日三餐所需要的食材。现在将传统线下对比选购的形式转换成线上浏览、比价下单、外卖到家的方式，大大节约了买菜的时间，同时确保了生鲜的价格和质量。当然，另一方面也要归功于强大的物流冷链以及标准化。
再举个通俗易懂的例子：线下支付。现在除了老一辈的人，几乎没有人出门携带现金。去银行大额取款还需要申请，小偷扒手也少了很多。
新技术的诞生出现在极少数的时刻，当机会来临时，产品经理需要奔跑在潮流前沿，不断思考新技术的使用场景，以及它是否能够解决传统难题，解放生产力。
列举其他一些我印象深刻的新技术应用：
产品经理有一项能力是要求会进行数据分析。许多公司都重视数据分析，认为数据分析能够带来所有问题的答案。但是数据分析的结果只能反映过去发生了什么，过去做的事情带来了哪些结果，而并不能预测未来。如同证券交易中的技术分析，数据分析是面向过去的解释。
产品经理更重要的能力不是回顾，而是预测未来会发生什么。举一个极端的例子，在车机领域，有百度、特斯拉以及华为等智能驾驶解决方案。作为该领域的产品经理，中控台产品经理被要求需要面向 4 年（48 个月）后的用户需求进行设计。因为一个车型从立项到量产，往往需要 4-5 年的时间。如果车型只是为当下市场设计，等到面世的时候早已过时。
让自己设计的产品兼容未来，让实例抽象为简单的对象便可以面对未来的不确定性。之后无论再有多少繁杂的信息都可以运用抽象的结果进行重组。除此之外，尽可能做到简单。越简单的理论、结构具有更强的生命力。
复杂的设计带来了更高的成本，复杂的会员体系是最优解吗？
简单是避免设计短命的前提，但是简单并不是商业化的最优逻辑，我们使用的手机 App 无一不在变得更为复杂，更难以理解。我始终觉得二八原则在产品设计是适用的，就像 TrandingView 或者我自己正在使用的小众看盘软件 PonentStock（非安利），这些产品的设计都远比下载一个大体积、看不懂的产品要清晰得多。80% 的用户只用 20% 的功能，花时间和精力做好那 20%，合适好用才更加重要。
产品设计的核心诉求是用最合适的方式解决用户需求。但以提高产品竞争力为由，增加技术含量和用户学习成本这件事每天都在发生。我从事的券商行业，新用户几乎难以理解这些应用应该如何使用，但是我身边的每一个产品经理都认为使用产品的用户天然是那批知道如何使用的用户，忽略了用户学习的环节。
可能这就是 “克制” 的典范。使用 Flomo 的用户不在意产品的功能简单，购买 iPhone SE 的消费者对性能不感冒，“简单” 和 “好用” 才是这些产品的竞争力。当你正在设计一个大量用户会使用的产品时，“克制” 是你的救命稻草。这也解释了为什么大部分国民级软件（如微信、美团）的主功能界面几乎不会变动的原因。
产品思维最精华的部分就是 “减法思维”，我更乐意称它叫做中庸之道。我想所有产品在起初都不会想要变得复杂，产品设计的目的是为了满足用户需求，但是因为需求而让产品变得复杂并不是产品设计最初的目的。做一个面面俱到的产品清单并不难，但是如何决定最重要的 10%，甚至是 5% 的功能，那是一场面对内心的战争。
需求是远远做不完的。无论公司规模大小，永远都会面临三不够：人不够、钱不够、时间不够。产品经理无时不刻都需要排序需求的优先级。如果此时要做的迭代时间只有 1 周，你会如何做减法，选择需求？对外来看，每天都会有用户教你做产品，用户的需求是切实存在的，如何做好减法将 ROI 做到极致，又能满足大部分用户的诉求？
“什么是产品经理” 这个命题非常难写。可能这篇文章到最后都并不能给人应该清晰的答案。由你可见，我喜欢那些具有创造力的 PD，同时我也钦佩管理运营能力足够强的 PM。我的认知还不够，并不能代表主流的一些观点，希望大家能够辩证地阅读本文。如果能够提供一些帮助，那就更好了！
本文由@Brinkey 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。