产品经理必学的几个需求分析

 

产品设计规划之初,涉及到站内信模块时,我还是心有余悸的、保持一份谨慎的态度。在大多数人眼中,站内信可能只是一个简单的辅助功能,在一款功能全面的产品中更是显得微乎其微、不值一提。如果搁在以前我刚接触产品那会——直接一鼓作气画原型、搞文档,并不会有前瞻性的评估和规划。

我相信:每一个产品设计的背后必须被赋予某种具体的意义!

背景意义

1. 运营成本:初期版本系统(V1.0)依赖运营商短信模板直接搭建与用户之间的沟通渠道,主要通过发送短信告知用户关键时间节点上的结论性结果,而高频次地发送短信必然带来高昂的成本性支出。

2. 功能局限:运营商短信只能提供单一的固定短信模板,每一条的短信模板都必须经过运营商相关部门的审核,缺乏良好的灵活性和定制性可能性,对业务形态多样的产品尤为不利。

3. 迭代规划:产品规划过程中,周期性迭代升级是一种良好产品运营模式下的宠儿。初期产品重点关注基础和核心功能,相对结构复杂且优先级不高的站内信功能,适当地下放至后期的迭代完,过程上肯定是合理的,主次分明也有助于业务的清晰明了。

4. 业务驱动:降低运营成本固然重要,而减少产品对外部服务的依赖性也不容小觑,逐步完善产品内部功能,增强用户的产品粘性,迫使用户自然延长产品的使用/停留时间。站内信息的发送和接收,形成一个完善的产品正向反馈闭环。

产品分析

1.站内信是什么?

产品体系内的用户与用户之间、用户与产品之间、用户与管理人员之间传达信息的一种通讯方式。

2.如何设计站内信?

2.1 相关平台:[WEB]前端和后台

2.2 功能解构

业务流程:产品各个业务流程中,产生的业务流在每一个阶段都应该给予特定的交互,闭合用户行为的正向反馈。用户行为路径的关键节点,或许正是由于一个不起眼的站内信功能而点亮一款产品。

产品运营:提升产品注册用户的活跃度,增强产品的用户粘性,这两个要点应该是每一个运营人员无法忽视的关键数据指标。产品框架体系内,站内信承担着”营销工具“的重任,通过站内信向已经沉睡、静默的用户推送精心准备的高价值/大热门的内容,可以唤醒沉默用户,一定程度提升产品的活跃度。

2.3 前台功能

1.接收消息:借助站内消息通知,及时了解某个任务/行为的进程,是一种产品设计策略性的方针。接收方式有多种:

  • 消息提醒功能:语音和图标
  • 关键消息提醒:双重提醒

大幅缩短用户与信息之间的路径,降低满足用户需求的成本,直截了当地将结果送达至用户眼皮底下。这方面的设计下文《产品需求文档》中是有体现的,务必用心感受。

2. 打开方式:消息的呈现形式很大程度决定了——用户是否愿意查阅推送的系统消息,策略性的重度重复通知消息,只是一种策略并不是目的。

  • 消息列表:站内消息仓库
  • 查看详情:消息通知详情

3. 功能设计:通知、查看、删除(单一/批量)、详情,简单的操作和思路让用户自主式地优化信息,使其更加清晰地呈现在用户面前。基础功能决定产品上层结构,重视前期的基础建设,为后期完善产品细节和逻辑将会有莫大的益处。

4. 消息类别:以消息状态或消息类型划分类别,两种维度的信息归类各有权衡利弊与得失的必要。

  • 消息状态:已阅读、未阅读(默认全部)
  • 消息类型:系统通知、网站公告、订单消息、活动消息(其他类别)

消息类型可能存在扩容,而消息的状态相对固定/稳定,包括:已阅读、未阅读,完整诠释了事物的两个方面。良好的产品必定一开始就为后期的扩展预留了足够的空间,这也是一款优秀产品的开始。

2.4 后台功能

因果循环,深深不息!站内信本质上是——某一特定场景之下触发的某一条通知性消息。大致分为:系统消息,主要是行为信息流的关键节点类通知;运营类消息自定义手动发送运营消息,主要是运营人员依据实际的业务需求手动推送的指向性信息。

  • 系统消息:由系统业务流触发不同场景下的消息提醒,极具过程性,将每一个结果融于有意义的过程中。下文PRD案例中将会详细描述不同应用场景下的站内消息。
  • 人工消息:由运营人员在后台CMS内容管理直接投入到前台内容的生产和管理,俨然一副商业化营销和运营工具的样子。有时候,人恰恰才是最不可靠的!对人员的束缚就被提到了一个更高的道德层面。

2.5 跨产品线

互联网发展趋向多样,单一产品跨平台、多场景的也是大势所趋、人心所向。产品路线规划图体现着公司发展的意志和资源性投入的重要参考。跨平台产品设计存在多难点,数据、账户、存储都值得付出和努力。站内信推送就是一个典型的例子,而这一点在面向C端的产品上体现的更加明显。以下为多产品线并行的一些值得思考的价值点:

  • 产品形态:WEB消息推送时,是否同步推送H5/APP移动终端?
  • 推送形式:(PC/手机)产品,消息推送的形式存在差异;
  • 推送时机:不同形式(WEB/H5/APP)的产品推送消息的时段都有各自的特点;
  • 运营内容:消息的触发场景存在差异,即并不是所有推送站内推送都适合全平台推送;

需求管控是产品管理的核心环节,一句话:需求都没搞清楚,做个Pi啊!搪塞了多少老板的冲动,堵住了多少产品经理的嘴,挽救了多少技术程序员的付出。需求管理位于产品管理的上游环节,决定了下游产品、技术、运营等一系列工作的开展价值与意义。

刚接触产品之初,需求管控——需求收集整理、分析细化、抽象具体、沟通确认、排期追踪几乎占据我个人工作内容的一大半。说实话,真要感谢那段时光,这么一项极具挑战而有意义的工作与我不期而遇。尽管充满不易与纠缠,细细想来却还是满心的不舍与难忘。

如果说人类起源于海洋,产品/服务必定是立足于——用户需求(RT)。这句话可以从两个维度解读:

  • 产品/服务/解决方案不是无源之水、无本之木,也不是产品经理的一厢情愿,更不是凭空想象的不切实际。
  • 用户/需求方概念是广义的,泛指老板、产品经理、运营人员、技术团队、产品用户等需求潜在提出者。

两大背景

有人问:为什么需求管理拥有如此举足轻重的地位?存在即合理,需求分析的存在得益于两大背景:

背景一、需求已经成为互联网/软件产品/服务的代名词。产品经理只要谈到产品,需求二字绝不离口。用户需求是产品/服务的最初出发点,还原原质化需求(Material RT),产品经理应该本着尊重事实的原则看待每一个需求。需求位列用户体验五要素的第一层:战略/需求层,强调了越早接触需求、越早理解需求。

背景二、需求属于产品的顶层设计,决定了产品的方向及被赋予的意义。需求理解不到位、出现偏差,未能洞悉用户需求的本质,等待的只能是毁灭。核心环节之所以意义非凡,在于想要精准把握原始需求远比想象要难地多,将不同立场的需求提出者“统一思想、听指挥”更是不小的挑战。

两个问题

纷至沓来的需求,最初显得有些凌乱。需求充分接触之后,我觉得需求分析过程的两个核心问题

1、需求来源广

2、需求数量多

那么究竟该先做谁的什么需求呢?经验狠狠给我一记耳光:需求方都是爷!

用户需求来源

产品经理身为需求的第一负责人,任何与需求相关的事都是产品经理的事。做人要有原则,做事要有章法,做产品要有态度——产品面前,需求一律平等!当然,不是要求一味坚持、而是策略性地变通。谁提的需求,是具有现实意义的。BOSS提需求,你敢搁置?评定优先级方法——[优先级+]是技巧性的需求优先级解决方案:

[优先级+]=需求优先级+不确定因素。

说明:

需求优先级:综合分析得出的结论,包括:马斯洛需求层次理论、KANO模型等需求分析理论方法论;

不确定因素:主要以人为因素为主,比如:提需求的是老板、私交不错、提需求的妹子长得不错等;

经济理论有言:经济基础决定上层建筑!对于产品/服务而言,需求直接影响产品的走向/调性。需求分析最核心的工作应属需求价值判断。制定需求优劣的标准是个技术活,更不要说将标准落实到具体的需求之上呢?

两个事实

判断需求价值基于两个事实:

事实一:需求提出者身份各异,分布于整个公司的各个部门。需求来源不一,目的却惊人的一致——解决问题。反馈用户需求的并不一定就是需求的真实诉求者,太多需求靠主观臆断、个人需求代替大众诉求。

事实二:产品协助用户解决问题,而非需求堆砌的产物。传播伴随着能量的损耗,接收到的需求还靠谱吗?不可避免会出现信息错位、不对称的现象。不同人意识形态各异,客观需求经由不同人的思维加工存在误差。

两个要素

判断需求价值两要素:

要素一:满足用户需求,解决实际需要

从需求本身出发:需求必须具有普适性,是大多数人的需求,而不是某个特例。产品经理(PM)只有认真倾听需求方的描述,与对方沟通清楚需求的每一个细节,深入挖掘深藏需求背后的故事,最终设计出来的产品是要能够真正解决用户所需,才有真正存在的意义。

要素二:需求务实可行,能实现可落地

从实现需求出发:产品经理很容易忽视这一点,有时候还以所谓的职业化做托词。想起那个激进的岁月:人有多大胆、地有多大产。没有做不到,只有想不到。产品经理只负责想需求的输出,能不能实现一概不考虑!如果需求不具备现实意义上的可行性,那需求只能还是需求!

除了需求的显性价值之外,合理性、可行性也被产品价值性囊括在内!用户需求转化为产品需求,衍生了以下两个基本点:

1、技术资源能力:产品经理(PM)是需求的管控者,保证需求的价值性、合理性、可行性是最基本的工作。同时,产品经理还需要判断公司技术储备资源是否足以支撑所提需求顺利的“负荷量”。技术资源有限,投入比例相对固定,需求实现无法万无一失,将不确定性控制在可承受范围之内。

2、数据驱动管理:需求分析是产品经理卓越思维能力的体现,不止于简单的照本宣科或按需而设,而是数据驱动需求管理,哪些需求优先解决?以怎样的方式解决?最终表现成什么样?这些都不是主观臆断随猜测的,而是客观数据指导下的理性产物,是对早期需求价值判断、评定优先级的最好回归验证。

俗话说:不以规矩,不成方圆。数据分析倒逼需求管理日益趋理性,而不再是涂鸦式的需求收集。产品需求依据客观数据做相应调整,才能被赋予现实价值。经过数据结论检验,才能验证需求管理是否有意义。

小结

《游山西村》有言:山重水复疑无路,柳暗花明又一村。需求管理/分析本就是一个经验性的过程,主观成分很重,正是经验的存在才能让需求管理得以开展。面对不确定性,更应该以预设性的手段加以约束,数据分析恰恰弥补了起初的经验性判断和假设。

需求管理的三个准则:第一,实现商业/用户价值;第二,解决用户所需;第三,具有现实意义、切实可行。多数产品经理喜欢大谈用户需求、痛点,我想:究竟痛不痛只有用户自己知道,甚至用户也不知道!

产品经理(PM)无法取代用户,主观臆断产品的需求。只有符合用户预期、直击用户底层需求、所思所想具有现实意义(可行性)的产品,才是真正符合市场预期和引领行业前进的产品。

以博客的形式直播《站内信体系》的产品逻辑设计,其实最主要的用意是回顾自己还原《站内信体系》设计的每一个脉络和细节。

下方链接为 《站内信体系》的产品需求文档(PRD)

 

文章由PM28网编辑,作者:海阁,如若转载,请注明出处:http://www.pm28.com/492.html欢迎投稿

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息