1.2 关于产品需求
1.2.1 真正的需求
幼儿园老师给小朋友布置了一个任务：带一条鱼来班里观察。小朋友告知了家长后，第二天上课，让人啼笑皆非的场景出现了（如图1-3所示）。面对老师的一个看似直白但其实需求非常模糊的任务需求，每个家长给出的反馈有时差别就是这么大。
图1-3 家长对幼儿园老师布置的任务的反馈
产品经理收到的需求很多，既然人们对于“带一条鱼来班里观察”的理解都能千差万别，更不用说产品经理在产品设计过程中要面对的各种纷繁复杂的需求了。在面对各种需求时，产品经理需要先解决一个问题：辨别需求的真伪。
先来看看伪需求是什么样子的？
我要美丽的衣裳。
这不是歌词，而是提需求的人常说的话。
另外，用户提出的需求常常是这样的：
现在的照片无法附加贴纸！一定要现拍才有用。
新版美颜相机的图片精修功能中，少了合照中的个人精修功能，精修时想单独将某个人五官精修下都不行，要全部人一起精修。
以上3个需求都是伪需求，也就是说，不是真正的需求，但它们又常在产品经理的需求登记表里出现。这些伪需求实际上是需求提出者想得到的解决方案，或者是用户遇到的操作问题，如表1-1所示。
表1-1 两类伪需求：解决方案与用户操作问题
常见的伪需求有两种：
解决方案和用户操作问题。
关于解决方案，就是需求提出人希望产品应该怎么做。
我要美丽的衣裳。
这个需求提出者不但提出了产品的解决方案——衣裳，还提出了对产品的体验需求：美丽。
类似的例子还有很多。
加入购物车太麻烦，我要可以直接购买商品。
我希望以后修照片的时候有美妆。
用户直接表达产品要怎么做难道不好吗？用户参与设计不正是产品经理想要的吗？问题是，用户既然都开始设计产品了，还要产品经理做什么？
当然关键并不在这里。提出需求的人提供的产品解决方案本身并没有问题，这是大部分需求提出者的表达方式，而且提出解决方案时的参与感会让他们更热衷于表达想法，应该鼓励。
但产品经理不能把用户提出的解决方案当需求来接受。如图1-4所示，实现需求的办法有很多，解决方案也不止一个，提出需求的人的解决方案只是其中一种。接受了这个解决方案就是接受了某个选择，同时舍弃了其他更多的可能性。
图1-4 多种实现需求的解决方案
产品经理把解决方案作为需求，就会停止挖掘需求，失去获得更准确需求的机会，对产品设计的影响更大。
用户操作问题是用户使用产品时出现的问题，这些问题和解决方案有关，是解决方案的漏洞导致的。
如果产品经理要跟踪产品bug，协助开发或者修复产品功能，那么用户提出的操作问题是极好的用户使用反馈和功能修改依据，但不是用户需求。
也就是说，如果产品经理要对用户提出的功能进行升级优化，设计新的、更优秀的产品，用户提出的操作问题无法作为需求帮助产品经理设计更优化的方案。
用户说修照片时没有美妆功能，在产品优化方案中增加这项功能，这难道不是优化方案吗？
用户提出的操作问题，从另一面看就是用户提出产品解决方案。
操作问题：现在的照片无法附加贴纸！一定要现拍才可用。
解决方案：不是现拍的时候照片也应该可以附加贴纸。
操作问题：新版美颜相机的图片精修功能中，少了合照中个人精修功能，精修时想单独将某个人五官精修下都不行，要全部人一起精修。
解决方案：增加合照中个人精修功能。
所以，用户提出操作问题与提出解决方案是相同的情况，不论是操作问题还是解决方案，如果把它们作为需求来对待将会限制产品设计。
所谓真正的需求，是指：
需求的需求，即：需求产生的理由。
真正的需求才是产品经理要花时间、精力洞察的用户期望。
参与过用户调研、用户访谈的产品经理通常会发现，用户说的经常并不是他们真正想的，用户再三强调重要的东西，在他们实际的行为中常常显得似乎并不重要。
作者曾经组织过一次用户活动——免费发放产品经理培训课程的学习资料。我们打包了一套产品经理培训课程的学习资料包，并通过各种渠道进行发放。申请资料包的同学只要回答几个简单的问题，如：申请学习资料是为了什么？打算多长时间看完资料包内容？回答完就可以免费领取学习资料包。其中申请资料为了“学习，提升自我”的回答占大多数。资料包发放一段时间后，我们对曾经申请了资料包的同学做了回访，回访内容也很简单：再次填写申请资料的目的和学习情况说明。
回访的反馈结果是，超过半数以上的同学没有看过学习资料。
所以即便是用户说出的需求，他们也未必会为之付诸行动，而是仅限于一个想法。根本无法激起用户行为的需求而形成的产品，最终很大可能会失败。
怎样洞察真正的需求？可以通过“5why分析法”——对用户的表面需求连问5个为什么，直到发现用户真正的需求。
当然5why分析法也不能生搬硬套，否则容易让需求提出者落入无限的死循环，与产品经理的交流过程恶化。
在询问用户的表面需求产生原因时，通常回答会形成因果链，如下所示。
问：申请资料为了什么？
答：学习，提升自己。
问：学习提升自己是想自我补充、帮助职业发展还是其他？
答：听说产品经理岗还可以，提前做个准备吧。
问：有想法做产品经理啊，现在的岗位遇到问题了吗？
答：觉得没发展，做到头了。
问：产品经理岗哪里吸引你？
答：听说发展空间比较广，待遇比较高。
注意
一旦没有新的回复内容产生，就不要再纠结需求理由的探究。
根据上述沟通内容可以形成如图1-5所示的因果链。
图1-5 5why分析法得出的因果链
通过因果链不难发现，申请产品资料的同学真正的需求如下。
学习的需求：学习提升准备做产品经理，获得更大的职业发展空间，在工作和待遇上有提升。
遇到的问题：现在的岗位发展空间小。
1.2.2 产品需求框架
几乎每一份产品经理的工作文档中都充斥着关于产品需求的内容。不但如此，在一些相对大型的企业，需求管理更是重要的产品工作。所谓产品工作，是指产品设计过程中需要完成的工作，但产品工作并不是全部由产品经理完成，如技术层的产品工作通常不是产品经理完成的。
产品设计时有三类需求：业务层需求、产品层需求、技术层需求，它们构成了产品需求框架，如图1-6所示。三类需求在设计过程里递进出现，即：业务推出产品，产品推出技术需求。
图1-6 产品工作中的需求框架图
（1）业务层需求
业务层需求是对产品涉及的用户、市场、运营等的需求确定业务范围，也就是确定产品要进入的行业、业务边界、干系人及业务目标。
由业务范围能够产生业务事件和业务流程。业务事件和用例将业务范围划分成业务小块，形成实现业务目标的业务流程。
（2）产品层需求
产品层需求是对产品解决方案的需求分析。是在业务层需求的基础之上形成的产品需求。
产品层需求中，第一类是针对整体产品解决方案提出的需求，包括产品范围、限制条件、技术需求；另外一类是产品实现业务事件时产生的产品需求，包括产品任务、功能需求、非功能需求。
实际工作中，后一种需求更加常见，也是产品经理完成需求文档、原型设计时必会遇到的需求。
（3）技术层需求
技术层需求的数据字典和系统组件，对大型、复杂的产品设计来说十分重要。产品经理应具备基本的开发技术。不过，并不是所有产品都需要产品经理完成技术层需求，更多的状况是产品经理主要专注于完成产品层需求的工作。
产品经理能够通过产品需求框架快速了解产品工作中的需求类型有哪些，同时在设计过程中也需要对需求框架产出相应的工作文档或需求内容。
并不是产品需求框架中的所有内容都必须在产品设计过程中有所体现，产品经理需要根据实际情况决定应完成的需求。
1.2.3 需求平衡=产品平衡
产品需求的来源很多，用户只是其中之一。产品部门、用户、技术部门都会向产品经理提出各种各样的需求。然而，每个人的角度不同，提出的需求就容易出现矛盾。产品经理不可避免地要对以上3个需求的主要来源产生的矛盾做出平衡。
在就业市场上，招聘人才的企业和应聘的学生有以下的需求。
用人单位需求：要招聘有工作经验的技能型人才。
学生的需求：想通过学习找好的企业，待遇高的岗位。
这两类需求催生了对接二者需求的、巨大的职业教育产品市场。但是用人企业往往对通过参加职业教育补足工作经验的学生心存疑虑。
一款职业教育产品如果无法充分证明学生的各方面素质足够过硬，无法被用人单位充分信任，那么对于这款产品来说就是死路一条。不会有参加职业培训的学生愿意接受无法达到个人目标的教育产品。但作为一款职教产品的产品经理，面对“友商”在就业辅导中帮助同学过度美化简历的手段，在宣传时打出的高薪就业的虚假宣传，你该怎么办？
通过建立技术壁垒支撑产品高度，可以使产品更具竞争力。但对于中、小企业来说，充足的技术储备几乎不可能，除非有类似情况：
企业核心人物有技术专长；企业背后有金主，可以不考虑生存问题。
但产品的技术需求往往意味着产品企业的高风险投入。
一个做车库管理的软件产品，市场占有率良好，一直处于稳定发展的阶段。这时，产品经理发现：在不少高档消费场所出现了一种能够对汽车出入库智能识别的产品。
这是不是行业产品的新发展？自己的车库管理产品，是否要向这个方向发展？
作为产品经理一定会思考上述问题。自身不变也许就意味着产品逐渐被取代走向终结；做出改变也并不轻松，因为面临着技术投入带来的风险，以及方向趋势判断失误带来的转型风险。
无论是职教产品的产品经理，还是车库管理产品的产品经理，都需要在用户、产品、技术中的一方面或者几方面做出平衡。