【产品经理】需求池和版本树

2023-12-13 04:44:27

在这个人人都是产品经理的时代,每位入行的产品人进阶速度与到达高度各有不同。本文作者结合自身三年产品行业的经历,根据案例拆解产品行业的极简研发过程、需求池、版本树、产品自我优化等相关具体方法论。

在这里插入图片描述

一、产品研发的极简过程

1. 产品概述

产品就是一棵树的形象,从生长环境的泥土里吸收养分,一个阶段一个阶段的成长。产品也需要是一颗树的形象,在自己的成长中挺直主干,直冲苍天。在努力成长中,给人一片阴凉,呵护一方水土;即使在之后倒下,也能够提供自己的身躯,给他人以借鉴,再铺一段路桥。

2. 需求池和版本树

抽象的需求池版本树形象,底部平台为需求池,上面分支生长开来为版本树。

借用简单的形象,就能从大局着手,看清楚一些最核心的内容。

在需求池上,本质是提供产品的生长环境。作为树的形象生长,就需要生长环境土壤肥沃,获取必要元素足够。那么,在实际的需求池构建上,就需要有广泛的意见收集,经过专业的筛选过滤,输出形成定版的需求。

  • 用户反馈,是产品深植的土壤,接触用户最大的需求及最深的痛点,最好的解决用户的问题;
  • 市场反馈则提供当前市面的发展情况,需要相关的硬件、技术、市场环境、配套设施等多维度匹配;
  • 竞品分析,则很好地比对了自己这一个物种的情况。在信息发展跨越度很大,融合很深的现在,就需要扩展更广范围的竞品,将更多的风险和机遇预估在范围内,从而有效促进产品成长;
  • 战略规划,则是产品需要为公司的发展战略铺路,辅助公司整体战略的实现,也需要公司内部各部门的通力配合,维护产品的健康成长;
  • 技术趋势,则是紧跟技术发展,实时更新产品的内核,确保产品更具有生命力;
  • 产品设计,则是将所有的收集整理,整合到产品的具体实现上,是信息整合的升级提升。

以上各个维度构建了需求池搭建的相对完善的框架,基于产品不同的生命周期、当前所处的阶段,需要给与不同维度不同的权重。

信息的权衡采纳,决定什么内容被产品当前版本吸收,这是很关键的一部分。当前范围的确定,从宏观上,确定了产品所需要的必要元素,从而筛选出来最有效的内容,促进产品快速成长。

3. 需求池和版本树关键内容

在产品成长中,产品发展相似与树,但是又不同与树。树的生长经不起一段生命周期的内容完全剥离,且在树的生长过程中,原有的树干也会逐渐粗壮起来。也因此,延伸出来,产品的版本树需要能够在未来枝繁叶茂,需要在主干业务上搭建最强壮的框架。

之后的 业务会一直使用最初始的框架,也就决定了之后的产品是否能够走的更远,长得更好。这也符合,先控制后碎部的思想,更符合事情的二八定律。做好一件事情,做好最关键的部分,事情就算完成百分之八十。同样的,在产品树出现问题时,要敢于及时削掉不必要的部分。

产品多余的部分在树上面就是个疙瘩,在实际的产品上,不只是消耗内部因为这个功能牵连的人力物力投入,更会在用户上消耗用户的好用度,会降低整个产品的品质。而这些最关键的部分就是,树要成长,产品需要不断版本升级来变得更好,那就需要落实,需要更高效的产品成长。也就是产品一个版本一个版本的实现,一个版本基于上一个版本的迭代升级。

在研发过程中,消耗最大的就是需求不确定,来回版本的更改。需求整理,需求讲解,UI设计,研发实现,测试验证,是一个个工作环节串联起来的。工作环节越往后靠,前面消耗的时间就越多,所以,最好的方式就是需求定版,从最开始的环节把控好需求的执行,确定最为清晰的目标。
在这里插入图片描述

二、需求池

  1. 需求收集:战略规划、市场反馈、用户反馈、产品设计、竞品分析、技术革新。
  2. 需求整理:伪需求、表层需求、真实需求、兴奋需求、深层需求。
  3. 需求筛选:需求重要性、需求紧急度、影响范围、安全性、时间要求、技术难点。
  4. 需求设计:用户角色、使用场景、业务流程、使用流程、数据追踪、原型图设计、PRD文档维护。
  5. 项目管理:时间进度规划、产品质量验收。
    在这里插入图片描述

1. 需求整理

信息大爆炸时代,相比于信息匮乏年代的信息内容缺乏,信息的堆积和冗余并不会更简单更容易处理。经过需求池构建六个维度的信息收集,关于产品设计,我们获取了大量的信息。而从这些信息中筛选出来真实需求就十分必要。

需求整理,是对需求信息的遴选,是把非必要的需求信息剔除出去。

需求挖掘中,对需求进行层次划分,细分为伪需求、表层需求、真实需求、兴奋需求、深层需求。其中伪需求、表层需求,就是最没必要的需求。这些只是用户痛点的遮盖布,我们都没有看到真正的病痛表现。

真实需求,就是直观的展示,看到的就是需要的,这种需求就需要再度识别,或许头疼就真的只是头疼。而对于兴奋需求、深层需求,就是掩藏在头痛下的根本,挖掘到根本,最后实现的产品才会真正接近用户的需要。

头疼若不是头疼,可能只是需要你的关心,那就是兴奋需求。不需要管什么头疼,对她呵护备至、疼爱有加,她的头疼就不是产品的问题,而是产品的价值!头疼若不是头疼,而是其他脏器损坏的痛觉转移,那就是深层需求。不管如何去医治头疼,最后不解决脏器的问题,头疼问题就算解决,也还有其他疼痛问题。

常见的说明,都会是更快马车的真实需求,这里换工作的生活例子看看。老板需要日周月报?是需求,是真实需求,但只是需求的表象。老板需要的是日周月报,但其实他更需要的员工的有效工作权衡证据,若是及时反馈任务进度,及时反馈异常信息,那日周月报还需要?

或许这还不足够,老板为什么需要进度,为什么需要他来监督进度?因为进度不如预期,至少在之前的所有工作中,进度都不如预期,或者说是,常常他以为是这样但现实却不是这样。在深挖一点就是,他没有安全感,他不信任,那么是谁给了他不安全感呢?是管理人员的管理能力不匹配?是项目安排执行不够精准?这估计就是职场,需要事事有回应、件件有着落的根本原因吧!

替换日周月报,更好的是目标、状态、进度、预期执行结果的统计表。本周正在做XX竞品分析,正常状态,进度50%,预期明天中午十二点结束。

2. 需求筛选

经过需求整理,所留下来的需求都是真实的需求,百川终到海。而所有的需求又需要排列顺序,从而决定哪些需求优先做,逐渐形成需求的金字塔。

其中筛选的重要条件包括,需求的重要性,需求的紧急度,影响范围、安全性、时间要求、技术难点等要素。依据产品的不同的阶段,公司发展的状态,产业所处的行业,当前的生产环境等会给与需求不同要素不同的比重。

整体回馈,还是要依据先控制后碎部,步步检核的原则来设定。

技术难度、安全性会在很大程度成为一票否决权的情况,需要优先确定。之后依据重要度、紧急度、时间要素等综合,按照数字打分的方式对需求的权重进行数字化,从而辅助决策。

同时,在公司进行重大决策,重大变更时,也会协调相关的人力资源倾斜来实现,从而让项目管理落地到实处。实际的情况就是,当前要做的内容多,重要性都高,且最好都一次性上线,在这种高度挤压集中的情况下,产品就更应该集中精力把产品的设计、需求的完善落到实处。

把人力不足,时间紧迫等相关问题交于项目管理来协调。专业的人办专业的事情,将是最为高效的。也就需要,在自己把控或者不属于自己管控范围内的,要迅速给与他人以合适的信息,让其他人共同协助实现。这也更是给与其他人实现自我价值的机会。

在没有那么紧迫,没有那么多需求堆积时,相对的处理也就更容易。

3,需求设计

经过前面相对较为“复杂”的过程,确保需求有效的被筛选出来,更关键的就是把需求做出来。在需求设计时,推荐用户角色,使用场景,业务流程,使用流程,数据追踪的方式进行整体的设计。

涉及一个需求的实现,我们需要完整的用产品思维整理出完善的使用场景。优先考虑有哪些角色使用当前功能,也就是确定人员类别,确定不同人员使用的场景。

外卖平台会有下单用户,外卖跑腿用户,会有商家用户,会有平台管理用户;内容阅读平台会有内容阅读者,内容创作者,内容管理者,内容审核者,以及平台管理者。在角色范围确定时,常常会漏掉平台管理员的角色。

使用场景就是一个角色会在什么场景下使用这个需求功能,也就是确定功能范围。例如一个内容阅读者需要内容阅读;需要和内容进行交互,点赞、评论、分享、收藏;也需要和内容创作者有一定的关联,就需要关注、私聊、打赏;而这些所有的都是每个读者所独有的,就需要用户的账号体系;而伴随平台内容的广泛还是垂直,还会需要构建用户特色,栏目关注。

业务流程则是使用场景的整个过程的梳理完善。内容的阅读,是从筛选内容开始的,筛选内容,阅读内容,是否更多交互,是否和作者平台有关联;回退然后筛选新的内容,重复流程。

阅读内容的往后延伸流程完成,还需要回退查看流程的另一端,即是内容的产生:已发布的内容,回退到内容审核,回退到内容的发布,回退到内容的编辑。依据这个主流程,再把每个环节细化,看看是否还需要扩展。

例如,已发布的内容是否有优先级顺序调整?整个过程会依据流程的逐步细化而完善,而精细化。整体业务逻辑梳理清楚,但作为步步检核的坚定执行者,还需要验核上面所有的流程是否真的完善,那就使用数据流检核。

内容的数据流,主要是内容的产生到内容的消逝,就会发现之前的流程设计,还缺乏内容的撤销和删除。基于每一个功能拆解数据的产生,数据的流转过程,数据的消逝,以及所有数据的统计分析,从而验证功能设计的完善性。

最终输出就是原型图,最好能够整理PRD文档。基于当前很多公司是实际执行情况,建议把PRD文档的内容完善补充到原型图中,然后配合问题列表,实现文档的高效化使用,以及内容的可追踪性。

三、版本树

(1)核心业务实现,业务框架的搭建

(2)登录注册用户体系搭建

(3)业务商城推广

(4)活动模板构建

(5)数据运营挖掘

(6)产品监控自我优化

之前的过程,实际已经将产品的关键执行顺序融入。在当前版本树的执行中,基于需求设计完善的基础,产品更多的参与是确定需求宣讲落到实处,让研发、测试能够统一理解需求,争取接近100%的需求理解。

从实际的经验中来,需求讲解,其他相关人员参与度不一定很高。而在需求讲解中,给其他人不确定的提问,有助于帮助集中所有成员的注意力。更是通过提高他的信息输出来倒逼他的信息输入。

在相对规范的公司,会需要所有人员再写需求确认,从而实现需求的传达一致性。在过去从事的项目执行中,配合先控制后碎部,步步检核的理论,整理出来如下项目管理的模型,期许能够辅助大家将项目执行更好的落地。

整个项目的执行,主要分为阶段,应用里程碑作检核;把阶段拆解为任务,用检查表来检核。一般的版本升级迭代,阶段划分可以分为需求整理阶段,UI设计阶段,研发实现阶段,测试测试阶段。各个阶段的里程碑是对过去的一个阶段的整理,也是两个阶段的交接,更是阶段产物的验核。

对产品来说,需求设计完成的阶段,需要交给下一个阶段需求设计原型图,若是输出完整的PRD文档是最恰当的。通过需求评审,进行需求设计的再一次检核,集大家的智慧完善需求,确保需求设计考虑完善。

需求设计阶段中的任务拆解,就可以使用之前的环节,包括需求收集,需求整理,需求筛选,需求设计,而对应各个任务的检查表就是对应任务的结果。需求收集,得到的结果应该是一张需求统计表,记录当前所有有可能需要执行的需求;需求整理,则是将哪些需求屏弃掉,将精力锁定在最关键的需求上;需求筛选,得到的结果是用什么样的理由决定了哪些需求当前版本优先执行,且各自的执行顺序是怎样的;需求设计也就是原型图设计,达到能够很好传递信息给后续环节的目标。
在这里插入图片描述
在这里插入图片描述
在项目的执行中,也要求项目做结项处理。从而形成项目经验,让后续新项目的执行基于当前项目进行维度升级。同时,项目中的执行文档、检查表、项目阶段规划,都是相关项目的实例,可依据这个内容抽取形成模板,构成每个参与者的勋章。

四、产品自我优化

(1)产品自我审视:版本树复盘

(2)用户行为研究,大数据分析

(3)用户直接反馈渠道

(4)MVP:最小最有价值产品版本

一个产品就是在这样的流程下,产品逐渐变得越来越好;一个团队,也就是在这样的项目执行下,变得越来越专业,越来越高效。

在项目都在推行项目复盘的情况,那么每一次的需求实现及运行,也需要对产品进行需求复盘,对“枝丫”需求进行适当的删减,对“主干”进行适当的补充完善,使其更加茁壮成长。

在产品运营过程中,也需要监控产品本身。依据产品用户群体的活跃度、留存率等来辅助确定产品的朝向;用各个页面的使用率及使用路径跟踪,确定产品的设计优化,辅助产品进行内容改版和升级;用产品的版本对比、时间对比、峰值、数据量等多方面变化来检核产品,进行自我的辩证认知。大数据的分析和挖掘,将能辅助产品走的更远,走的更稳。

产品还是需要根植于用户,构建用户的反馈渠道,就能更直接的和用户接触,也更能发现那些细节问题、特殊情况问题,也是另一个坚持,步步检核。

在整个整理过程中,会发现,需求的整理及实现,花费了大量的时间和精力。在实际的执行中,因为需求池的明确,需求筛选之前的很多事情都省掉。最关键是,所有的需求按照深度思维都是可以不断挖掘的,但是在实际的情形中,会因为生命周期、产品阶段,会存在部分功能隐藏较深,不被使用的情况。

所以,产品在初期的需求设计中,不必尽善尽美。在完成核心业务逻辑的实现后,需要尽快投入市场,依据市场的反馈,更加及时的修改,以确保产品深耕于用户群。这就是产品最小最有价值版本设计的方法,即是MVP,也确实是MVP。
在这里插入图片描述
需求池和版本树的进化一个人可以走很快,一群人可以走很远!当前的内容分享,主要跟大家沟通一个实际工作的大框架,将自己的工作范围锁定下来。后续会逐步将各个环节细化,走向更加专业的深耕。也是如此,整个内容框架适合整个方向的工作,而个人需要依据实际情况,进行方法的筛选,截取对自己最有效的部分,执行正确的内容,并正确的执行。

向阳生长,和有趣的人同行。

文章来源:https://blog.csdn.net/qq_41661800/article/details/134935792
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。