产品经理打架引发的问题：如何识别需求及其价值

Posted 2022-11-28 zhangmike

[作者按：平安产品经理与研发工程师打架的小视频在IT圈刷屏了，笔者不能免俗，参与讨论了，自以为讨论中有不少干货]
趁着产品经理最新的段子，来聊聊产品经理如何识别需求并恰当表达？

一、背景假设-线上产品及其特征

背景假设是已经在线上运行的产品或者产品群，有一定的访问量。
无论是主动调研还是被动响应，需求的来源必然是多方的。
有如下特征：

• 1，碎片化
• 2，涌现式，不可预知
• 3，易变
• 4，时效敏感

变色这个需求对比整个产品或者应用，应当就是个碎片需求，或者叫需求碎片。
跟原有的需求，也许有联系，也许没联系，就算有联系也不会那么明确和紧密。
平安这次提出的随手机壳变背景颜色的这个需求，也是一个典型的涌现式需求。
猜不到谁在什么时候会提出来？ 它在今年炎热的夏天突然就冒出来了。
需求易变是显然的。出了这么一档子事，平安产品经理侧不知道还会不会坚持这个需求？
说不定如视频当中搞笑的要做成随内裤颜色变，
这个太不靠谱了，那也许是可以随外衣颜色变。
根据手机壳变主题颜色，类似这样的在手机应用上需求，如果要搞五个月搞出来，那就是生意还不够好，不仅仅不够好，简直就快死掉了。
因此需求时效性是值得追求的，互联网活动季节比如618，双11等等，都是强时效。
经典的故事地图方法，看起来很美，可以组织计划多个迭代，
其实是不能够应对以上特征的需求流。
或者说如果能够应对，那说明生意还不足够好；足够好的生意，大量涌现的各方诉求可以把故事地图冲击得歪七歪八。

二、需求流模式

在处理具体到单个需求，目前在需求条件方面，仍然是SMART用得多。
但是SMART并不是一步到位的。
从模糊创意到符合SMART的需求，有一个过程。最新有些理论流派给出了“持续探索”的说法，比如SAFe。
也有product discovery和product development，双轨Scrum的说法
我在最近几年的实践中，更加喜欢把它称之为需求流模式。
所谓需求流模式，需求如同小船一样放到泉水里面流淌。

1. 从开始模糊的创意，
2. 到确定启动的需求，
3. 到需求初稿
4. 到等待IT排期
5. 最后到上线

对于单个需求而言，以上的过程跟经典的瀑布式生命周期模型几乎一样。
不同的地方在于，同时并行许多需求。
就像泉水里面有很多船，有的在前，有的在后，有的在加速，有的抛锚了。

三、从创意到需求

回到平安那个事情，貌似那根据机壳改变主题色调的需求来自于一个拍脑袋创意，
那凭什么这样的一个拍脑袋的创意能够传递到开发人员？
拍脑袋的创意要做到什么份上，可以往下流转，可以避免打架？[呲牙][呲牙]
先来为回顾一下经典的做法-BRD, MRD，PRD（引自 https://www.jianshu.com/p/607c3ac65887 ）
PRD
一、PRD的含义 英文简称，PRD（Product Requirement Document），PRD文档中文意思是：产品需求文档。 PRD文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。
MRD
二、MRD的含义MRD，英文全称Market Requirement Document，中文意思是：市场需求文档。 该文档在产品项目中是一个“承上启下”的作用，“向上”是对不断积累的市场数据的一种整合和记录，“向下”是对后续工作的方向说明和工作指导。 作用是：产品项目由“准备”阶段进入到“实施”阶段的第一文档，其作用就是“对年度产品中规划的某个产品进行市场层面的说明”，这个文档的质量好坏直接影响到产品项目的开展，并直接影响到公司产品战略意图的实现。
BRD
三、BRD的含义 BRD，英文全称为：Business Requirement Document；中文意思是：商业需求描述。 基于商业目标或价值所描述的产品需求内容文档（报告），其核心的用途就是用于产品在投入研发之前，由企业高层作为决策评估的重要依据。BRD是产品生命周期中最早的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是供决策层们讨论的演示文档，一般比较短小精炼，没有产品细节。
PRD、MRD、BRD之间的关系
1、PRD要把MRD中的“产品需求”的内容独立出来加以详细的说明，而产品需求本身是在MRD中有所体现的。
2、MRD侧重的是对产品所在市场、客户（client）、购买者（buyer）、用户（user）以及市场需求进行定义，并通过原型的形式加以形象化。
3、如果说PRD的好坏，直接决定了项目的质量水平；那么BRD的作用，就是决定了你的项目的商业价值。 BRD、MRD和PRD一起被认为是从市场到产品需要建立的文档规范。
当前如何处理需求载体？
在当今快速变化的市场环境下，如果还要三份文档的话，恐怕早就被竞争对手远远甩在身后了
写三份文档会太慢，
不写文档，直接去找it，恐怕要打架。
这如何是好，如何平衡？
从业界的情况而言，首先减少的是MRD
现在已经有很多公司不再写MRD，最大的原因，因为它是一份夹在中间的文档，无论是BRD向后延伸，还是PRD向前覆盖， 都比较容易把它给替代掉。
因此当前在需求识别时，常用二级信息识别，先识别创意，然后到具体需求。
常见创意的载体是BRD或者简化BRD，或者直接就叫创意，或者原始需求，或者意向。
具体需求的载体常见沿用PRD的说法，也有沿用需求说明书的说法。
如何判断创意？
创意的产生一般是不受限制的，鼓励产品经理们打开脑洞，但显然的，从创意到具体需求是要讲究的，否则可能出现打架。
创意有多大市场价值？
首先考虑是这个创意有多大市场价值？
从一个拍脑袋创意，要转换到一个需求，首先回答的就是多大市场价值？
自动根据机壳色彩改变主题色彩，显然有一个替代方案，是手动。
那么手动变化主题色彩的功能是不是已经有了？
如果有了的话，有没有数据监控运行了多少次？
比例如何？什么样的客户群体在用？
如果没有的话，那是不是先上一个手动改变主题色调的功能？
从方法论上，首先寻找最小可行产品，根据实际数据反馈，再来决定下一步。
简单而言，如果手动改变色调，这样的功能上去了之后，都没几个人用。
那也许没必要搞自动改变。
难以判断的市场价值
虽然说是首先应该想到市场价值，但在目前这样的一个快速发展的市场上，不少需求，不少创意，其实是很难评价市场价值的。
所谓无心插柳柳成荫，有意栽花花不发。
这样的例子比比皆是。
这也就是乌卡时代的一个特色。 简单而言，充满了不确定性。在不确定性的大背景下来，考虑当前的需求处理，就值得引入概率思维。也就说不假设做某个需求，绝对能够获得巨大的成功；而试图提高每个需求的成功概率，积少成多，从量变来引发质变。
回到BRD的撰写上面来说，在激烈竞争的市场环境下，花10天写一份BRD，会比花30分钟写的BRD更加精准吗？
答案真的是不一定。
拜访现场客户走断腿，
购买各类市场研究分析报告，花很多钱，
自己收集采集数据，花很多时间做研究分析
所以现在有一个性价比更高的方法得到了大量的应用，
那就是基于自己产品运行的数据采集。
有些公司做到了实时监控，有些公司做到了隔天出报表。所以现在产品经理的一个工作情景是这样的：
看着前一阵子的数据表现，包括昨天的情况，
拍自己的脑门，还有什么招？可以提升关键的各项指标？
蛮拼的产品经理
根据手机壳搞个自动换色，是不是能够吸引那些对主题敏感的潮人？ 那些新新人类喜欢什么呢？这个需求实现了也许可以提升百分之一的访问量[疑问]
拜求幸运女神眷顾我
为了这百分之一，我不惜跟开发干一架[奋斗][奋斗]
作为产品经理也是很拼的呀[可怜]

小结

以上整理了微信群里面的发言，回望上文发现还是蛮有条理的。
乌卡时代，为奋战在一线的产品经理喝彩！ 指数式增长的基础来自于每个1%的努力！