大家好,现将我过往工作中的在产品层面的一些方法论和实证经验整理分享给大家,方便产品同仁交流学习。

本篇是同产品同学分享我自己在需求提取、需求翻译、需求管理、需求设计、需求驱动、需求交付方面的一些实践经验,希望通过此篇文章帮助初中级产品从业者优雅的驾驭需求,进而做到从容应对杂乱无章的无序需求,对上游需方兄弟做到强有力的专家支持,对下游研发兄弟做到专业有序的统筹调度。

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

功能矩阵的设计策略及实战case

功能矩阵是站在产品各一级功能视角或具体的业务场景视角去思考、设计我们产品的演进计划,某种意义上讲功能矩阵是另一个角度的Roadmap,但与Roadmap有明显的区别。

区别一:功能矩阵更偏“矩阵”、更弱“时间”;区别二:功能矩阵相比Roadmap,我们更习惯用“优先级”、“状态”来表述,而Roadmap里的优先级基本一样,只是时间窗口的设置问题。

换句话说,功能矩阵是产品经理通过“自下而上”的内生动力,以暗线方式推动产品迭代演进。Roadmap是产品经理通过“自上而下”的外在框架指导,以明线方式推动产品迭代演进。Roadmap体现的是公司的战略意图,功能矩阵提现的是产品经理对产品的深度思考和排兵布阵。

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

需求池:采集、梳理、更新策略及实战case

产品经理打交道最多的就是需求,面对来自各方杂乱无章的需求,我们需要进行统一管理。基于分层组织架构,实践中我认为比较好的采用AB结构。

A类需求池原则上是产品总监或一级产品负责人维护,A类需求池需要向产品内部进行实时同步、随时查阅、协同编辑,共同维护,作为团队的“公有资源”使用。实务中,产品总监或一级产品负责人需要每周、每月、每季度与产品组同事内部集体Review——指导产品团队持续的完善需求、聚类整理需求、有序解决需求。如有必要还需与业务领导一起讨论技术开发是否有必要或者启动优先级及时间窗口设定。

B类需求池原则上是所有产品经理对自己负责模块的维护。大家会问,这两个是否重,是否存在需求不一致呢?

答案是“一定会”,但是,并非简单意义上的“重复”,我们姑且可以把B类需求池作为自己的账本,自己的账本应该和大账本保持同步,但是自己的账本的侧重点是更敏捷、更系统、更细腻——方便自己心中有本账。

无论是A类需求还是B类需求,都遵循“实时记录”、“及时整理”、“定期复盘”、“干系人共识”、“状态更新”。

无论是A类需求还是B类需求,在信息处理时,都应该有如下几个必备字段:“提出人”、“问题描述”、“问题归属”、“问题性质”、“优先级”、“版本规划”、“状态”、“责任人”。不同团队,不同个人习惯可以略有不同,示例如下:

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

三个版本的Featulist

基于上述Roadmap的“明线指导”和产品功能矩阵规划的“暗线指导”,结合上述需求池的原始线索,我们需要梳理出下个版本要解决的问题,并基于可投入的研发资源及时间窗口设置下个版本的Featurelist。

相对产品功能矩阵表,Featurelist的粒度要更细。具体哪些需求可进入Featurelist,可以同大家分享我的一些实务经验:

如果是运营类需求,Featurelist包含两个维度:运营面上的功能需求点+产品内部相关联动点;如果是产品类需求,Featurelist包含两个维度:主功能点占比80%+用户体验(含bug修复)优化点:占比20%。

为了将产品经理从需求应付中解放出来,发挥我们的产品owner原始价值,我的操盘经验一般是采用三段式,也即研发一版、设计一版、规划一版。

研发一版:当前研发团队正在进行的,产品的时间投入基本分布在如下几个场景:文档动态更新、研发动态支持、项目进度动态跟进、测试验收、上线培训等工作,这些场景的特点是:琐碎、紧急。

设计一版:是我们提前对已共识要干的下个小Roadmap进行拆分设计,也是研发前期产品拥有最宝贵的静态时间窗口期。

这个场景的特点是:产品内部方案论证、产品内部评审、需求方二次确认、必要的前置视觉启动等。设计一版也是最考验产品经理能力的,出色的产品经理可以很好的做好时间窗口把握,帮公司和团队节省巨大的人力资源(不是产品经理自己,而是整个下游团队的静态等待时间)。

规划一版:更多是提前思考下下个版本应该做哪些、相对大Roadmap我们进度有哪些偏差、是否有最新的需求或市场变化需要考虑进来,带有较大的不确定性。

除此之外,出色的产品经理还要做到如下两件事:通过提前思考来逆向指导“设计一版”的逻辑扩展性和方案策略的合理性,二一个是与业务体系进行论证、明确哪个部门的优先级高,哪个需求优先级高,并向外部提前一个月同步一个月后的预定攻击目标和预期交付成果,进而避免业务追着产品问,我的XX需求啥时候做?我的XX需求啥进度了?你们下一步打算做什么?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

业务链路的设计策略及实战case

产品经理千万不能接到需求上来就画原型,钻入细节,而是先调研业务、静下心来思考人,然后用手(或工具)画出业务链路图。画完业务链路图后再自行推敲是否合理,正向的、逆向的、约束条件、分支条件等是否都考虑到了,业务链路是否有遗漏、业务链路能否再简化,现有功能如何自然演进(如需)。

上述基础工作做完之后,再结合前述的功能矩阵图(如excel、如脑图)二次推敲、调整。

二次推敲完之后,再与业务方、干系人讨论、看下是否有遗漏,如无遗漏方可开展原型撰写。这里有个坑,业务方并非只是领导,还要邀请实际使用者参与讨论,避免我们闭门造车或遗漏业务中的特殊规则等。

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品架构设计策略及实战case

产品架构是产品经理站在公司的业务、资源和时间三个维度,统筹考虑当前产品的业务架构、技术架构、研发平台(客户端还是小程序还是都干)、先做哪些功能?再做哪些功能?各个功能模块之间的耦合解构关系、不同的研发小组分别并行或串行做哪些功能,最后有序会师等。

一方面考验产品经理的过往大项目经验沉淀能力;一方面考验产品经理的业务理解深度;一方面考验产品经理敢下功夫投入的系统思考的逻辑严谨性和前瞻预见性;一方面考验产品经理的权衡决策能力;最后一个是考验产品经理的落地执行能力。

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

产品从业干货-基础技能篇:如何优雅的驾驭需求?

以上是自己在产品中的一些实践总结,限于文采拙劣和时间有限,未能精细呈现,海涵。文中所述观点不当的,希望广大产品同仁不吝拍砖,共同提高。

不同的产品团队、不同的岗位角色,会导致我们的分工不同,以上很多场景可能不涉足或不主控,但万变不离其宗,方法相同,只要我们有产品盘感、业务敏感、逻辑严谨、灵通好学、干练带风、狠下功夫,放到哪我们都一样熠熠生辉。

产品之路很艰辛,也更能锻炼人!在此祝广大产品兄弟姐妹们不辱“产品”之title,做出好产品!

作者:九天牧人,个人微信unifarm

本文由 @九天牧人 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议




阻力设计在产品中的应用

阻力设计在产品中的应用

阻力是指物体在流体中相对运动所产生与运动方向相反的力,不仅在自然间中常见,在互联网中也广泛存在。本文作者从五个角度,深入分析阻力设计在产品中的应用,希望对你...

2020-06-18
如何成为一个合格的数据架构师?

如何成为一个合格的数据架构师?

数据架构师在互联网行业中是个很重要的职位,是企业数据资产最重要的“奠基者”。那么,如何成为一个合格的数据架构师呢?本文作者基于自身经历,从三个方面展开介绍,推...

2020-06-18
倒推“抖音短视频”APP产品需求文档

倒推“抖音短视频”APP产品需求文档

文章是倒推“抖音短视频”APP产品需求文档,但由于作者是第一次写需求文档,所以仅对核心需求进行了需求分析与说明。一起来看看~ 目录: 一、文档综述 1.1文档属性 1.2产...

2020-06-18
微信“拍一拍”,真的是一个没什么用的功能吗?

微信“拍一拍”,真的是一个没什么用的功能吗?

昨天微信上线了“拍一拍”功能,用户点击2次头像,会产生头像抖动,震动反馈,且在聊天框中显示“XX拍了拍XX”。 这个功能推出后,很多微信群都在疯狂拍一拍,引起了一波拍...

2020-06-18
数据大屏设计师,我不信你没有这些困惑(上)

数据大屏设计师,我不信你没有这些困惑(上)

从事互联网行业的人,每天都在接收新知识,时常也会有迷惑的时候,尤其是数据大屏这样比较少有人踏足的领域。本文作者以自身经历出发,对数据大屏设计提出了自己的一点...

2020-06-18
客户关系管理的15个模型总结(下)

客户关系管理的15个模型总结(下)

对于ToB产品,仅仅基于用户需求来设计产品架构是远远不够的。B端产品服务的是有着几年,甚至几十年管理积淀的企业,必须依靠一定的理论知识来支撑系统的设计规划。本文...

2020-06-18
B端产品设计:价值主张与需求对应的价值

B端产品设计:价值主张与需求对应的价值

B端产品的需求来源于场景,产品经理通过满足客户需求从而产生价值。因此,SaaS产品经理面对扑面而来的需求时,应当更清晰理解并评判需求的价值。 01 2008年,著名商业...

2020-06-18
以知乎为例,探讨未来产品设计的几大变化

以知乎为例,探讨未来产品设计的几大变化

知乎作为一个典型的问答社区,它本身反映了内容社区产品的很多典型问题。本文以知乎为例,探讨社区类产品未来发展的一些变化,对内容社区感兴趣的童鞋不要错过。 前段...

2020-06-18
如何用产品思维打造线上课程?

如何用产品思维打造线上课程?

如何用产品思维来给自己打造一个线上课程呢?本文从市场调研、课程开发、运营推广、成交这几个方面分享如何打造自己的课程,希望对大家有所帮助~ “地摊经济”重出江湖,...

2020-06-18
「武侠连载」营销中心设计——优惠券

「武侠连载」营销中心设计——优惠券

优惠券是常见的一种营销推广的方式,但是你真的了解它吗?本文作者以武侠故事的形式,对优惠券展开了生动的分析,对优惠券感兴趣的童鞋不要错过哦。 (武侠情节接上文“...

2020-06-18
金融支付财务融合业务-实践分享1:订单、账单、交易流水、账套知识解构、原理解析

金融支付财务融合业务-实践分享1:订单、账单、交易流水、账套知识解构、原理解析

本文作者从实际工作实践出发,结合案例等分享了电商金融支付财务融合中的基本概念和相关原理解析,包括:订单、账单、交易流水和账知识解构,供大家一同参考和学习。 ...

2020-06-18
关于卡片设计的分析与思考

关于卡片设计的分析与思考

卡片是APP常见的设计形式,它既有好处也有弊端,因此需要根据场景和内容确定展现形式。本文从四个方面对卡片设计展开分析,推荐给对卡片设计感兴趣的童鞋阅读。 卡片是...

2020-06-17
内容型产品中,付费会员功能如何设计?

内容型产品中,付费会员功能如何设计?

付费会员制度让用户预付会员费,将钱留在平台,那么未来一定会有消费行为,那么会员制度要如何设计,才能激励用户付费呢? 01 为什么要做付费会员? 讨论这个问题之前...

2020-06-16
文字社区是否可以拥有弹幕?

文字社区是否可以拥有弹幕?

从社区产品的角度来思考,弹幕功能对于内容生产方,内容消费方以及平台方而言各自有什么意义?图文内容社区是否有机会拥有弹幕呢?如果可以发弹幕,用怎样的形式呢?本...

2020-06-16
FMS财务系统收支结算总结

FMS财务系统收支结算总结

本文按照FMS收支结算划分,结算流程分类及各系统交互,财务系统内部结算基础能力,收支结算整体结构的顺序来依次介绍,总结财务系统收支结算的结构,和一些作者的个人思...

2020-06-16
如何迅速提升用户好评?试试这三种方法

如何迅速提升用户好评?试试这三种方法

小编推荐:如何提高一个产品的用户评分,改变大家对这个产品的印象呢?本文作者给大家介绍了三个概念:用户体验地图、峰终定律和服务蓝图,并详细解释了该如何使用这三...

2020-06-16
对工具型产品易学习与易使用的思考

对工具型产品易学习与易使用的思考

小编推荐:易学习是指怎么让新用户的学习成本降低,能够很快地掌握产品的使用,它的前提是足够简单和容易理解。而易使用是指,如何让用户快速、高效地完成一项任务,达...

2020-06-16
比对象还懂你!推荐算法为啥这么准?

比对象还懂你!推荐算法为啥这么准?

信息过度和广告过多的社会中,推荐算法的使用也就显得理所当然,但是它是如何做到了解用户的呢?本文从用户画像的定义和设计出发,结合实际案例,深入浅出地阐述了基于...

2020-06-15
B端平台产品需要培养的4种意识

B端平台产品需要培养的4种意识

对于许多刚入行不久的产品经理来说,B端平台产品是比较有难度的一项工作。本文作者基于自己的工作经历,提出了四点关于B端平台产品需要培养的4种意识,希望对你有帮助。...

2020-06-15
广告系列:保留价

广告系列:保留价

在一次拍卖中如果所有买家的报价均小于卖家的估价时,则拍卖品不出售由卖家保留,此时卖家的估价就是保留价,也叫底价,全称市场保留价。对于卖家来说,保留价的设置保...

2020-06-15