产品经理工作流
2020-11-03 09:52:18 4 举报AI智能生成
产品经理工作流注意事项。
作者其他创作
大纲/内容
立项阶段
概念阶段
市场调研
调研原因
验证我们的想法与政策、市场、用户需求是否耦合度高。<br>
调研方法
方法论
PEST
政治
经济
社会
技术
调研结果
BRD:市场规模、政策倾向、商业模式、盈利模式、资源投入、产品壁垒<br>
用户调研
用户画像
C端产品
属性
基础属性：年龄、性别、居住城市、家乡
伴侣情况：单身、恋爱、未婚、已婚、离异
教育情况：学历、专业、院校
家庭关系：长辈（父、母）、晚辈（子、女） （数量、年龄）
事业属性：行业、地点、公司、职位、收入
特征
社交习惯
线上：抖音、微信、微博...
线下：聚会、蹦迪、餐馆
爱好
运动
艺术
文学
游戏
旅游
动物
消费特征
消费力
消费频次
消费金额
消费行为
消费品类型
衣
食
住
行
学
消费偏好
质
价
B端产品
B端产品很多时候客户与用户是两个群体，需要在客户需求和用户需求中做出平衡。客户决定首次购买，用户决定续购和裂变。
客户在意的是收益，投入产出比。用户在意的是用起来顺手。
eg:火锅店点菜系统:客户：老板 用户：收银员\服务员
提案阶段
需求分析报告
方法论
马斯洛需求层次理论
生理需求
安全需求
社交需求
尊重需求
人生价值实现需求
KANO模型
基本需求
期望型需求
兴奋型需求<br>
无差异型需求<br>
反向需求
HMW 。<b>How Might We</b> 我们可以如何做
有什么用
找方向
扩展思路
脑暴
创新
什么时候用
脑暴前
分析用户反馈
需求优先级的排序
用户量频次问题
优先解决大量用户的高频问题
最后解决少量用户的低频问题<br>
开发难度和效果
优先见效快且开发难度小的，迭代
最后做见效慢开发难度大的，未来的机会
产品价值
迫切程度：用户是不是真的非常需要？
付费意愿：用户是否会为了解决问题而付费？
ARPU：用户会为了解决这个问题付多少费用
目标用户群体的熟悉群体
是否深入了解用户使用场景
对用户群体的理解是否足够了解
总结
用户：核心用户是谁
场景：用户在什么场景下使用这个
问题：能否解决用户的痛点
对比（产品以上线）：跟现在的方案对比，体验、效率有多大提升
竞品分析报告
方法论
SWOT
优势
劣势
机会
威胁
核心：竞品分析只做参考，每个产品的核心功能不同、商业模式不同，不要被竞品所误导。<br>
需求评审
目的
1.跟各方确认项目方案认知，促进协作统一作战。<br>
2.通过会议群策群力，查漏补缺。<br>
会议原则：
1.问题解决在会前，前置预警，有预案。<br>
2.好的意见要记录，会后要整理吸收。
会前准备
确认文档、原型是否完成。是否发送给与会人员。
提前找核心人员沟通，提前消灭大问题，与各方达成初步一致。
与与会人员确认会议时间。
预约会议室，提前发出会议邀请。
带上文档、原型等文件。
根据对相关资料的熟练度，提前演练一次甚至多次。<br>
如遇突发情况会议时间变更，及早通知与会人员。
开会现场
注意事项
不要上来就讲功能。
细节上不要争论。
控制节奏，条理清晰。
记录争论点
流程
1.需求背景
2.用户与需求
3.业务流程
4.功能模块
5.原型交互<br>
6数据指标<br>
7.需要资源
8.预计上线时间
会后
整理会议记录，记录变更；追排期。<br>
整理遗留问题，拿出解决方案。
发出修改后的需求文档。
如果需要约下次评审会议时间。<br>
项目实施阶段
原型设计<br>
工具
Axure
摹客
Xmind
Visio
processon
输出物
流程图
作用
梳理流程
查漏补缺
高效沟通
注意事项
方向
从左至右
从上至下
连接线尽量不要交叉
原型图+PRD
文本框
用途：用户输入内容
限制
输入类型
文本
数字
长度规则
特殊情况
eg:登陆界面的用户名是否显示上次登陆账户
操作提醒
交互
焦点获取
（移动端）输入键盘调用
按钮（图标、面板）
用途：与用户交互，数据传输、达成目的<br>
限制
交互
Loading样式
成功样式
文本标签
加载失败
失败提示
40X 服务器问题
50X 网络问题
返回前一页面
研发阶段
临时需求
定义：在原版本功能需求确定后临时添加的需求统称为临时需求。
类型
缺陷型需求 为了解决现有功能缺陷的需求。
1.判断是否会影响版本上线
2.判断是否有Plan B
3.在原有的资源下，研发加班能否完成
4.能否借用资源，增加人手。
5.是否能砍掉别的需求
6.项目延期
强化型需求 完善现有功能，提升用户体验。
一个原则：当前版本不处理，跟需求方沟通清除后续应对方案，并且达成双方认可的目标，
两个方式
1:如果该需求对用户体验改善较大，在后续版本中进行迭代。
2.如果该需求对用户体验影响较小，砍掉需求，当然还是要用比较柔和的方式进行沟通。
独立性需求 在现有的业务体系之外，新增一个耦合度较低的功能。
1.如果当前业务处于开发阶段，跟需求方沟通，避免影响上线进度。
2.如果当前业务处于使用阶段，并且可以丰富业务，大大提高用户体验，可以将需求放入需求池，和现有需求一起进行优先级排期，在未来的版本中实现。
测试阶段
上线后
上线阶段
上线邮件
什么是上线邮件：上线后一段时间（3-5天具体根据团队实际情况），由项目负责人发给相关同事的通报邮件，主要描述研发过程和上线结果的邮件。<br>
为什么要写
总结与记录：未来翻查资料速度更快。
项目推动:上线才是开始，需要推送，协调各方资源。
团队润滑剂：给与参与者、帮助者正向回应。
怎么写
标题直白：标题简单明了说明项目内容。产品+版本+卖点+动作 eg:xxx 1.0上线了，更新留言功能，邀请大家测试。
内容清晰
有背景
为什么要做这个版本、功能
有过程
简要描述一下研发过程，是否按时上线，是否有加班，有没有碰到说明问题
有功能清单
这一次上了哪些功能
数据对比如何
上线前后的数据对比
有后续计划
是否需要同事支持
提前准备好素材和资料，提时间和要求。<br>
求测试，则附上测试账号和收集渠道。
求推广，则附上相应的位置、文案。
求销售，准备好材料和宣讲会时间。
表扬有技巧
说案例
谁，给你提供了什么帮助
谁，在研发过程中，有哪些事情让你很“感动”
从谁身上，学习到了什么东西
复盘阶段
回顾目标、结果对比
回顾需求目标和设计逻辑
目标和意图是什么
设定的项目目标是什么?
指定的计划是怎么样的？
设定的流程走向是什么样的
需求合理性
与短期目标或者长期目标重合度有多高
未来是否需要投入资源
目标与结果的对比
目标完成度对比
业务数据评估，从数据倒查问题
叙述过程、全面刨析
数据展示与分析：业务指标、ROI
项目流程是否可以整合、调整、优化
反思是哪个点出现问题
成员提问、复盘归档
多方提问，突破个人局限。
优秀结论归档
0 条评论
下一页
为你推荐
查看更多
