1. 主页 > 网络营销 >

B端产品推进过程中的项目管理思考

在产品推进过程中,遇见太多太多的大规划,但这些,在具体产品迭代过程中,用于限定需求范围可行,规划与实际计划不符却不可取。成熟的产品迭代团队,每一期迭代一般会有相对固定的周期。尊重时间周期和需求范围,做好当期需要实现的内容,不过于蔓延需求,机动时间合理,方可称不负韶光。

B端产品推进过程中的项目管理思考

做B端产品的痛与苦

如果你跟一个负责B端产品的朋友喝下午茶的时候,他不小心走神了,请你大方的原谅他吧。

哪怕他人在你面前,他的脑子里与跟你唠嗑同时并行的事情,可能不下10项:

嗯,对面这人在问我奶茶好不好喝,咦,怎么又说到了熔断,熔断是啥?

后天这个产品版本上线,还有5个重要bug得改,不然不能上线。

下个版本里得做20个需求,数据权限下沉得涉及多个部门,该怎么推进呢?

某服务的供应商不是说今天上线这个功能嘛,都这个点了还不通知我们准备,今天还能上线吗?

完了,A项目和B项目会议时间冲突了,怎么办?

C项目好像也要上线了,当时的需求是什么来着?

有个研发资源好像要被释放了,好几个产品线和项目在争抢,怎么才能让他来我们团队呢。

……

焦虑啊~

有人感叹,我有丰富的理论知识和实践经验,在做下一个项目的时候,怎么还是不敢保证成功呢?

是呀,项目如流水,哪怕看上去很相似,下一个也不是这一个。知识和经验可做参考,却没法照本宣科。

没头绪啊~

不过有丰富的知识和经验,整个团队又身心投入地为产品和项目的推进付出的话,成功概率总会高些。

读过国内国外的产品项目书籍并做过对比的朋友应该能够感觉到,国内讲产品或项目的时候,会偏向于抽象理论、拔高高度,比如著名的产品人梁宁老师会讲“宏观视野、中观套路、微观体感”,QQ之父马化腾会讲“Don’t Make Me Think”;而国外讲产品或项目的时候,会把一句话,写成一本书。

“Don’t Make Me Think”这句话,在国外的书里会写的时候,光目录可能就有下边这么多:

产品体验的最高境界是,用户不需要思考就能知道下一步怎么做;

为了实现这一点,作为某某某角色,要在第一步第二步第n步做到这个那个另一个;

实现了这些,基本能将产品体验做到多少分;

某一步没实现,会将产品体验降低多少分;

针对什么样的产品,可以应用哪些步骤来执行;

吧啦吧啦吧啦……

一个说的那么多,一个说的那么少,到底怎么实践啊~

解决B端产品推进的痛点

上边赘述的篇幅有点多,实在是亲身感受,痛之又痛,没忍住就唠叨多了。

汇总下做B端产品的痛点:

B端产品业务复杂、定制化高,同阶段并行的产品和项目可能有很多个,资源有限的情况下,资源该怎么分配,产品该如何迭代?

项目管理过程中,进度、质量该怎么把控,已实现功能该怎么复用在其他项目中?

产品和项目上的知识和经验,怎么才能更好地体现在产品中?

在B端产品推进的过程中,大大小小的问题多到数不胜数,要行之有效的解决问题,还是需要知识和经验的积累和传递。

在推进产品进展的过程中,是有规则可遵循的,可总结为:识别相关方、主动学习、尊重流程、明确优先级

在产品经理基本素养过关的情况下,将上述4点把控到位,产品推进中可能遇到的可预知或不可预知的问题,在解决的过程中,方向和边界基本可以保证不会偏离。

(1)识别相关方

个人认为这是最重要的一点,识别错相关方,所有努力都白费。

(2)主动学习

产品经理往往承担产品推进和项目管理等多方面的工作,主动学习各方面的知识是必要的。

了解与你沟通的人希望在你这里获得什么帮助并表述清楚,是很重要的一种能力。

一些做B端产品的公司,会拿业务领域的经验作为门槛设置招聘要求,想要进入B端发展的产品经理们,也常常因为业务知识及经验的不足望而却步。但实际上,业务知识及经验诚然重要,更重要的却是快速并合理使用业务知识及经验的能力。

(3)尊重流程

尊重流程,包括尊重流程中的人、组织以及流程本身的知识项,共同遵守规则,才能有效的保质保量完成任务。

每个公司,都有自己的项目管理或产品管理流程,这些流程,是公司团队间长时间磨合一点点积累下来的财富。

本文由摸索网(http://www.lnmosuo.com)发布,不代表摸索网立场,转载联系作者并注明出处:

联系我们

工作日:9:30-18:30,节假日休息