发表于: 2019-05-08 21:09:05
1 598
今天完成的事情:
1.阅读人人都是产品经理文章
2.学习PRD文档相关知识
3.确定产品工作流程
4.学习任务九消息推送板块
5.完成任务八功能需求表
PRD是什么?
产品需求文档(Product Requirement Document,PRD)的英文简称,这是一个产品经理为了跟其他项目成员说明需求的重要文档,也是PM参加需求评审会时,你的成果作品。
PRD是给谁看的?
首先,PRD是给产品经理自己看的。产品经理提出一个需求,那么实现这个需求的功能、逻辑,通过书写PRD的过程,能够慢慢梳理出逻辑。
其次,PRD是给团队的其他人看的。一个产品经理,即便能够在脑海里想清楚所有的功能、逻辑,但是他不能保证团队的其他人也能在头脑里想清楚一切逻辑。所以,产品经理需要通过输出PRD,让团队其他人员理解需求的逻辑。
再次,PRD也是给老板看的。产品经理需要做某一个产品,在跟老板申请资源的时候,给出一份清晰的PRD能够让老板看明白你到底要做什么。
PRD作用
首先,PRD有证明需求的作用。
产品经理需要认真写一份PRD,通过需求评审后,邮件群发给开发、设计、测试等大爷,有文件留底,到时候他们就赖不掉了。
其次,PRD有证明PM的作用。
很多公司将PRD的修改次数作为作为评判PM水平的标准,还可能作为PM升级评定的参考因素。如果一个产品经理写的PRD平均修改次数过多,那将严重影响升级评定。
PRD闭环


PRD的目的
实现目的所需要的功能
完成功能需要的逻辑
异常逻辑、危机处理
争取需要的资源:项目成员、硬件资源
数据反馈:
- 访问量
- 转化率
- 留存率
- 用户活跃天
- 产品收入
- 任务、活动完成量、质量
需要注意:
1.换位思考
(文档是给开发、设计、测试等看的,语言上尽量好理解,尽量不要用形容词,描述功能时,可以尝试用开发的逻辑去思考书写方式。)
2.不要求大求全,功能最好分点说明,正常逻辑和异常逻辑分开说明。
3.所见即所得
有的功能点,逻辑比较复杂,这时可以考虑用原型图展现,原型图可以做到所见即所得。
4.实现进度如何?
在PRD之外,最好再做一个项目进度表,这份表格要做到及时更新,让整个团队知道项目的进度。
5.关于语病和错别字
基本不要有语病和错别字。语病和错别字太多的话,容易让大家觉得你很不严谨。
6.排版标准
排版一定要有一套标准,保证你的每一份PRD都按照同一份标准。排版力求美观大方,字体、颜色、字号、行间距等方面都需要有一定的选择。
需求入门 - 用Kano模型来确定需求优先级
KANO模型定义了三个层次的顾客需求:基本型需求、期望型需求和兴奋型需求。
这三种需求根据绩效指标分类就是基本因素、绩效因素和激励因素。
客户满意度模型Kano
- 基本型需求:顾客认为产品“必须有”的属性或功能。当其特性不充足时,顾客很不满意;当其特性充足时,对客户满意度没有多少影响,顾客充其量是满意。例如只要酒店浴室满足了我的基本需要,我并不会关心洗漱台的台面是用什么材料制作的。
- 期望型需求:要求提供的产品或服务比较优秀,但并不是“必须”的产品属性,有些期望型需求连顾客都不太清楚,但是是他们却希望得到 的。顾客通常谈论的是期望型需求,期望型需求又叫做线性需求,这类需求越多越好。线性需求在产品中实现的越多,顾客就越满意,当没有满意这些需求时,顾客 就不满意。因此,产品的价格通常和线性特性相关。如果酒店有健身器材,我会更加高兴,相比没有这类器材的酒店,我下次可能就会在此入住这里。
- 兴奋型需求:提供给顾客一些完全出乎意料的产品属性,使顾客产生惊喜。兴奋点和惊喜点常常是一些未被用户了解的需求,客户在看到这 些功能之前并不知道自己需要它们。当其特性不充足时,并且是无关紧要的特性,则顾客无所谓,当产品提供了这类需求中的服务时,顾客就会对产品非常满意,从 而提高顾客的忠诚度。这类需求可以为产品增加额外价格。
评估需求类型
我们可以设计一套问卷,对用户进行问卷调查。Kano建议通过对一个 功能问两个问题来确定分类:一个问题是如果产品中有这个功能,用户会觉得如何;另一个问题就是如果功能不存在,用户又是觉得如何。对每个问题采用5点的度 量方式进行回答:
- 我希望这样
- 我预期这样
- 我没有意见
- 我可以忍受这样
- 我不希望这样
Kano模型分析
- 对于必须完成的功能,在产品发布时需要完成,但并不是要求在第一次迭代时就开发完成。
- 完成尽可能多的线性需求
- 如果时间允许,至少应该确定少量的兴奋点优先级,把它们包含进发布计划
消息推送是召回用户、保持留存和内容推广常用的办法。
一、Push推送
Push推送受推送权限影响,若用户关闭推送允许,则该消息无法触达用户。所以,在第一次打开某个APP时,会弹出请求推送允许的弹框。若用户不允许推送权限,在后续的使用中,有些不服输的产品依然会再次触发提醒用户打开推送允许。
服务器 —> 第三方服务器 —>设备。
Android如下要将消息推送到手机,就要自己做一个类似APNs的东西,还要考虑及时性、稳定性、抵达率等,开发成本比较高,所以很多APP会采用第三方通道,比如友盟等。第三方SDK会拿到用户的Token,当要进行Push推送时,服务器将消息推送给第三方服务器,第三方将消息推送到设备上。
二、推送注意要点
1. 明确推送目的,选择适合的内容
推送的内容可以有以下几种:
- 与用户相关的主核心功能,如收到新私信、评论、点赞、收藏等;
- 新功能新于法的推送,如应用推出新功能,引导用户去升级等;
- 结合APP的定位,推送相对用户价值高的内容:如对于资讯APP,推送地震、海啸、宋慧乔宋钟基结婚等;
- 福利信息,如优惠券、红包、福利活动、秒杀开始等信息;
- 有时间截止的信息内容,如订单即将过期请支付等信息。
2. 选择触发时机
考虑用什么触点撬动用户,想在什么时候唤起用户,当触发点和时间更合理时,推送的效果才有可能更好。
触发时间:
结合用户的使用情况进行推送。如订餐APP会在考虑在上午10时给用户推送午餐优惠券;电商APP会在支付未成功的订单快过期时,提醒用户赶紧付费。(这种情况,往往更多是使用短信,触达率更高,更及时)
触发时机:
在用户提交外卖订单时,通知提醒用户购买会员免配送费,可能会比进入APP就引导用户去购买会员的转化的效果更好。
3. 结合业务考虑用户体验
除其他推送条件外,也结合业务的情况,考虑用户的其他体验,比如以下场景:
场景1:
之前我们做APP,允许用一个账号在不同的设备中登录,推送会同时推给所有的设备,但只要点击其中一个设备的消息,则另一个设备的消息会自动消失,免去用户被重复打扰的情况;
场景2:
对于应用内通知,我在设计功能时,虽然设置了有效时长,但仍不会在用户打开APP时立即进行应用内通知。我会考虑用户的平均使用使长,若用户刚找开APP,会在某个时间内随机下发通知,不会造成用户一启动APP就看到一大堆推送的困扰。
场景3:
该场景不算考虑用户体验。在商业中,有时候会采取应用通知来补其他点位的量,我也设计过此类功能。当时,为防止第三方查出在补量,曾跟开发讨论过,模拟APP日活曲线下发推送,不致于让数据在某个时刻点暴涨。
4. 个性化推送
APP的众多使用用户除共性外,依然有很多个性的喜好,根据外部自然情况与用户的实际使用情况给用户推送内容,会让用户更喜欢,主要表现以以下几个方面:
(1)推送条件细分
通过对用户进行地域、年纪、性别或者兴趣维度等,进行推送用户细分。比如以前我在做教育APP,内容会通过地区、学校、教材版本、年级、用户角色(家长、老师)等分发,推送时也会将适合的内容推送给最适合的用户。同时还会提取更细的数据类型,如通过用户的登录行为、付费行为、功能使用情况等将用户区分为XX型用户,推送时定向针对该类型用户推送,既可增加推送的准确性,又能降低其他类型用户的反感度。
(2)推送频率个性化
根据用户的使用场景和现实生活场景,进行推送频率控制。如之前我在做K12教育产品,暑假时用户活跃度较高,推送的频率也会更高;而临近期末考试,用户的活跃频率低,推送的频率也会相对降低。有些APP也会针对用户每天使用APP的次数和对推送的反馈结果,对不同用户进行不同的推送频率,如今日头条,点击推送消息越多的用户,收到的推送频率越大。
(3)推送界面个性化
推送行为会受用户影响,有些聪明的APP会通过改变推送的样式(皮肤),来增加用户的新奇感,但我并不认为这种方式时时凑效。
三、关注推送后的数据指标
(1)关注推送过程每个环节的数据量
消息通过第三方推送,每一步都有可能折损消息数量。首先要关注推送的漏斗,根据漏斗每一个阶段数据的变化率采取相应的措施。
- 若触太率太低,则要考虑是否需要更换第三方服务器,或者查看用户的禁推比例,引导用户打开推送允许,或者采取其他运营手段;
- 若打开量相对少,则考虑推送的内容是否符合用户口味,或是否与推送时间有关系等;
(2)关注召回率
对于Push推送,除要关注消息的到达数,也要考虑通过推送,用户的召回率。可通过A/Btest,对比受推送用户与其他非推送用户的召比率情况,分析推送是否有效。
(3)关注推送后用户禁推和卸载应用的数据
推送有可能会受到用户的反感,而导致用户禁推或者卸载APP,当推送成为日常的运营手段时,需要关注推送后用户的禁推率和卸载APP的数据波动。
明天计划的事情:
1.继续学习消息推送相关知识,了解APP推送和定时推送
遇到的问题:
消息推送是通过推送技术自动传送信息给用户,它根据用户的兴趣、偏好等定期推给用户,从而帮助产品运营人员更高效地实现运营目标,维持APP留存率。消息推送可以通过BAT平台,第三方平台,短信,电子邮件等,服务器 —> 第三方服务器 —>设备,是通过后台来操控?还是购买第三方后第三方给一个后台去操控??????
收获:
消息推送的分类和方式等,如下图:
评论