几乎所有的公司都会有这样的问题,这种现象已经渐渐成为了互联网公司的一种常规病,那么这样的产品流程问题如何解决呢?
之前John写过
《你凭什么能做产品经理?
》
,今天John也想结合产品经理工作流一起来聊下。
我需要一个什么样的工具,来满足我要做什么的诉求?
所以在John看来可以总结一个公式来拆分下:
-
满足谁的需要?
—-辐射的用户群体;
-
他们有些什么需要?—-用户需求;
-
我们提供的是否满足需要?—-能否解决用户痛点;
-
这些需要如何有效实现?—-具体实现方案。
而是真真实实的落实到业务的根上。
做好产品规划有几个好处:
清晰的产品线规划,可以让一个企业保持无比清晰的头脑。
除了在攻打市场的时候,有的放矢,还可以让在竞争的时候,保持自己的节奏,攻防自如。
很多企业,尤其是行业老大,因为不清楚的自己的产品组合,没有清晰的产品策略,总是被行业老二,或者是市场新的竞争对手带偏。
让团队可以明确在不同的阶段需要做什么,暂时不需要做什么,以及在什么时间段该做什么;
在某些公司产品线众多,梳理产品规划更主要的是资源的协调。
即明确分配资源,包括人力资源、开发资源以及运营资源等;
依托于产品业务的模型。
产品生命周期一般是四个阶段:
孕育期(种子期)、成长期、成熟期和衰退期。
不同产品依托于不同的业务模型更新换代的速度或长或短都会产生不一样的效果,所以目的就是为了在不同的阶段合理分配好时间选择,达到产品在周期中的健壮性;
《一文理清产品规划究竟怎么做(内附案例剖析)》
,也可以去看看。
哪怕你的竞品和你的用户量不是一个级别,利润是竞品的几十倍,也得去研究研究。
毕竟蚊子也是肉嘛。
分析竞品有几个重要的点:
为什么竞品在这个版本做这个内容?他的产品路线图为什么这么走?(结合所处市场来分析,会更加清晰)
清晰的描绘历史版本路线图,更好追根溯源达到快速梳理清楚业务并了解产品目前“优势”、“劣势”、“机会”和“威胁”(SWOT分析法)。
当然最后别忘记输出业务需求了。
分析业务需求的时候,可以通过流程管理六要素进行分析:
输入、输出、活动、关系、客户、价值。
从业务角度来说指的是业务流程输入跑起来所必须的资源。
也是流程启动的触发原因。
指的是流程完毕后所得到的产物,整个业务流程流转到最后的产出。
指的是业务流程流转的过程中各个环节,如何有机的调动整个业务流程运作起来的核心关键点。
指的是各个环节即上述的活动直接的联系,以及相互承载使整个业务流程可以串起来的节点。
指的是流程服务的对象。
指的是这一套业务流程跑完后,得到了什么,有什么意义,同时这也是为什么要有这么一套流程的意义所在。
为一组存在相互“关系”的“活动”将“输入”转化成为对“客户”有“价值”的“输出”的工作。
产品经理规划产品之了解业务
》,可以去看看案例分析。
当然和业务同事更多的沟通是一定的。
有的小伙伴就说:
我都懂这些,但是还是不了解。
听John一句劝:
对业务不熟的产品经理,充其量只是原型仔。
推荐体系来聊聊
毕竟互联网产品讲究小步快跑,快速验证迭代,怎么样权衡产品设计(用户体验),技术成本以及商业利益是产品经理主要工作之一。
产品经理如何避免需求评审会背锅?
但是需要实时的和技术去沟通反馈。
跟进项目管理。
所以严格把关很重要。
测试一般针对于产品功能测和性能测。
针对于功能测试会具体分为常规流程测试和边界测试。
John之前其实写了
《不吹不擂,产品自查表看完这篇就够了》
,帮助了至少几十位产品经理找到了处理边界逻辑的方法。
但是作为产品经理,对应的功能测试肯定需要去了解下。
具体的字段:
-
序号:
不用说,就是按顺序下去的。
-
模块:
该功能点具体属于哪个模块的,填写这个主要是方便查找,如:
注册/登录模块。
-
编号:
对每个用例进行编号,方便后期跟进。
毕竟用文字说,容易口误。
不过此处建议编号设计的有点规则,方便快速定位查找。
如:
A0001。
其中A表示注册/登录模块。
00表示账号登录,01 表示账号密码登录下的第一个测试用例。
-
功能点:
具体指某个功能,如:
账号登录、首页、发布等。
-
子功能点:
具体指功能点,如:
账号密码登录、手机验证码登录、邮箱登录、第三方授权登录等。
-
用例名称:
具体测试用例的名称。
如:
输入账号、输入密码、密码不合规等等。
-
前置条件:
指要达到预期测试结果,需要满足那些条件才能达到。
如:
账号密码不一致时,就需要登录失败,那么此时就得保
-
证账号正确或密码正确以及账号正确时是存在的。
-
操作步骤:
指要达到预期测试结果,需要按这些步骤来。
最好说明在什么页面,点击或操作什么内容,输入什么内容。
-
预期结果:
说明按照前面写的应该呈现出怎样的结果。
-
测试结果:
如果符合预期结果,直接填写正常或OK,如果不符合,则说明不符合或NO。
-
结果描述:
如果正常,可以不用填写,如果不符合预期结果,则说明哪里不符合。
-
测试人员:
填写测试人的名字,方便后期跟踪BUG。
-
测试日期:
填写测试的时间,方便后期查询。
-
BUGID:
跟测试编号一样,自己设定ID规则,方便快速查询。
-
BUG负责人:
此处应该有技术那边填写,具体落实到某个人身上,才能更好的解决到问题。
John之前也写过数据分析的方法——
产品经理工作流之数据分析全阶段(附电商统计)
。
其实工作流不复杂,复杂的是和项目组其他成员的沟通总结和思考。
做产品经理真的挺难的。
不是什么人都能做的。
记住,所有的内容都必须要落地。
因为落地会立足根本。
“在看”
吧。写文不易。
声明:
本文采用
BY-NC-SA
协议进行授权,如无注明均为原创,转载请注明转自
大白PM
本文地址: 一文详解产品经理工作流程
本文地址: 一文详解产品经理工作流程