深度｜如何让你的产品思维卓有成效？

深度｜如何让你的产品思维卓有成效？

编辑导语：一个正确的产品思维对于产品经理来说十分重要，产品思维有助于打造有效用、有利润和可持续的产品。本文作者分享了让产品思维卓有成效的具体方法逻辑，分别从五个方面进行阐述卓有成效的产品思维，一起来学习一下吧。

“如果你无法描述，那么你一定是没有真正理解”。

想透彻，写明白，说清楚，是表达观点的三个层次。谈起产品思维，我们仿佛每个人都能说上两句，但是话到嘴边时，却感觉咫尺天涯，不知从何说起。

按照维基百科的定义，思维是指可以独立于感官刺激而发生的有意识的认知过程。这句话看起来并不是那么好理解。

实际上，我们每个人都有许多不同的角色，比如，岗位只是我们的工作角色，一个人即可能是一名产品经理，他还可能是一个摄影师，又或者还可能是一个文字爱好者。

白了，不同的角色代表了不同的思维，所谓屁股决定脑袋。按照岗位维度来区分，开发工程师要具备工程思维，数据分析师要有数据思维。

简而言之，不同思维是思考问题的不同维度，所谓的产品思维就是站在产品的角度思考问题，是用户价值和商业价值寻求最优解的系统化且理性的权衡和决策。

怎么才算站在产品的角度思考问题呢？产品经理应具备怎么的产品思维才算有卓有成效呢？

一千个读者有一千个哈姆雷特，对于产品思维的理解大家也莫衷一是。

《卓有成效的管理者》一书里对于“卓有成效”的定义是“完成并使某项工作产生效益”。

产品经理本身是一个综合性，因此，当掌握的知识越多时，来自产品角度的思考也就越全面。因此，关于以上问题，我将从以下五个方面来阐述我所理解的卓有成效产品思维。

一、理解产品：是艺术更是商品

我相信，每个产品都倾注了产品经理的心血，经历了含辛茹苦的培育过程。我更相信，每个产品经理的梦想，都希望能够打造完美的产品。每一次迭代是产品力的体现，从想法到产品，中间潜藏着无数惊心动魄的故事。

但是，如果不追求持续正向增长的产品模式，反而是追求打造极致艺术，无疑是舍本求末。

俗话说：“自我欣赏的是艺术，他人接受的才是商品”。

产品是用以满足用户效用（需求和欲望）的商品，而商品最重要的属性就是交易，用户需要通过交易时间、金钱等才能去使用。因此，使用势必带来交易成本，只有给到用户的效用大于交易成本时，该“商品”的流通才会成立。

复杂的事务可以从不同维度来理解，如同成功的电影一定兼具艺术性和商业性。

艺术性，是指审美、内容和剧情都足够好，而商业性，则是经过市场检验，能够创造经济收益。

为了保证能够可持续的创作以及带来更多的影片，两者缺一不可。艺术性是品质保证，商业性则是现实刚需。两者并不矛盾，高品质引来观众的欣赏和评论，进一步提高其商业价值。

殊途同归，产品亦是如此，每个产品经理的灵感与艺术感的创新至关重要，但是更重要的，是能够平衡商业性后落地，从而打造可持续的、长期的、正向增长的产品模式。

产品经理最重要的任务，则是寻找用户价值和商业价值的结合点，打造有效用、有利润和可持续的产品，让正确的事情持续发生。

也是因为如此，如果从使用者的角度出发，人人都是产品经理，因为每个人只需要追求自我满足的产品艺术性。然而这可能距离成为产品经理还有天涯海角的距离，不仅是因为产品经理需要考虑商业性，更关键的是，产品经理的思考主体需要从一个人转变为一群人。

二、共情用户：从一个人到一群人

从事产品经理已有几年时间，时间推移，越发认可为什么说产品经理首先必须是一名用户，其次才是一个产品设计者的说法。

俗话说：“欲卖狗食，必先尝之”。

只有成为用户才能共情用户，才能识别用户的轻重缓急，进而识别用户价值。用一句废话文学来描述的话，那就是用户是一切产品的基础，任何的迭代都需要从用户视角出发。

产品经理最危险的境地，莫过于自以为是，不甚求解，认为自己最懂用户，最后陷入孤芳自赏。从共情一个用户到共情一群用户，产品经理首先要学会的是克制，然后是谦虚。

我一直认为，某种程度上，做产品经理并不难，学会克制自己的天马行空的想法，当获取足量的真实用户反馈后，往往只需要保持谦虚向用户学习，寻找只需要寻找用户反馈频次较多的问题并处理即可。

此外，我们还需要学会识别“真实用户”。问你一个问题，你的用户真的是你的用户吗？这句话读起来有点拗口，但却反映了一个现实：使用者可能并非决策者。

众所周知，To B 和 To C 最大的差异点是前者用户是企业，而后者是个人。

如果是个人，那么使用者往往就是决策者，用户的选择往往是被动而非理性，首先决策链路短，其次决策驱动力会体现在体验、冲动、跟风、情绪等非理因素，所以 To C 的核心逻辑是注意力经济和极致用户体验甚至病毒式体验，典型案例如抖音。

但是在面对企业客户时，往往使用者并非决策者，拿我所在的云计算行业而言，使用者往往是运维或 IT，而决策者可能是 CTO 甚至 CEO。

• 一方面，决策链路无论是从上到下推广，还是从下到上审批，都意味着涉及的关联利益方会很多；
• 另一方面，决策驱动力也变为合规、成本、收益等理性因素，而这些，往往又和使用方关联度不高。

因此，To B 行业大多数产品属于典型的“狗粮”产品，即买狗粮的和吃狗粮的不是一波人。

认识到这点，自然也就理解为何诸多 To C 转 To B 行业时，往往会折戟沉沙。用户模型变了，当无法共情用户时，产品自然也就会失败。

To B 行业里，一个非常典型的成功案例是钉钉，作为一个自上而下的管理利器，核心在于取悦管理者。

比如考勤打卡、“DING 一下”和“已读”等备受打工人头疼的功能，又或者免费电话、OA 审批和定时红包等与微信迥异的功能。无不体现了只要正确识别了“真实”用户，才有“到位”的产品设计。

产品经理的优秀与否，一方面在于能否成为用户，从而共情用户。另一方面，也在于是否能够尽调关联利益方，从而识别产品的“真实”用户。

三、洞察需求：在问题中寻求共性

1. 经济学的需求

我比较喜欢读经济学，在经济学里，需求是指消费者愿意并且能够在给定时间段内以不同价格购买的商品数量。这里有几个关键词：愿意、能够和给定时间段内。

实际上，任何行为的产生都离不开 MAT 行动三要素：M（motivation）动机、A（ability）能力和 T（trigger)触发，也可以分别对应着经济学定义的需求里的愿意、能够和给定时间段内。

这里我又查了字典里对需求的解释，字典定义需求是指因需要而产生的要求，需要则是指欲望这种内在驱动力，使之朝着所期望的目标前进的过程。换言之，需要可以看做动机，而需求是在欲望驱动下能负担的最佳选择，需求不仅需要考虑动机，还要考虑能力和触发。

2. 理解需求本质

产品经理肯定都听过马斯洛需求层次理论，在这个理论里，需求被分为 5 个层次：生理需求、安全需求、社交需求、尊重需求和自我实现需求。

可能某些童鞋要迷糊了，这里的马斯洛“需求”理论，为何不同层次看起来像是动机即需要呢而非需求呢？

马斯洛的“需求”层次理论，英文的是“Maslow’s hierarchy of needs”。实际上，这里的“needs”中文可能翻译为“需要”更合适，即为马斯洛需要层次理论。当然，我们并不是要咬文嚼字，而是为了更好的理解需要和需求。

举个例子，借用老亨利·福特一句话：如果你问你的顾客需要什么，他们会说需要一辆更快的马车。因为在看到汽车之前，没人知道自己需要一辆汽车。

按照之前的分析思路，我们可以得到一个结论：更快的马只是一个需求，但是顾客的动机是希望能够更快，而目前最佳的一个方案是提供一辆汽车。

3. 如何洞察需求

作为产品经理，我们不可避免的会面临海量用户需求，每个人都会基于认知和遇到的问题会提出符合自身利益的要求。因此，理解“需要”和“需求” 的重要性就显而易见了。

由于大多数用户无法表达出自己内在真实所需求的事物，更常见的是会根据已有信息描述出一个具体方案，最典型的案例即友商有 xxx，你们也需要 xxx。作为消费者，用户表达想法和提出需求理所当然，但是产品经理盲从需求而不思考动机，就会陷入浮于表面的境地，永远没解决本质问题。

因此，产品经理最重要的能力是要学会分析需求，要通过各种方法与手段找到“藏在表面信息之下”的动机，寻找需求里的共性，解决大多数用户的问题。

归根到底，洞察需求只需要做清楚以下几件事情：

1. 用户想了什么（动机）；
2. 用户说了什么（需求）；
3. 我们要做什么（方案）。

怎么找到用户的真实动机呢？可以尝试 5Why 原则，即针对一个需求，多问几遍为什么，通过一种方式尝试追问任何一个现象、任何一个问题、任何一个需求和任何一个想法背后的真实动机。

4. 需求与方案

在产品分析里所定义的需求，某种程度和经济学里的需求也很类似，消费者（用户）某个场景触发某种基于某种需要能够消费某个产品或功能。

需要是因，需求是果，前者来自于欲望的驱动，而后者是针对前者的一个实现，是产品，是功能，甚至是解决方案。时代或许在变化，但是满足需要的本质没有变。

从“用户”到“产品经理”，从“用户要求”到“用户需求”。需求的分析，是一个实现了主体转变的过程。产品经理的最终决策，也是基于各类约束条件下的最佳选择。

四、深耕场景：由需求触及使用

1. 为什么需要了解场景

在收集需求时，一般会采用用户故事的方式。用户故事用一句话简单描述：“作为一个<角色>, 我想要<功能>, 以便于<商业价值>” 。

在需求分析时，我们也可以借用这个框架来表述，可以表述为 2W1H：“我们为谁（who），用什么方法（how），解决了一个什么问题（what）”。

共情用户是为了了解「为谁做」，洞察需求是为了知道「是什么」，但是这个时候往往对于需求的理解还是不够深刻。缺乏场景，如同纸上谈兵，片面而又局限，抽象而非具体，很难得到「做什么」的产品方案。

有时候，我们迭代功能往往是因为竞争对手拥有了该功能，而非分析了用户的真实需求和场景。清晰的用户画像和使用场景，是整个产品的必备条件。在产品设计前，亟需进行一次细致而又全面的场景分析。

在网上看到过一个描述场景非常形象的例子，场景就像一双鞋子，只有穿鞋的人自己知道这个鞋的舒适度如何，比如包裹感，缓冲感等等，另外，鞋子还有休闲鞋和运动鞋等不同类型，不同的场景需要穿不同用途的鞋子。

因此，我们分析场景，不仅需要考虑自己穿鞋的体验，还需要考虑用户感受。

2. 场景是什么

对于场景一词，百度百科翻译为场面和情景，主要指戏剧、影视、文学作品中的场面。就像我们看科幻电影时，我们时常会惊叹场景宏大，看悬疑片时，会因时而转折的线索而屏息凝神。

场景两字拆开来看，“场”是来源于戏剧中的概念，指故事的一个小片段，是一个时间上的定义。而“景”是代表景物的意思，是空间上的定义，所以“场景”是时间和空间的结合，为了突出主题，推进故事情节，为剧中的角色的人设做铺垫。

回到产品上的场景分析，其实也类似。我们可以从两个维度出发：用户需求场景和用户使用场景，每个维度又分别可以从角色、时间和空间等属性进行结构化考量。

3. 用户需求场景

实际上，这里是需要和需求的分析，在前文洞察需求里我们已经用很大的篇幅来阐述差异点，对于我们分析场景时，两者很多可以共用，需求场景分析也是对需求分析的补充，用一句话阐述：“某某角色（who）在某某时间（when）某某地点（where）出于某种动机（needs）采取了某某方式（how）解决了问题”。

这里举个例子，我在从 0 到 1 设计某款云密码产品时，其背景是因为某 GB 国标的发布，要求所有关键基础设施信息系统（不展开了）都要求通过商用密码安全与应用性评估（简称密评）。

在继续深入调研时发现，尽管是 GB 国标，但是执行时间有先后，首批要求执行的是所有政务信息系统，且部分密评改造必须在 21 年左右的时间完成，而私有云的主要客户是政企与金融，如无法使自身云平台符合密评，可能导致未来无法遗失所有政企客户。

因此，为了应对未来巨大的潜在市场和，作为云平台产品经理需牵头设计一款符合 GB 密评规范的产品。

在了解了诸多信息后，该需求场景分析就变得很简单：“政企行业角色（who）在政策法规要求时间（when）的政务云互联网（where）出于信创指标/政策法规/上级任务等动机（needs）采取了密评定制改造的（how）方案解决了问题”。

对于用户需求场景的分析，往往我们可以用于评估需求的价值和重要程度。比如在这个例子中，所有政企客户必须过密评，而时间又比较紧张，现在是密评定制改造又需要耗用大量的时间、精力和金钱，成本较高。所以，为了增加存量政企客户粘度以及建立新的政企客户切入点，密评产品化势在必行。

4. 用户使用场景

当有了用户需求场景分析后，往往我们需要进一步分析用户使用场景来指导产品设计。

顾名思义，使用场景是有了某个产品、某个功能后，客户怎么与该产品或功能通过怎样的交互来完成目标。

还是用一句话阐述：“某某角色（who）在某某时间（when）某某地点（where）出于某种动机（needs）采取了某某方式（how）解决了问题”。

使用场景最关键的是将每个操作路径梳理清楚，最好能通过流程图来描述业务流程，从而达到精简的目的，而在流程的最后，一定是用户能够完成最终目标。

举个例子，IOS 系统来电界面实际上在处于不同的状态时，会有不同的交互展示。

锁屏状态：某某用户（who）在被拨打电话的时候（when）处于锁屏（where）状态出于防止误触的动机（needs）采取了滑动展示（how）解决了问题”。

应用使用状态：某某用户（who）在被拨打电话的时候（when）处于使用（where）状态出于防止被打扰的动机（needs）采取了横幅展示（how）解决了问题”。

可见，不同的用户使用场景决定了产品设计的是否好用，产品经理需要借助场景化设计，引入使用场景概念将需求从需求场景到使用场景来精细化产品设计，考虑的场景范围越广，同一个功能在不同的场景下具有不一样的交互方式，这也诠释了极致用户体验。

五、死磕价值：产品经理考虑边际量

在经济学上，对于交易的阐述，是指理性人在预期收益大于机会情况的情况下才会做出交易行为，且人的主观行为过程必然包含对预期得到什么、付出得到什么的思考。

“世界上不存在等价交换，交易创造价值”。

现实生活中不存在绝对的理性人，但是人们也会考虑效用和成本。产品经理的一大职责就是促进产品与用户之间交易，只有完成了交易，最终使双方受惠。

边际量可以拆解为边际成本和边际收益，所有产品诞生都是都是一个从 0 到 1，再从 1 到 N 的过程。因此，“边际”的意思就是“每多一个”或者“增加的增量”，边际成本就是每增加一个量要产生的成本，边际收益就是每增加一个量所带来的收益或效用。

举个生活中典型的例子会更好理解，在诸多快消店有可乐免费续杯的服务。

看似消费者大赚特赚，享受固定价格下的无限可乐。实际上，可乐这玩意，第一杯第一口永远是喝的最爽的，即收益最大，接下来的任何一口可乐，都会减少收益，遵循边际效益递减规律。而每一口可乐的另一面，会带来饱腹感，肚子容量有限，成本也会越来越高。

因此，也许当消费者喝了一个中杯可乐后，大多数已经没有任何欲望想要继续续杯。因边际收益原理，商家通过诱人的边际量设计未付出多少成本反而吸引了更多消费者。

除了生活中的一个案例，其实在任何规模效应的行业都存在着边际收益原理，比如我所在的云计算行业，公有云的发展具有明显的共性特征，在企业前期会有巨额的重资产投入，比如云计算数据中心等，在中期目标都是朝着规模效应和发展增值服务前进，寄希望于在后期能够实现规模利润。

规模效应的本质是随着资源池规模的增长，服务一个客户的边际成本会趋向于 0，但是当客户规模不足时，固定的资产则会使成本过高导致严重亏损。

所以，企业会考虑边际量，在边际收益和边际成本之间寻找平衡。

当产品经理把边际量运用在产品设计时，就能理解创造一款产品为何常说 MVP 最小可行版本方式进行验证。这里其实也潜藏着边际量的考虑，只有当一个产品前期投入成本足够小时，哪怕所能产生收益不多，也能使之间的差距尽可能的少。

因此，构建最简洁的可用的产品往往能带来更低的试错成本。

此外，产品优化的本质为了通过增加效用或者降低交易成本来促进交易，比如为产品增加新的功能或新的特性，或者优化性能、路径和动效，任何一项优化都需要考虑边际量。

产品是面向未来的，在需求分析和方案设计时，定性定量都只是预期价值。所以，往往以最小 MVP 可行版本进行发布是一个可以遵循的准则。

同样，在做功能迭代时，产品经理也应考虑边际量，我非常认可一句话：“不要让完美成为更好的敌人”。

作为产品经理，追求极致用户体验理所当然，只有不断追求细节完美才能打造完美产品。但是，交付手中有的，而非脑中想的。当追求完美反而使此时已经变的更好的产品只有成本没有收益时，反而非智者所为。

产品思维并非只可意会不可言传。产品、用户、需求、场景和价值等篇章因才疏学浅无法尽善尽美，只能算当前的一点小总结。

从产品思维起，自上而下罗列了 5 个如何产品视角看待一个问题。实际上，我知道这仅仅是九牛一毛，比如还有设计、还有数据、还有运营等等。只有在充分的信息和充分的吸收后才能有相对理性的权衡与决策。

每个人心中都有一个理想国，但是没有人找到理想国。产品思维是接近理性的，是在充分自我认知的基础上，寻求约束条件下的价值最大化。

绝对理性的产品思维并不存在，我们只能在掌握更多的知识后，让产品思维即有深度，也有广度。

#专栏作家#

零度Pasca，公众号：大兵闲记，人人都是产品经理专栏作家。关注前沿技术趋势，理性数据主义者；热爱阅读，坚信输出是沉淀输入的最好方式，致力于用产品思维解决用户共性问题。

本文原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash, 基于CC0协议