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