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