产品经理-Timekr

聚集于“如何”做产品,而非“产品经理”本身

基本上多数论坛说教都在讲如何做产品经理,成为产品经理的方法等诸如此类的观点,但真正讲到其核心的是非常之少,也时常局限在title本身,对于大多数没有判断力的用户来说,完全是误导,抛开实际的产品、业务、逻辑、市场去谈如何做产品经理完全是耍流氓,鸡血类的文章看看就得了。

衍生的例子也诸如“如何做一个优秀的CEO,实际上真正优秀的CEO考虑的都是如何做好公司。也就说想做好某个具体的职位,那么应该以职位范畴的项目为出发点,而非停留在title本身,毕竟过于理论化的东西只是基本的层面,也并非按部就班,下面进入主题。

现在所存活的优秀产品,基本都建立在良好的业务规范、解决问题的需求、优秀的用户体验、强大的运营手段等综合因素。也存在大量的死掉的产品,但这也不足以表明背后的策划者就是没水平的,毕竟不确定因素太多。

对于产品经理本身而言,每个阶段都有其重点的目标去实施,但有两个基础的点是必不可少的:对需求的把控以及业务的深入理解。前者为策划的来源,后者为策划的实施,相辅相成。


对需求的把控:

每个项目策划的背后都有一个需求池,如果没有,请完善建立。需求池基本会融入不同角色(运营、市场、用户、老板等)的产品需求,那么在每个迭代节点具体做哪些方案就取决于其优先级,这种优先级完全是根据状况分析而来,而并非某个角度或产品经理本身直接判断所得。

说白了,就是如何说服团队成员去做这个功能,这个迭代方案。可能很多产品经理考虑自己本身就是策划者,认为无需被干涉,但这种想法基本是比较极端的。就像建筑师一样,如果没有说服为什么要如何这样的方案,那么基本上相互之间很难理解,甚至可能怨声不断,盖不好一座房子。

但考虑到没有不可能满足所有人的观点、需求,因为作为产品经理而言,至少要进行迭代方案的缘由阐述,让大家理解即可。

对于杂乱的需求池,如何筛选需求?有个实操的方式:

1.将本次迭代的外部需求+上次遗漏的需求整理成列表;

2.对每个需求进行需求来源、需求场景、需求解决的问题重点分析说明;

3.根据分析所得,进行优先级的排列,并进行简要说明;

这样好处是对每个需求都有仔细的判断与分析,同时又保证各个来源需求的完善处理。


对业务的理解:

一旦本次迭代的需求确定了,那么对业务的理解能力就需要足够到位。假如把迭代的方案比作“人体”的话,那么从骨架到造型、从细胞到血液,精确到最小颗粒度,产品经理也能完全讲明白任何细节性的功能,同时对整体的扩展牵连又需具备良好的囊括意识。

如果在策划阶段,产品经理出现细节性的差错或遗漏的地方,那么补“坑”是件很麻烦的事情,策划后与设计、技术的对接出现问题,十有八九是业务出现问题。

不要遗漏需求,不要出现业务混乱,不要没考虑好就进入迭代开发。对业务理解的越透彻,进度与质量越顺畅。

对于不同形式的业务来说,如何保证基本的规范?

1.整理每期迭代的所有功能逻辑;

2.梳理每个功能涉及的元素、事件、交互方式;

3.进行关联业务与扩展的说明。

一个简洁而见效的方式是:以用户实操的角度,从头到尾走完迭代的所有业务,使用完所有的功能,这自然会发现很多业务问题。


上面所谈的“做”产品只是其中的几个点,目的只是让大家多去想想产品业务本身,而且只是盯着“title”去看,而真正的产品从01会涉及非常多的事物。

基本上你懂得如何“做”产品,也就明白如何做产品经理,title真的没想象的重要,好比历史的将军,优秀只会注重如何打好每次战役,而非如何一味学习如何做好将军。


Timekr”文章均为一线原创,禁止转载、摘录等,尊重原创,阅读价值信息。

— 于 共写了1459个字
— 文内使用到的标签:

一条回应:“聚集于“如何”做产品,而非“产品经理”本身”

  1. Testing说道:

    感受同身,产品策划的重要性大于职位。