产品经理常用思维模型以及流程图
看过不少文章都提到这样一个问题，在产品同质化严重的今天，许多产品经理其实只是“功能经理”、“原型仔”。大概的意思就是说有些产品经理缺乏深刻的需求洞察能力、驱动企业价值的商业化思维等核心能力，每天重复着“接需求-原型”的工作，与市场、用户发生了脱节。
身为一个产品经理，不往大的讲奢望可以通过产品改变世界，但是往小的说，我们始终要抱着一个为用户解决问题，实现用户价值的心。仅仅这样可能还不够，在互联网红利已经逝去，整个产业趋于理性化的今日，我们还要争取实现用户价值与企业价值的平衡。
本篇文章跟大家分享产品经理常用的思维模型以及流程图，有些可以帮助我们快速梳理业务逻辑，有些可以帮助我们用产品的思维去处理问题。多模型的思维有助于我们遇到不同问题都能找到最合适的方法论模型来解决问题，希望对你有零星的启发作用。
产品经理常用的思维模型
思维模型的作用在于帮助产品经理快速思考、分析问题，可以少走许多弯路。思维模型有很多，不同的问题需要不同的模型，在这里没有办法一一列举，给大家分享几个常见的模型。
01 KANO 模型
KANO 模型是东京理工大学教授狩野纪昭(Noriaki Kano)
发明的对用户需求分类和优先排序的有用工具。产品经理经常会遇到各种需求，利用KANO模型可以帮助我们进行优先级排序，分清楚哪些是必须要优先做的，哪些可以放缓实现的，哪些是可以放弃不做的。
在KANO模型中，根据不同类型的需求与用户满意度之间的关系，可将影响用户满意度的因素分为五类：必备型需求、期望型需求、兴奋型需求、无差异需求、反向型需求。
KANO模型需要回答的是，这个需求我做还是不做，做了之后用户会的满意度如何变化，不做，用户的满意度又会如何变化。它描述的是需求具备程度和用户满意度之间的关系。如下表：
所以，根据功能实现程度与用户满意度之间的关系来进行优先级排序的话，必备型需求>期望型需求>魅力型需求>无差异需求>反向型需求。
02需求价值模型
在评估需求优先级时，有些朋友会用到“紧急性与重要性”四象限，包括紧急且重要、紧急但不重要、不紧急但重要、不紧急且不重要，关于紧急性、重要性四象限模型不做过多介绍。
在这里想跟大家分享另外一个模型，同样可以用于需求的优先级排序，那就是按照“资源投入”与“产出情况”两个维度来分为四个象限。这个其实是基于投入产出比（即性价比）来对需求的优先级进行排序，性价比用公式表达就是：性价比 = 价值/成本。所以我们可以用这两个维度搭建一个模型用来评估需求的优先级。
横坐标代表功能复杂程度，越复杂的功能意味着需要投入更多的人力与时间成本。
纵坐标代表需求带来的价值，需求的价值应该包括用户价值与商业价值。
衡量一个需求的的用户价值可以从以下两个方面展开：
- 需求是否涉及多数核心用户群
- 需求是否足够高频、刚需
长远的商业价值应该是基于良好的用户价值的，两者是螺旋式促进的关系。
03产品画布
产品画布是一套完整的产品思维模型，它的特点在于综合考虑了产品因素与市场因素，要求产品经理不仅仅从产品、用户本身去思考，同时也强调了财务、市场方面的思考，可以锻炼产品经理的商业思维。
利用产品画布，可以帮助我们用产品思维去为用户解决问题、实现商业价值。同时，产品画布也可以用于竞品的分析，帮助我们对竞品有更为全面的了解。
图来自三节课
04SMART原则
SMART原则是管理学上用于指导目标制定的一套方法论，在企业管理中，不管是企业层的，还是部门层级的，都会根据经营的需要制定目标。那么如何判断我制定的目标是否合理呢?其中一个判断标准就是SMART原则。
S（Specific）——具体明确的
所谓明确就是要用具体的语言清楚地说明要达成的行为标准。没有具体明确的目标，团队成员的行动往往十分混乱，效率低下，毫无章法可言。
有时候我们围绕方案、功能讨论得热火朝天，几个小时过去了，可大家依然得不出统一的观点，这时候不妨回过头思考，我们的具体目标是什么？本次讨论方案、功能是否能够帮助我们实现这个目标？
M（Measurable）——衡量性
衡量性就是指目标应该是明确的，而不是模糊的。应该有一组明确的数据，作为衡量是否达成目标的依据。
例如：如何评估一个上线的功能是否达到预期？我们在需求阶段就可以提出相关的数据指标，以此来告诉团队成员，这个功能在上线后可以通过采集哪些数据指标来衡量是否达到预期，这也是我们进行数据埋点的其中一个原因。否则，一个功能上线后，产品团队在复盘时，根本没办法去验证功能的价值，反正上线了就上线了。
A（Attainable）——可实现性
目标是要能够被执行人所接受的，通过努力是可以完成的。制定目标需要综合考虑现有的内部环境、外部环境，确保目标能够团队成员认同，驱动实现。
一个MAU（月活跃用户）为10万的产品，如果制定了未来一年MAU达到1亿的目标，这个目标对于一般的玩家来说基本上是不可实现的，这样的目标毫无意义。
R（Relevant）——相关性
目标的相关性是指实现此目标与其他目标的关联情况。如果实现了这个目标，但对其他的目标完全不相关，或者相关度很低，那这个目标即使被达到了，意义也不是很大。
T（Time-based）——时限性
目标特性的时限性就是指目标是有时间限制的。这个很好理解，没有目标没有明确的时间计划，会影响我们下一步的方案落实与执行安排，毕竟你只了说要实现某个目标，但是没有提出什么要完成。
看到了一则旧新闻，滴滴在2020年制定了未来三年的目标“今年3月，滴滴曾在内部宣布未来三年的“0188”目标：每天服务超过1亿单，国内全出行渗透率超过8%，全球服务用户MAU超8亿。”
仔细看看这个目标，它是符合SMRAT原则的，明确提出了在什么时间限制内要达到什么目标，具体衡量的数据指标是什么。
05MVP（最小可行化产品）
最小可行化产品概念源于《精益创业》，书中给出的定义是：
“所谓最小化可用产品，是让开发团队用最小的代价实现一个产品，以此最大程度上了解和验证对用户问题的解决程度。”
MVP的作用在于，我们可以通过最快的速度、最小的资源制造出一个最轻量级的可被用户试用的产品，提供给用户使用，再根据用户的反馈来对产品进行优化迭代。而不是，耗费巨大的人力资源，时间，开发一个自认为功能十分完整的产品，做出来之后却与真实的用户需求相差甚大。
例如，当你希望做出一款市场喜爱的、最好吃的甜甜圈时，在MVP思维的指导下，你的创业步骤应该是这样的：
第一：先用最快的速度，最少的资源投入，做出一款能吃的甜甜圈，显然它肯定不是最好吃的甜甜圈
第二：向你的目标用户推广这款简单能吃的甜甜圈，并与用户进行交流，收集反馈意见，比如说：
你们觉得这款甜甜圈哪最好？
如果你可以选择加配料，你会加哪些？
你喜欢什么甜甜圈造型？切开的还是一体的？金黄炸透的还是脆嫩相间的？
第三：现在你可以就采集到的用户反馈，去升级迭代你的甜甜圈了。
产品经理常用的三张图
业务流程的梳理是产品经理的基本能力，在接到需求后，对整个业务流程进行梳理，可以帮助我们发现更多的分支场景与细节问题。
同时，在需求编写阶段，过多的文字的描述，你可能觉得把话说清楚了，但是程序员可能会看得一头雾水，相反，一份简明扼要的流程图，可以有效提升双方的沟通效率。
常用的有普通流程图、泳道图以及状态机图，我们很多人其实都有画过，在这里简单跟大家介绍一下。当然了，除此之外，产品经理在日常工作中还可能会用到其他图，比如原型图、用例图，产品架构图、功能结构图等，不一一列举，有兴趣的朋友可以自行百度了解。
01普通流程图
什么是流程？个人理解就是为达成一个目标需要进行一系列有序的执行操作。
打个比方，如何把大象放进冰箱。其实就是三个核心步骤，第一步：把冰箱门打开；第二步：把大象装进去；第三步：把冰箱门盖上。当然了，实际执行起来可能还会有其他分支场景，比如冰箱容积>大象体积怎么办，冰箱容积＜大象体积又该怎么办。
之所以称为普通流程图，是便于跟后面即将介绍的泳道图做区分。通过普通流程图，你可以看到发生了什么操作，但是你没有办法知道这个操作是由哪个角色或者哪个系统执行的，也没有办法看到每个操作在整个流程中处于哪个阶段。
普通流程图的特点就是逻辑清晰，界面简洁，适用于仅仅需要了解整个核心流程，不要求清楚的展示角色或者系统之间的交互过程。
以一个支持短信快捷登录以及账号密码登录的APP为例，其登录流程图可能如下：
02泳道图
泳道图，也称为跨部门流程图，是普通流程图的进阶版，相对复杂些。
与普通流程图相比，泳道图有两个特点：
第一：可以体现出某个动作发生在哪个部门、系统或者角色；
第二：可以体现出某个动作所处的流程阶段。
如下图，横轴表明了整个下单流程涉及的子系统，纵轴则表明了下单流程的三个阶段。
绘制流程泳道图的时候需要根据看图的人是谁来考虑颗粒度的问题，如下图只体现了正向的核心流程，可能比较适合产品经理、开发人员对整个下单流程方案的宏观把控。
对于其他异常场景，如支付前的取消订单，发货前的退款，发货后的退款退货以及收货后的售后流程，并没有体现出来。我们也可以就这些子流程绘制单独的流程图，这个往往是程序员在开发时功能时比较关注的地方。
绘制流程图的时候，尽量避免流程之间的交叉、缠绕，因为这样会让看的人十分痛苦。可以适当调整泳道的顺序，以保证流程的清晰、干净。
03状态机图
状态机图，也称有限状态机图，是描述有限个状态以及这些状态之间流转情况的图形。
状态对用户来说是一个很重要的信息，它让用户清楚的知道业务处于什么阶段，从而减少茫然与焦虑感。
比如我们每个人都见过的订单状态，包括待付款、待发货、待收货、已完成、已关闭。
再比企业要求员工通过考勤软件提交请假申请，那么员工提交的请假申请大致有以下几个状态，审批中、审批通过、审批拒绝、审批撤回。
产品经理需要通过状态机图告诉开发，有什么状态，每个状态之间是通过什么事件进行流转的。以员工端的请假申请流程为例：
写在最后
利用思维模型以及图形工具，可以帮助产品经理快速分析、解决问题。以上只是众多思维模型中的一部分，平常我们遇到某些有用的模型时，可以多加总结与整理，模型也是要多运用的，否则只是一堆无用的理论，分析得多了，良好的思维习惯也就形成了。
当然了，思维模型并不是万能的，还需要具体问题具体分析，毕竟我们的目的在于解决问题，而不是仅仅为了套用模型而去使用模型。
既然来了，说些什么？