决策，主要是做选择，我们无时不刻都在做选择，人生面临的选择太多了，人生方向路口的选择、选学校、选专业、选公司，选择你的生活圈、城市，小到吃饭去哪里吃、吃什么、穿什么衣服。
提问:3个水蜜桃，都是你的，一个很大看上去很好吃，一个一般大，一个较小，你先吃哪个？
我的答案和分析在最后分享，虽然很多选择不重要，当是其实你的选择会反应出你的当前状态。
很多选择看上去不痛不痒，但是其实积累起来，会直接影响你都命运。
我们需要做更多的正确的选择，毕竟选择大于努力。
作为产品经理，我们的决策能力对产品的成功或失败有着直接的影响，不仅决定了产品的发展方向和功能特点，还塑造了整个团队的方向和动力。
文章会以涉及到产品相关的主要决策进行展开:
产品战略决策、人力资源投入决策、需求版本决策、需求方案决策。
产品经理在不同岗位决策的内容是有很大差异的，比如产品总监/产品负责人、高级产品经理主要负责产品战略、资源投入。中级、初级产品经理主要负责需求版本、需求方案决策。
01 产品战略决策
涉及产品的长期方向和愿景，以及如何与公司的整体战略目标相契合，包括确定目标市场、产品定位、核心竞争优势以及产品的整体发展路径。
方向、目标：
确定产品的目标用户群体，产品的核心能力以及价值。在不同阶段，方向和目标都可能会随着实际产品市场情况、业务发展、行业发展、技术升级进行调整。
比如：
目前AI的发展进入新的里程，对所有行业所有产品的影响非常明显，各界大佬都在说：“所有产品都值得用AI重做一遍”“每一个产品都值得重做一遍”。
很显然，目前很多产品都已经在原来的产品上开始植入AI、AIGC，为了什么？
为了提高产品竞争力，提高产品的价值。现在世界变化太快，如果你的产品目标和方向一层不变，很容易就被淘汰掉了。
之前看过快手的发展史，我觉得比较能明显反应出产品的方向和目标会随着自身的发展、行业发展、技术升级不断的调整。从网上找了张图：快手是做GIF起家的，最后搞成了短视频分享平台。
产品的整体发展路径:
产品规划图: 产品架构图、产品线路图 、产品蓝图，都是对产品的具体规划，能看出产品的形态，是实现产品目标和方向的具体方案。也是产品的概览图。
产品规划图主要给2类角色看，一个是领导层，一个是产品或项目团队。
不管是针对B端、C端、G端的产品，一定都会有规划图，项目经理需要根据规划输出WBS工作分解计划，产品经理需要根据计划产出PRD文档。
产品架构图:一个产品是由各种各样的功能组成的，产品架构则是将这些不同的功能围绕目标进行分类、整合，可以让团队了解产品的业务流程、功能框架和设计思想。
图片来源ProcessOn
如果这些功能不分主次、没有逻辑地堆砌在一起，用户会不知道如何上手，不知道怎样才能找到自己想要的东西，也不知道自己的操作会带来什么结果，最后只好沮丧地带着深深的挫败感离开。
因此对于产品架构而言，在我们分析了所有产品功能之后，就要对产品功能之间的各种关系进行分析，最终形成由各种功能构成的产品系统的模型，成为一个整体形态。
产品线路图主要是将产品以业务流程、业务类型、用户场景和用户完整路径来进行划分，是产品的行动路线地图。
图片来源ProcessOn
所有产品都不是一蹴而就，特别是产品体量变大以后，会形成产品生态。比如要打造智能家居全品类产品，像小米，从做手机开始，扩展到排插开关业务，这就会形成一条排插开关业务的的线路发展图；还有照明业务发展线路图、安防业务发展线路图、运动、厨房卫浴、宠物与植物等等，每个业务都会有一条产品线的发展线路图。
产品蓝图是展望未来的样子，就是产品中长期的一个规划，是未来至少半年一年的样子。产品蓝图通常也是业务功能组成，是产品的全貌图包括未来的部分。
产品蓝图和产品架构图有什么明显区别？
产品架构图更会从产品本身出发，是产品的框架结构，框架构建的好，产品才会更加清晰。好的产品架构（如微信）囊括的功能非常多、涉及的业务非常多，但对绝大部分用户来说，可以获得一个简单、流畅、清晰的体验；而不好的产品架构则可能会让用户迷路，散乱、冗余感比较强。
而产品蓝图更多的是从产品能力出发，会体现出产品未来的能力，会包含产品所有的功能模块和未来的能力，他们是融合在一起、有关联关系的但又可以相互独立运转。
02人力资源投入决策
一个产品或项目需要投入多少资源，一般都是根据上层战略既定的上线时间和具体业务需求情况进行推算+综合考量后拍出来的。
先说说项目，一次性投入的这种：
- 确定好上线日期后，根据日期反推出各关键里程节点；
- 同时需要项目经理或者产品经理拉出WBS项目计划表，由技术经理拍出所有需求开发完成所需要的人天工作量，在来算出至少需要的研发人数。
- 根据需求量和研发周期，由测试经理拉出测试计划，确定好测试人员投入。
- 还有产品经理、UI的投入人数和时间也是根据时间和需求量进行评估的。
项目需要投入的各角色人员拉出来后，需要项目负责人和公司领导进行申请确定，资源是有限的，如果项目是外包给乙方，乙方通常要考虑项目盈利来做资源投入；如果项目是公司内部自己完成，也要考虑已有资源和项目优先级 以及公司的战略。
一般在项目启动会的时候，就会把项目投入的人力资源全部确定好，如果在项目进行中出现变动和风险，项目经理需要及时增减资源的投入情况。
再说产品，需要持续投入
产品的第一个版本，如果是按项目模式来做的，那就是按项目模式来确定投入的资源。
如果是按互联网方式来做产品，那就是按MVP模式来做，先搞出一个最小可行性产品，这样前期投入的人力资源不会很多，整个团队会是一个相对稳定的状态，至于后续的人力投入，就会根据产品上线后的市场情况来确定是否加大投入。
比如做个小程序、app这些产品，前期投入1个产品经理、1-2个技术、1个测试、1个UI就应该足够了，而且UI通常是共享资源，测试前期其实也可以先不用。
随着产品用户规模上来了，产品功能也会逐步增加，数据量会越来越多，运营的需求也会越来越多，1-2个技术已经完全更不上增长速度，需要根据实际情况增加投入。
03需求版本决策
新产品
通常都会采用敏捷项目管理，将产品划分为几个重要里程，按目标分阶段快速上线。
这还取决于产品行业特性，如果是互联网产品通常采用MVP模式，一个最小可用版本就直接快速上线了，上线后在采用快速迭代的方式不断更新完善。
而针对一些合同项目、一些稍微大点的项目，需要3个月、半年、1年才能做完的这种，就需要将版本划分几个里程碑来分阶段上。
如何决策:
项目采用敏捷还是瀑布，一定是根据项目开始客户的要求或者基于客户期望来定的，现在一般项目和产品通常不会采用瀑布模式，当是比如手机、装修这种大工程，通常都是一次要搞定的。
做一个软件产品，不管什么行业来看，采用MVP通常都是最好的选择，先搞定一个最小可能性产品，先用起来，再来不断完善补充。
签合同的项目类型的阶段划分，通常会和业务关系比较大，按业务流程来划分，每次至少要保证一个完整流程能闭环，先把基础和业务流程搞完，然后再来搞一些扩展业务，像一些报表就是，大部分报表可以放后面几个阶段来做。
产品初版上线
会根据产品情况采用需求迭代管理，比如每个月、每2周，甚至每一周发布一次。一个持续运营产品的需求池会有大量需求，来自规划、用户反馈、细节问题、用户体验等，每个迭代版本都需要确定哪些需求先做，哪些需求放到下个版本。研发资源有限，都优先级高都想快速上是不可能的。
如何决策:
这是需求优先级的管理问题，可以通过需求评分表评分的模式来决策。
主要根据四个维度进行打分:
- 用户价值。根据需求给用户带来的实际作用和价值进行评判；价值越高分越高。
- 使用频率。高频的功能一定是核心功能；频率越高分越高。
- 简易性。需求的实现难度，越简单分值越高，如果实现起来耗时长、复杂性高，那么得分要低。
- 特殊性。客户或老板硬需求，具有一定临时性且重要，有特殊的应用场景。如果此项没有则可打0分。
每个维度10分，四项分别打分之后，再相加平均便得到一个想法的综合得分。
产品经理根据当前的产品目标和重点来做快速决策、会根据领导的期望来做安排。不过通常没有那么复杂，对需求的优先级情况，PM大致是心里有底的，直接就能拍板。
决策后还要和相关人员和部门协同版本迭代需求，达成共识。
04需求方案决策
画一个需求从方案到落地所需决策点的路径图:
需求方案决策涉及到的大部分都是很细节的决策，主要包括如下：
1、需求的实现方式，会涉及到功能灵活性、扩展性、研发工作量、体验、未来规划，会有很多的取舍判断。
同样的需求会有好几个实现方案、会有不同的用户路径，产品经理需要根据精品分析、实际用户的需求分析、业务场景分析来做决定。
还有需求的范围决策也是产品经理经常要做的一个判断，本次迭代的需求要做到什么程度，需要产品经理根据产品情况和紧急程度做出反应。
2、界面交互控件以及交互方式，比如页面控件选择、布局、跳转、文案提示等交互，很多时候其实这也行那也行，但是需要制定出一个交互标准，根据交互标准来定义，保持统一性。
交互标准也是需要细分到具体业务和场景，不然标准反而会限制交互的友好性。
3、UI的界面判定选择。产品经理对审美是有一定要求的，虽然不能说像UI设计师一样那么样专业，但是要以业务和用户的角度、整体的视角来审视UI的设计。对于UI的选择和判定，除了要提高自己的审美观外，还是需要多看，特别是多参考竞品。
4、需求评审时，研发会提出很多细节的处理方式，需要做出选择和决策。
有些需求如果完全按照你的原型设计来，工作量可能会很大，因为研发很多时候都会用一些标准控件来处理，包括数据的处理方式也都会影响到一些设计，研发也通常都会给出自己的想法和方案，这些时候都要产品经理综合来评估决定。
5、上线前的测试阶段，QA会发现很多奇怪的问题，还有一些优化问题，这些问题要不要全部解决完在发布，这些问题要不要解决，某个问题到底是不是BUG？
需求方案到落地上线，遇到的细节问题和选择是最多的。一些支撑决策依据：
- 多做一些竞品分析，参考竞品的处理方式。
- 查看用户反馈，可以在系统内置用户反馈功能，也可以做些调查问卷分析。
- 针对一些交互，可以使用AB测试的方式，让用户来做决策。
- 通过用户行为数据来做决策。
三个水蜜桃，都是我的，先吃哪个？
现在的我会先吃最大的最好吃的，然后吃一般的，最后吃最小的。
我的理由越来越简单: 因为水果放到后面通常都会因为时间问题，导致水果坏了、变软了、不新鲜，如果不第一时间把最好的吃掉，那么最好吃的可能就变成最不好吃的了，浪费了最美好的那部分。
最近在吃的荔枝也是，荔枝很多，你一次吃不了多少，放几天就不好吃了，所以必须先把最大最好的挑着吃掉。
以前我会先吃最小的，用会把最好的最大的留到最后再来吃，因为舍不得，总想把最好的放到最后来享受，这样的想法持续了很久。
这个简单的选择，其实我有领悟了一个道理，你在做事情、在展现自己、在创业的时候，你要先用尽全力去尝试，而不是刚开始就想着留着一份力在未来使用，因为这份力可能最后都用不上，反而会有遗憾。
还有人是一直在进步的，就和你写文章一样，你今天写的这篇是你当前写的最好的，那么你会更努力去学习去吸取知识，未来就会写的更好。
当然并不是所有事情都这样，比如“斗地主的时候，你总不能先出双王四个二吧”！
标签：需求,要素,经理,之三,决策,用户,产品,投入 From： https://www.cnblogs.com/R-bear/p/17985811