需求的重要性续集

这里是IT修真院产品分享课，今天要分享的是

【需求的重要性续集】

1、需求提出方是谁？

• 产品？
• 运营？
• 推广？
• 技术？
• 老板？

不少时候需求的提出方可能并非咱们本身，是由他人提出的。记录需求的提出方是谁有助于咱们从新梳理当时的决策过程，若是提出的是失败需求，就算不是咱们本身。

那么也应当思考：为何本身没有阻拦此次需求，反而是让失败的需求顺利的上了线？当时若是提出了质疑，为何咱们没有继续说服别人？若是是咱们本身提出的，就更应当反思了，当时在作出决策的时候是哪一个方面的缘由使咱们产生了误判？这种误判是本身的思惟习惯仍是思惟漏洞？

这些都是值得咱们深入反思的。

全部的需求都必须有明确的需求依据，缺少明确依据的需求一律拒收。

2、需求的依据是什么？

• 数据分析的结果？
• 用户调研的结果？
• 竞品分析的结果？
• 我的的经验判断？

从上面四个依据中，不难发现：数据分析的依据是最难的，须要对需求的详细分解和推断以后才能给出结论，而且产品上线后也须要持续的观察数据的变化，以判断产品的改动是否符合预期。

用户调研每每也须要耗费必定的时间和精力，须要搜集必定量的用户数据后通过分析才能得出一些初步的结论。而竞品分析相对不是很靠谱，在不少人理解起来就是竞争对手作撒，咱们跟着作就行了。而我的经验是最简单的，也是最不靠谱的，全凭我的的感受和判断，也就是纯粹的我的YY。

失败的需求大多有个特色：有着极强的我的主观经验判断，而缺少严谨的数据分析和用户调研。大多时候是由什么内部的“决策层头脑风暴”以后提出的，严重缺少数据的依据和用户的反馈。

3、需求的类型是什么（KANO模型）？

• 基本需求？

• 指望需求？

• 兴奋需求？

明确产品的发展阶段很重要！清晰本身这个阶段什么能作、什么不能作很重要！

咱们都知道产品是有生命周期的，不一样阶段产品的侧重点也是不同的。咱们也都有这样的经历：在作产品的时候忽然的灵光一现，想出一个极好的创意，兴奋的不行。

可是若是把这个创意放在KANO模型中思考一番后，咱们发现产品当前还处于需求验证阶段，最核心的任务是验证需求的真伪，而本身想出来的不少创意每每只是一种兴奋需求——有了更好，没有也影响不大。

用KANO模型进行分析的主要目的是——让团队可以更加的聚焦：将产品的重点放在核心的需求上，而非过于发散的提出一些所谓的“奇思妙想”，虽然这些奇思妙想在某些时候的确很重要，可是大多数时候，咱们仍是要着眼于产品当前阶段的核心任务，脚踏实地。

4、需求的影响范围？

• 个别用户
• 新手用户
• 轻度用户
• 重度用户
• 所有用户

咱们在之后提出需求的时候，更加谨慎、思考的更加全面，影响范围较大的时候，咱们更多应当采用AB测试的方式，或者先上马甲包，等数据稳定后再作判断。

好比：当时我在正式包上直接上线了一个“付费功能”后，致使新用户的注册转化率受到不小影响，进而影响到了产品在App Store的排名，这些都是被我事前低估的，好在我预先准备了备选方案，在出现问题后第一时间更换为了备选方案。

5、评估的过程是怎么样的？

• 是否通过了充分讨论？
• 当时的团队总体意见是一致的吗？
• 是否对风险进行了充分的预判？
• 当时团队的决策是正确的仍是错的？
• 为何团队会作出错误的决策？

作产品时间长了以后，我观察出来一个现象：团队的决策不少时候不必定比我的决策更明智，团队的决策反而会提高失败的几率。

背后的缘由大概有两个方面：

一、团队决策的时候责任是分散的，因此会必定程度上为了追求团队和谐而致使中庸意见占据上风；

二、由于不少问题须要的不是集思广益，而是极其深度的思考，因为团队将责任分散了，因此在思考的深度上不必定比一我的强。

评估的过程，其实就是加深咱们对团队的认知和理解——团队总体的氛围是怎样的？团队成员是否都有表达观点的机会？团队的意见是否会被个别人左右？团队的决策是更明智的仍是更中庸的？等等。

“评估过程”以后，你会发现：每次产品的需求讨论会议，都常常被决策层的个别人员所左右，致使其余部门的人难以有太多表达意见的机会，此次我索性直接将需求讨论会议进行了拆分。

和决策层进行战略讨论会议，和执行层进行需求评审会议——这是很是奇葩、很是有公司特点的，可是效果却出人意外的好！不少日常基本上不说话的开发小哥哥，在这种调整以后也有了表达意见的机会。

6、是否遵循了MVP原则？

作产品的人都知道，在产品发展的初期，交互和设计对产品自己的影响是比很小的。从“用户体验要素”的层面讲，设计和交互都属于产品表现层的东西，影响也是有限的。

可是由于设计和交互是千人千面的，人人都能说上几句的，因此才被那些“不懂行的人”给予了太多的关注。复盘和检讨咱们是否遵循了MVP原则，有利于团队将整个注意力和重点，放在核心需求的验证上，而非千人千面的设计和交互上。

这其实也是对团队成员在知识层面进行不断降维打击的作法——不少人都认为本身特懂产品，拥有最好的想法。这个时候咱们要作的不是和对方争吵，而是用数据和结果去证实对方为何是错的，错在哪里。

同时，在咱们须要在知识层面上持续的输出，提高整个团队的产品认知——这也是产品经理为何要持续学习的缘由，要对他人进行降维打击，就必须保证本身的思考和认知可以持续性的引领团队。

7、实际的结果如何？

• 正向影响：产品数据获得提高、用户体验提高……
• 负向影响：产品数据下滑、用户体验变差……
• 中性影响：短时间数据并未有明显变化、但长远可能提高……
• 其余

对结果进行分析有助于整个团队可以更加的以结果为导向，在大部分的创业公司，你们都是狂奔的状态，不分昼夜的提需求、赶进度、争分夺秒，可是勤奋、忙碌与成功之间并不必定是成正比的，不然创业就成了太简单的事情。

冷静下来从结果的角度进行分析，有助于咱们反思本身所作的事情中哪些有重要的、积极的、有价值的？哪些是没必要要的、消极的、价值较低的？本身如何将时间与精力聚焦在核心的，有价值的事情上？

从而在之后的产品迭代中，尽量的作出最正确的决策。

咱们常犯的错误之一就是：误把假设当结果——认为事情的发展就应该符合咱们的构想和预期。可是结果会告诉咱们：你的假设只是你的假设，你的构想也只是你的构想。对结果进行跟踪、反馈和反思，是逼迫团队更加务实。

【更多内容，欢迎加入交流群565763832与你们一块儿讨论交流】

【这里是技能树·IT修真院：IT修真院官网，初学者转行到互联网的汇集地】