PM必备:日活千万智能硬件产品经理手册
成功的产品经理各有各的不同,而失败的产品经理只有一种,而学习前人的经验是比较有效的一种路径,因为不身临其境是不易获得带着毛细孔般的感知。
为了帮助新从事智能硬件的产品尽快的熟悉智能硬件部产品流程,掌握各种数据,平台工具的使用方法,以及提高产品设计能力。特以智能硬件产品经历为例制定适合转型到智能一到三年的PM/PD工作手册,方便新工作。
概述
智能硬件PM/PD手册包括:有调研方法与工具,Feature List,Demo,MRD,如何进行UE,商务,技术,需求沟通,会议纪要,邮件记录,项目流程等内容。
1.1目的
制定本手册的目的是使刚到智能硬件的PM/PD更详细的了解,智能硬件产品设计的相关工作流程和细节,从而加强PM/PD的专业性。提高产品设计和把握项目的能力,更快的进入智能硬件工作。
1.2目标
- 熟悉各类平台和工具的使用方法
- 掌握产品栏目调研和需求分析的方法
- 熟悉项目流程和提高细节执行的能力
1.3适用范围
所有智能硬件入职不久的PM/PD同学。
2.需求阶段
通过对智能硬件用户需求调研,分析核心需求点,明确产品方向,功能点,输出demo,与组内分享并确认产品feature list,和demo,启动项目kickoff,输出对应的UE需求以及资源需求,撰写PRD,需求准备完成后进行产品评审以及技术评审。
2.1需求调研
具体内容:用户需求调研得出用户需求点。
注意事项:
- 明确调研对象和目标;
- 清晰规范的调研大纲;
- 有说服力的数据支持;
- 准确合理的调研结论。
对应产出: 调研报告
2.2 Feature list及demo
具体内容: 根据调研结论输出产品功能列表及产品demo图。
Feature: 即产品功能点列表,对应覆盖的需求点,及该功能点优先级。
Demo图:
即系产品页面线框图,原型图,可用axure、visio、PS、fireworks等任意擅长的工具,去完整的表达出产品各个模块的功能位置,以及所有交互行为,可保证UE同学利用DEMO设计出完整的页面效果图,技术同学可利用demo开发出完整的功能。
文案要尽可能接近真实,强化及弱化的功能点表达清楚,web/app端产品,尽可能按照页面实际图片元素的比例,进行示范。
对应产出: feature list,demo图。
Featurelist 示例:
Demo图示例:
2.3调研分享
具体内容: 分享调研内容,收集建议,确认feature及DEMO
对应产出: 会议纪要
会议纪要组注意事项: 主要包括时间,地点,人物,会议议题,讨论内容,会议结论,确定问题, 遗留问题。后续计划及跟进人等
会议纪要范例:
2.4Kick off
具体内容:
- 确认技术人员技术接口人,统一安排
- 启动项目,根据资源引入成本,技术成本,等因素讨论,并最终确定项目feature
特殊说明: 并非所有项目均需进行,启动大型项目或重要并完整的新项目时进行kickoff.
对应产出: 会议纪要,确认PM、FE、RD、QA对应负责人,明确接口人,技术人员对应一个PM接口人。
2.5资源引入
具体内容: 商务合作需求,商务接口人
提出方式: 邮件方式详细描述资源需求,
资源需求要点 :
- 项目背景,
- 具体资源需求。
- 有无指定合作方,
- 相关产品及技术接口人,
- 资源到位的期望时间,
对应产出: 需求邮件及资源到位的情况。
2.6,UE效果图
具体内容: 提请UE需求——UE接口人。
提出方式: 邮件方式,将详细描述UE需求发出,附Demo图,若需交互设计师执行交互设计,请与交互设计师优选沟通,完成交互设计设计稿后交付视觉设计师执行。
UE需求要点:
- 项目背景;
- UE需求点,(包括文案);
- 线框图即可,避免影响UE设计发挥空间;
- 期望时间;
UE需求沟通:
- 新人第一次沟通需求需指导人示范,要点详尽描述;
- 第二次沟通时,需新人主导,指导人旁观把控;
- 提出组内确定后的需求,避免频繁更改;
- 需求描述时告知预计效果,而不是告诉我要什么;
对应产出: 邮件需求及UE效果图交互设计图。
2.7 PRD撰写
具体内容: 输出产品详细需求文档,清晰描述产品功能逻辑,策略及统计需求。
对应产出: PRD,最终版本需上文档保管中心对应所立项目。
2.7.1,PRD定位
PRD受众: FE/RD/QA等。
PRD重点,需求的定义,而不是需求的实现。
2.7.2,清晰的结构
适当拆分: 例如大型栏目,进行复杂功能改版,复杂产品管理后台的。
提供完整的流程: 文字概述,流程图。
利用目录控制大局: 目录不宜太细,且提供,链接指向相应页面,各级目录编号不建议使用:一、1、(1),推荐使用1、1.1、1.1.1。
突出重点: 需要强调的内容,都用粗体,或不同的颜色标出,必要时使用截图,尽量用流程图,列表,对比等形式展现,避免大量文字模糊不清。
2.7.3合理的顺序
根据用户的使用流程进行描述: 适用于新的产品,入口-使用-退出。
根据功能的依赖关系: 适用于产品的新功能,新升级,使用文字开锁或流程图。
使用表格和截图: 对同类信息适当使用表格归纳,对承载很多功能的页面应使用截图帮助理解。
2.7.4完整的细节
- 分清主干与分支,提醒合理的优化描述。
- 各种情况下的假定。
用户状态的记录策略,如切换TAB,下次进入是否为其记录上次状态,这里特殊字符的限制,比如:定宽式样设计的字数上限。
各种错误的提示信息: 所以PRD给出各种预期到的错误,详细错误号,及对应信息可由RD提供列表。
对其他产品的依赖及影响: 是否需要其他产品提供支持或对其他产品构成影响。
2.7.5严谨的措辞
不使用含糊词句:
- 形容词,例如非常、及其。
- 含糊不清,例如可能大概也许等。
不要和其他产品类比: 例如:同开放平台改版保持一致等。
预期到会变动的地方需明确指出: 预计后期升级的困难,帮助技术设计时考虑到可扩展性。
字数类描述: 使用字节,不要使用字(防止理解不同、可用字进行补充说明)。
必要的备注说明: 提示信息必须明确真实文案,与需求描述文字区别显示。
2.7.6变更需求
技术评审前: 变更需求需要有版本记录,需要随版本号给出日期,各版本的修改内容,提供各版本PRD撰写人。
PRD修改记录示例:
技术评审后:
原则上不允许随意变更需求,除非有重大失误或影响用户体验方面可以变更需求,变更需求需要获得指导人确认后,召集项目相关同学沟通变更内容,口头达成一致后更新PRD,对应变更内容,需以批注形式标注。上传文档保存处,邮件通知项目相关同学PRD已更新及更新内容。
2.8产品评审
具体内容: PM内部讨论及确定PRD及UE图。
争议处理: 产品凭内部评审过程中,如遇到意见分歧的情况,可通过如下几个方法进行处理,用准确的数据说话,必要时可进行AB测试,线上尝试。
注意事项: 欢迎提出不同的建议和意见,内部评审务必达成产品需求内部一致,但是需要发在产品内部群或者产品内部会中,避免到技术评审后在公共群及公共会议室PM/PD组内才发表不同意见,影响PM专业度,或者技术误认为产品内部没有达成一致就提出开发需求。
对应产出: 会议纪要修改后的PRD既有意图。
2.9技术评审
具体内容: 与负责项目的技术人员进行技术评审,评估实现难度,问题以及风险点。
评审准备 :
- 用于评审的PRD及效果图务必是产品内部确认后的版本。
- 至少提前一天发图片的及效果图,给参与评审的同学充分的熟悉内容时间,评审需在会议室进行,尽量避免在休息区进行,提前发出会议邀请。
- 提前五分钟,到达会场,准备好投影等相关设备。
对应产出:
- 会议纪要,通报修改点。
- 修改确认的PRD及效果图,并上传至文档保管处。
- 跟进技术排期。
3开发阶段
3.1立项
具体内容: 评审通过后,项目负责人立项,项目正式开始启动,进入开发阶段。
对应产出: 需求分析邮件,排期。
3.2跟进开发
具体内容: PM/PD跟进前后端开发进度,处理开发中遇到的问题,如需求有调整和改动,需及时更新加的。推进项目顺利进行。
注意事项: 开发过程中尽量避免修改需求,如遇重大问题,需要修改,见2.7.6变更需求部分操作。
对应产出: 前后端开发顺利完成,如修改需求,更新PRD邮件通知。
四,测试阶段
4.1配置数据
具体内容: 配置现场真实数据,需要人工配置的具体的数据内容。
操作步骤: 如配置推荐数据需提前向市场运营组提出需求。
对应产出: 线上真实数据,达到上线数据要求,邮件记录通报。
4.2效果确认
具体内容: PM,UE,对前后端开发效果进行确认反馈问题及时修复调整,使之达到预期效果可上线状态。
注意事项:
- 第一轮提测时发出测试版本供PM,UE确认样式和页面功能及时修改。
- 最后一轮提测时,发测试版本。PM、UE再次确认,此时不影响功能的小问题,可先行上线后续修改,避免人员反复修改。
- 新人第一次上线项目确认效果,由指导人把关,积累一定经验后客,自己掌握效果,确认无误后务必发出去的邮件。
效果确认点: PM确认产品功能及页面,UE确认,页面设计及交互效果。
对应产出: 修复问题,PM、UE邮件记录。
4.3内测组投放
具体内容: QA投放公测版本。到荣誉内测组,跟进内测组用户,反馈的问题和建议,推动完成bug修复,收集到的用户建议转化为相关需求,作为后续迭代计划。
对应产出: 邮件记录,需求收集整理录入到文档管理的产品需求池,产品视图-spark需求管理。
4.4BUG修复
具体内容: 跟进QA发出的测试问题,推动完成BUG修复。
对应产出: 测试报告。
五 上线阶段
5.1上线通报
具体内容: 上线前一周或更早时间,邮件通报版本上线公告介绍上线发布内容。
通告形式: release notes+功能介绍。
具体操作:
邮件通报项目组相关人员,及公司全组release notes+功能介绍,release notes尽量简明扼要,列举出版本发布的新功能及优化功能点,并附上相关的功能截图介绍。
对应产出: 邮件记录官网应用升级提示,release notes。
示例:
5.2效果回归
具体内容:
PM QA等对线上效果进行再次确认,如有必要请UE同学,确认页面及功能模块的设计实现完成度与UI问题。
针对QA测试的BUGLIST,PM需要确认debug的优先级,建议如下:
- 原则上,开发项目中的所有bug,在项目时间允许的条件下都要完成debug;
- 若版本持续迭代更新,严重影响用户体验的导致功能缺失,影响产品可用性的bug必须在产品上线前解决;
- UI问题以及产品中用户直观可见的BUG视影响产品可用性的严重程度,进行针对性解决;
- 优先级稍低的bug。可放在后续版本计划中review优先级,加入到debug计划;
对应产出: bug review 会议召集、邮件记录输出。
5.3小流量因素,(投放内侧组)or A/Btests
具体内容:
选择部分用户或者终端进行升级,进行小流量引流,投放内测组,效果,观测,平稳过渡,若有需要进行ABCtest,则进行部分用户小流量上线验证。
- 小流量引入的好处:新功能有待验证,避免用户大幅度反弹,降低风险。
- 适用于A/B test的情况,在不确定两种设计方案的前提下,将两种方案分别投放到随机用户中进行测试,对两种用户数据进行对比,从而为方案选型提供决策参考。
当然,无论是小流量引入还是A/B test,都只是手段。PM同时更应该注重数据和用户需求的研究与分析,利于各种简单有效的手段进行验证测试,避免产品功能风险。
另外,a /bbeat需要有足够的UV样本量. A/Btests核心是分流,如果样本量太少,有可能会被偶然因素影响,对结果判断会有干扰。
5.4开放正式入口
具体内容:
- 首页、产品模块对应的分类推荐,相应的分类入口展现。
- 通知研发人员开放入口,协调市场运营在首页推荐位进行推荐,并邮件同步给相关人员。
- 对入口的点击效果进行跟踪,同步点击数据。
方式: 提前通过邮件申请首页推荐位入口和周期,经和市场运营团队协商一致后,有运营进行操作。
对应产出: 邮件通知入口开放,效果数据同步。
6运营阶段
6.1效果评估
具体内容: 开放入口数据统计稳定后,累计两周左右数据后,进行对比分析,给出线上,后续迭代计划。
对应产出: 效果评估报告、邮件发出。
效果评估示例:
6.2项目总结
具体内容: 对于流程周期较长的项目进行项目总结,主要对项目中自己或其他角色做得好和不好的地方,以及后续改进方法进行总体阐述。
对应产出: 项目总结报告邮件发出。
6.3运营推广
具体内容:
- 产品相关的设计物料,产品亮点,FAQ等;
- 媒体网站,用户BBS,微博,微信等用户渠道的推广,广告,软文;
- 数据收集及分析,针对推广效果,做评估;
- 新的渠道引入,留住新用户;
- 相关运营工作活动专题等。
对应产出: PV/UV/VV使用时长等关键指标上持续优化。
6.4持续优化
具体内容: 产品持续优化,迭代。
对应产出: 迭代计划。
7.总结
本篇列举了一个日活千万的智能硬件平台软件部分的生产流程,可有效地帮助从事智能硬件的产品人员,产品策略能力的快速提高。
当然快速提高的前提是基础扎实,产品的基础工作是不经一番彻骨寒,岂得梅花扑鼻香,成功走出来的产品几乎是砥砺过开发、实践过营运、更是经历过市场用户的检验,这种经历也许痛、也许苦,但最终一定会使产品的思想更丰盈。
#专栏作家#
连诗路,公众号:LineLian。微信私号 Line15201991967,人人都是产品经理专栏作家,前阿里产品专家,希望与创业者多多交流。
本文原创发布于人人都是产品经理。未经许可,禁止转载。