产品需求的来源大致可以分为4个维度：
人员反馈包含, 老板或者领导提出的一般是公司战略规划或者业务发展要求, 业务方也就是公司内部人员涵盖运营、财务等方面, 客服所反馈数据, 用户反馈情况, 自己进行的规划数据分析, 即产品功能的具体使用情况通常是产品后台数据、第三方埋点数据, 调研反馈有市场调研、用户调研以及公司内部业务方调研, 竞品分析是经由直接或间接竞品的产品功能对比, 或者与竞品公司在市场上的优劣势进行对比等, 02你是怎么评定产品需求优先级的?
被较为频繁使用的工具有马斯洛模型、Kano模型、四象限法、二八原则等等, 挑选契合自身状况的才是最为适宜的。然而运用这些工具的前提条件, 仍旧是要借助不同维度予以融合剖析, 我通常会从三个维度去展开剖析, 研发以及运营所需成本、影响面（涵盖影响程度以及影响范围）、给公司所带来的收益（鉴于笔者从事有关后台产品的工作, 对于用户体验的要求没那么高, 若你所从事的是C端产品, 可将用户体验这一维度增添进去）。
比如说, 有这样两种情况, 一种是影响一万人的功能, 其平均每天被使用一次, 另一种是影响一千人的功能, 它平均每天被使用一千次, 然而投入的研发成本却是相同的，那么必然是优先去解决影响范围更大的那种需求。
03 如何辨别需求的真伪？
想必大家对《更快的马与福特汽车》以及《用户与音箱》这两个经典案例都是十分熟悉, 实际上最关键的是你得往深层次去挖掘用户的需求, 要知道有时用户所讲的并非是其真正想要的。
范本示例
首先, 我会明确需求的来源, 究竟是公司业务方的专员? 还是业务方的领导? 是外围用户? 还是专家用户? 是一两个用户? 还是大部分用户呢（二八原则）? 比如说, 业务方的专员, 他对于业务的理解程度, 肯定比不上他的领导, 因为所站的高度不一样, 所以需求的价值也会有所不同。
每一回接收到一个需求之际, 我起码会一步接着一步地多去追问几个为何, 再添加上多方面予以了解, 在持续刨根问底之时, 偶尔也会有意外的发觉。
04 如何将用户需求转化为产品方案的？
这个问题, 与上个问题存在一定类似之处, 是用户基于某种场景提出的需求, 或许其考虑得并不周全, 在此种情形下, 就需要你来进行深层次地挖掘以及分析。
传给大伙更具层次的办法, 面试官会即刻觉得你更有影响力——。
“HWM分析法”的意思是“How might we”即“我们可以怎样”, 大部分人面对问题的解决思路是直接给出解决方案, 这种方法能有效帮助我们打开思维定式而非局限于具体解决方案里, 它的核心重点在于 “我们”、“可以”、“怎么样”, 要先在最大范围搜集产品的所有可能性, 接着抽象出这些想法背后隐藏的核心概念和产品需求, 随后整理出具象化的产品设计方案, 最终形成可视化的PRD。
大致流程如下：
于产品创新而言, 此方法有着极大帮助, 然而, 该方法所需经历长时间练习, 方可逐步培养这方面能力, 若长久坚持下去, 你的思路会象山洪爆发一般, 汹涌澎湃, 根本无法阻挡。
05 你是如何做产品版本规划的？
面试官所思欲知者, 乃汝之情状, 即汝有无产品规划之能力, 又或汝曾否于更高之视角, 琢磨思索过未来产品之规划。
范本示例
我会时不时地针对产品当下状况予以梳理、予以总结, 弄明白产品上线之后的成效以及后续该朝着怎样的方向前行。
就月度数据分析而言, 是针对产品线上的数据情形予以分析并总结, 且凭借这些数据去规划后续要开展的事项；对于需求汇总分析来讲, 是依据当下所收集到的需求实施分类梳理、优先级排列, 进而规划后续几个版本所要做的事情。06项目延期问题是如何得以解决的? 怎样去避免项目出现延期情况呢?
此项问题着重考查你那沟通之中进行协调的能力, 还有项目予以推动的能力, 能够从三个层面予以着手, 其一为知晓当下状况, 其二为什么去解决, 其三是后续怎样去规避。
1. 了解现状
刚开始的时候, 得清楚明白当下是什么样的状况, 究竟是致使延期的缘由造成, 和原本计划的上线日子差了多少, 是技术层面遇上了困难, 还是开发评估的时间跑偏了, 又或者是别的因素。唯有把状况了解透彻, 才会有相应的解决办法。
2. 如何解决
其次, 依据问题去制定与之对应的解决方案, 要是针对技术方面遭遇了难点这种情况, 能不能协调资源来达成, 又或者在功能层面想出一个折中的方案, 这个方案不仅仅可以满足业务需求, 技术层面也能够得以实现。
对于开发评估出现的时间偏差情况, 能否适当加班去完成呢（毕竟当初开发同学自行承诺了时间, 得为自身承诺承担责任）, 接着查看与原定上线日期的差距有多少, 能不能相应地削减非核心功能部件, 以此保证能够按时上线呢。当解决方案确定好之后, 要在第一时间去通知业务方以及干系人, 保证他们能获取到第一手消息, 让干系人有心理方面的准备。
3. 后期规避
最终便是后期怎样去规避的相关问题了, 方案存在着许多, 比如说在需求评审之际将需求予以细化进而确保每一个人都能够充分理解。
我在此推荐一种办法, 需求评审结束之后, 当开发人员进行时间评估时, 能够采用“估算扑克”（敏捷开发里边的一种办法）的方式, 此办法在刚开始运用之际, 兴许和预计的时间存在较大偏差, 不过熟练使用之后, 就会发觉屡试不爽。
在项目开展进程里, 有没有发生需求变更情形, 针对于此你做了些什么, 在此过程中你又是怎么做的?
候选人解决问题的能力以及应变能力, 是此问题着重考察的点需求变更在产品迭代进程里是常见状况, 业务方会临时增添需求, 老板会提出当前版本必须纳入的需求, 还有可能因需求评审时考虑不周全, 致使与原本需求存在偏差，进而不得不进行需求变更。
在这里笔者只能为你提供一个解决问题的思路：
必须得先弄明白当前的状况, 究竟为啥会发生变更? 究竟是被哪些因素给致使的? 变更会造成多大的影响? 保持不变能否行得通? 要是不进行变更, 能不能搁置到下一个版本去做迭代? 要是实施变更之后, 当下这个版本会不会出现延迟的情形? （项目延期的话请参照问题5）。
还要给大伙提供一种我的做法, 我们团队里搞研发的同学, 在对任务进行估时之际, 会留出大概 1 天的时间, 用以应对往后可能出现的突发状况, 要是没有突发状况, 就会在提前的情况下进入到下个版本的迭代任务当中。
对于跨部门沟通协作, 你是怎样做的? 要召集高质量的、涉及不同部门的会议, 至少得提前 1 天告知参会人员会议主要讨论的内容, 还有会议的时间以及地点。要提早安排好时间, 防止出现时间冲突。在会议主导的过程中, 得避免讨论问题出现跑偏的情况, 要明确每个事项的责任人以及时间, 以此来避免后续出现扯皮、互相甩锅的现象。形成会议纪要后, 通过邮件发送给每个参与人, 也可以抄送相关领导。最后就是进行里程碑跟踪, 避免出现脱轨的状况, 要是出现问题, 要及时进行沟通并解决。
笔者所能为你提供的, 只是所有面试问题及答案的一个思路, 更多的, 是要依靠你自身的经验以及应变能力, 祝你面试顺利。
