成功的产品经理各有各的不同，而失败的产品经理只有一种，而学习前人的经验是比较有效的一种路径，因为不身临其境是不易获得带着毛细孔般的感知。作者：连诗路
为了帮助新从事智能硬件的产品尽快的熟悉智能硬件部产品流程，掌握各种数据，平台工具的使用方法，以及提高产品设计能力。特以智能硬件产品经历为例制定适合转型到智能一到三年的PM/PD工作手册，方便新工作。
概述
智能硬件PM/PD手册包括：调研方法与工具、Feature List、Demo、MRD，如何进行UE、商务、技术、需求沟通、会议纪要、邮件记录、项目流程等内容。
▍1.1 目的
制定本手册的目的是使刚到智能硬件的PM/PD更详细的了解，智能硬件产品设计的相关工作流程和细节，从而加强PM/PD的专业性。提高产品设计和把握项目的能力，更快的进入智能硬件工作。
▍1.2 目标
熟悉各类平台和工具的使用方法
掌握产品栏目调研和需求分析的方法
熟悉项目流程和提高细节执行的能力
▍1.3 适用范围
所有智能硬件入职不久的PM/PD同学。
需求阶段
通过对智能硬件用户需求调研，分析核心需求点，明确产品方向，功能点，输出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.4 Kick off
具体内容：
特殊说明：并非所有项目均需进行，启动大型项目或重要并完整的新项目时进行kick off。
对应产出：会议纪要，确认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及效果图，并上传至文档保管处。
跟进技术排期。
开发阶段
▍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.4 BUG修复
具体内容：跟进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/B test
具体内容：
选择部分用户或者终端进行升级，进行小流量引流，投放内测组，效果，观测，平稳过渡，若有需要进行ABCtest，则进行部分用户小流量上线验证。
当然，无论是小流量引入还是A/B test，都只是手段。PM同时更应该注重数据和用户需求的研究与分析，利于各种简单有效的手段进行验证测试，避免产品功能风险。
另外，A/B test需要有足够的UV样本量。A/B test核心是分流，如果样本量太少，有可能会被偶然因素影响，对结果判断会有干扰。
▍5.4 开放正式入口
具体内容：
方式：提前通过邮件申请首页推荐位入口和周期，经和市场运营团队协商一致后，有运营进行操作。
对应产出：邮件通知入口开放，效果数据同步。
运营阶段
▍6.1 效果评估
具体内容：开放入口数据统计稳定后，累计两周左右数据后，进行对比分析，给出线上，后续迭代计划。
对应产出：效果评估报告、邮件发出。
效果评估示例：
▍6.2 项目总结
具体内容：对于流程周期较长的项目进行项目总结，主要对项目中自己或其他角色做得好和不好的地方，以及后续改进方法进行总体阐述。
对应产出：项目总结报告邮件发出。
▍6.3 运营推广
具体内容：
对应产出：PV/UV/VV使用时长等关键指标上持续优化。
▍6.4 持续优化
具体内容：产品持续优化，迭代。
对应产出：迭代计划。
总结
本篇列举了一个日活千万的智能硬件平台软件部分的生产流程，可有效地帮助从事智能硬件的产品人员，产品策略能力的快速提高。
当然快速提高的前提是基础扎实，产品的基础工作是不经一番彻骨寒，岂得梅花扑鼻香，成功走出来的产品几乎是砥砺过开发、实践过营运、更是经历过市场用户的检验，这种经历也许痛、也许苦，但最终一定会使产品的思想更丰盈。
作者：连诗路，公众号：LineLian。微信私号 Line15201991967，人人都是产品经理专栏作家，前阿里产品专家，希望与创业者多多交流。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
