导图社区 产品经理工作流程(全面)
产品经理接到产品需求后先进行产品市场调研,围绕产品背景、痛点问题,以用户为核心,重点关注用户存在什么不能忍受的且持续反复出现的问题。梳理自己刚刚从事产品经理时的工作流程,全面细致,阅读后你会很快明确了自己在产品岗位上的职责
提示: 本内容由社区用户上传并分享。平台不对内容的真实性、合法性、知识产权归属及是否侵害第三方权利进行事前审核或保证。本内容可能包含受版权保护的图片、字体或其他第三方素材,使用前请自行确认授权范围。
如果你要运营抖音短视频,先搞懂这些个专业名词,这里整理了所有的基础定义,建议收藏阅读。
着这写步骤,你会渐渐懂得抖音的算法,增加你账号的权重,提高你视频被平台推荐的概率。总而言之,孵化一个成熟的抖音账号,就得先有前期的准备。就算是一个粉丝量很多的账号,违规了也需要再养号。我就是希望大家不要忽略养号的重要性,也不要疏忽后期的培养,要学会运用平台的规则,而不是被规则束缚手脚。
看了很多抖音运营知识,但自己作为新手真正操作时会遇到各种各样的问题,这里整理了所有抖音新手常遇到的问题答疑,都给出答案,不做无头苍蝇。
社区模板帮助中心,点此进入>>
论语孔子简单思维导图
《傅雷家书》思维导图
《童年》读书笔记
《茶馆》思维导图
《朝花夕拾》篇目思维导图
《昆虫记》思维导图
《安徒生童话》思维导图
《鲁滨逊漂流记》读书笔记
《这样读书就够了》读书笔记
妈妈必读:一张0-1岁孩子认知发展的精确时间表
产品经理工作流程(全面)
一、产品设计阶段
一、产品概念讨论
#立项
输入
原始业务需求
规划类需求
自提自解决需求
参与人员
产品经理
一级中心负责人或二级中心负责人
产品总监、设计总监、技术总监、架构师、UED负责人、
业务负责人
关键内容
概念设计目标
使用场景
服务对象
业务流程
产品量化目标
核心运营指标
关键任务
产品经理和一级中心负责人或二级中心负责人或产品总监面对面讨论产品目标、方向、范围和基本产品雏形设计
产品经理无需呈现文档,现场口头讲述,结合板书用图文形式辅助自己的表达,将产品思路表达清楚
输出
同意立项,并确定项目级别为集团级或中心一级或中心二级,最终体现在《项目过程确认单》中
确定项目范围、相关干系人,关键里程碑评审级别,明确评审组成员
关键里程碑评审级别确定后,后续的评审专家中必须包含当前级别的专家,可以邀请高评审级别的专家参与评审
产品经理以邮件形式发出产品概念讨论会议纪要,告知相关干系人,抄送一级中心负责人、PMO、QA,并体现上述两点内容
关键点
概念讨论可以多次
项目立项的条件
产品概念讨论完成
二、产品高阶设计及评审
#高阶评审
讨论通过的产品概念
一级中心负责人、二级中心负责人
产品总监、技术总监、架构师、测试负责人、UED、数据部门产品经理、
线框图
核心业务逻辑(考虑原有逻辑)
数据概念模型(E-R图)
提供了表示实体类型、属性和联系的方法,用来描述现实世界的概念模型
实体在E-R图中用矩形表示,矩形框内写明实体名;比如学生张三、学生李四都是实体。
属性在E-R图中用椭圆形表示,并用无向边将其与相应的实体连接起来;比如学生的姓名、学号、性别、都是属性。
联系在E-R图中用菱形表示,菱形框内写明联系名,并用无向边分别与有关实体连接起来,同时在无向边旁标上联系的类型(1 : 1,1 : n或m : n)。比如老师给学生授课存在授课关系,学生选课存在选课关系。
产品经理对产品进行方案设计并组织评审
输出物
产品设计方案
输出标准
产品设计方案开展专家评审,并确定后续各阶段的评审级别和内容(如果涉及到核心产品逻辑、系统逻辑、关键界面),且评审通过
评审通过邮件及时发出周知所有干系人,参与高阶设计评审专家执行线下签字流程
产品高阶评审通过之后,产品经理应立即组织产品、开发、测试、UED、数据部门产品经理、业务负责人、具体执行人员来宣讲产品的高阶设计;
产品经理可以协调技术总监共同分析
二、产品高阶宣讲
产品经理对产品进行方案设计并组织宣讲
产品高阶评审通过之后,产品经理应立即组织产品、开发、测试、UED、数据部门产品经理、业务负责人、具体执行人员来宣讲产品的高阶设计
三、产品详细设计及评审
#PRD评审
评审通过的产品高阶设计
产品总监、技术总监、敏捷组长/梯队leader、架构师、测试负责人、UED、数据部门产品经理、数据部门技术经理、
#包括但不限于
原型图
交互流程
取值逻辑
业务规则
各类状态
提示信息
产品运营指标的算法及监控手段
埋点定义(包括数据埋点和UOM业务异常埋点)
产品经理对产品进行详细设计,输出PRD及用户故事(敏捷模式)
PRD
用户故事(敏捷模式)
产品PRD(根据产品特征,可以是Word或axure文档格式)
埋点文档(PC和APP)
用户故事列表(敏捷模式)
产品详细设计中需考虑新老版本的功能和数据兼容,及对周边产品产生的影响;
产品PRD需要组织产品总监、技术总监、测试经理、UED、数据部门产品经理、数据部门技术经理进行评审,并执行线下签字流程;
产品界面、逻辑在过程中倘若必须执行大的变更,需要组织产品总监、技术总监评审,评审通过方可执行变更,并发送变更邮件告知相关干系人;
产品需要在PRD文档中明确后台菜单权限及角色逻辑(若涉及后台权限);
UOM 基本原则:
异常提示语的地方都要需要UOM业务埋点
异常不给提示语使用默认方式处理都需要UOM业务埋点
涉及到用户故事相关内容都为敏捷模式
四、产品PRD宣讲
产品PRD文档
敏捷组长/梯队leader
参与开发人员、测试人员、UED人员、周报相关系统的产品和开发、产品总监(可选)和技术总监(可选)、业务负责人(可选)
产品经理将产品需求文档、用户故事与项目组成员、各个专家进行宣讲
产品PRD及用户故事得到参与人的确认,项目组各个角色成员都无疑问,以邮件形式发出产品宣讲的PRD文档、用户故事列表,并归档于SVN/wiki文档库
五、产品数据分析
产品交付使用
产品经理对已交付的产品进行数据分析,作为结项的依据
《数据分析报告》经过一级中心负责人评审通过,并归档于SVN/wiki文档库
产品数据分析工作是一个持续的过程,项目结项后,产品经理仍需定期输出《数据分析报告》,并由产品部门负责人在二级中心数据例会上进行数据汇报