2

我是如何在转岗2年内做到产品团队负责人的

 1 year ago
source link: https://www.woshipm.com/zhichang/5697099.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

许多同学在转岗之后会有些难以适从,那么如何在转岗期间更快适应以及取得好成绩?作者分享了他转岗之后的职业变化以及做到产品团队负责人的一些心得体会,希望对你有所启发。

2LDiJJjtGOsRWpxDIPr1.jpg

本文记叙了我在过去这两年职业上的变化和心得体会,对我自己是一个总结和反思,也希望能够给到在产品经理路上和想转产品经理岗位的朋友一些启发,能够了解产品经理发展之路。

转眼间,专职做产品经理也两年了,这两年经历了入门产品经理、高级产品经理、带领产品团队的快速成长。

一、入门产品经理

刚从开发转产品经理的时候,还是一个只会接需求,老板让干啥就干啥的执行者,一切以满足老板预期为目标,至于需求的合理性、ROI,都是老板在考虑,也多亏当时的老板们(CTO和技术VP)都是区块链行业创业多年的大佬,对于需求的真伪、价值都有清晰的判断,才让我拿着一句“老板说要做”成功推进需求落地。

后来在资深产品经理和老板们的指导下,开始明白用户需求并非都是要实现的真实需求。

  • 有些需求只是个别用户在社区里提出来的增强体验价值的需求,对于大部分用户而言无关痛痒;
  • 有些则是天马行空的需求,或许能实现,但是实现的代价很高,带来的用户价值有限,商业价值就更不用说了,甚至为零;
  • 有些是和老板们相熟的客户提出的需求,但是拖一段时间后,就不再是需求了,作为一个长期使用的产品,为了几个人的短期需求,投入研发人力,最终也没有带来商业价值,显然是不合理的。

对于一个创业团队来说,性价比不高的需求,通常是需要放弃的,否则怎么熬过寒冬,迎来春天呢?

二、高级产品经理

在学会了产品经理需要掌握的核心能力–甄别需求的真伪、判断需求实现价值、输出需求文档之后,我到了现在所在公司做高级产品经理。在这里,一同共事的有数十名产品经理,大家有的负责一个片区交付,有的负责一个产品线,而我,因为有技术背景(全栈开发、架构师)、多年的区块链从业经验,以及必要的产品经理技能,成为了区块链产品线负责人,完全负责区块链产品线的所有产品工作。

在这里,技术的领导和产品的领导是分开的,如何推动研发将我的需求落地成了一个新的难题。

起初的时候,做一些小打小闹的需求,比如增加个新页面、调整一下审批流、规范一下文案和状态等等,都十分顺利,因为所有人都能看到修改的必要性和效果,改完之后的体验确实比之前好得多。

后来研发和交付都反馈,现在的区块链开放平台太难维护,权限管控很难做,希望我能主导一次重构。

于是我着手分析平台的全流程,将平台分为管理端和业务端,让资源申请和使用的操作全部放到业务端,让审核、全网监控的操作全部放到管理端,从而将两大主要角色的功能完全隔离,推出了开放平台4.0版本。该版本的架构设计让开发人员能够更加轻松地管理API权限和数据库表隔离,让交付团队能够更好地理解操作全流程,为客户配置所需的账号角色。该版本也成为历史上存在时间最长的版本,至少到现在一年多也没有再发生过大的改动。

然而,在需要研发新产品时,却遇到了些波折。

首先是研发A平台,这个平台属于区块链的一个典型应用产品,但是竞品的做法不一,有简单做的,也有做得很完善的,还有针对特定行业做的。在与研发团队负责人进行多次交流后,达成了一致意见是需要做,但是怎么做还是个问题。研发想用最小投入的方式,只做API,但我觉得只做API和没做是一样的,因为客户看不到,在ToG行业,客户看不到的东西就很难让客户购买,因为他看不到这个API,看不到使用的效果。

后来,在项目上发生了一件事,由于我们只提供了相关API,可视化界面完全由其他供应商提供,客户就把钱全部给了另一家供应商,让我们找那家供应商去收接口费。

这件事作为很好的一个证据,让研发信服,没有可视化的东西,客户是不会买账的,因为客户没有获得感,他也不知道买了这个东西到底有什么用,你得让他看到、感受到你的产品带来的效果,他才会愿意为你掏钱。就这样,A平台最终与研发团队负责人达成一致,投入研发,并在后来的项目中顺利交付,支持了多个场景接入,更重要的是,支持了产品报价。

在研发B平台的时候,由于技术侧的领导表态,没有项目需求的东西都不投入,B平台一度搁浅。直到在某项目有了B平台的需求,才同意进行研发投入,在该项目中B平台与A平台共同支撑了利润率可观的报价。

三、产品团队管理

由于成功实现了区块链产品和研发的拉通对齐,顺利落地了几个产品、几次需求迭代,产品线领导决定将区块链和大数据产品线合二为一,让我带领新的团队实现产品协同,对区块链和大数据进行整体规划,以获取更多商机,推动更多产品在项目中落地、沉淀。

带领团队,对我而言无疑是一个新的挑战:

  1. 一来我对大数据不甚了解,必须短时间内快速了解大数据,并对大数据产品线的现有产品熟悉;
  2. 二来原大数据产品线的负责人已经做了大数据产品线这么久,就这样被合并了,成为我的组员,难免出现心态调整的困难;
  3. 三来我在这的时间不算长,新团队的成员有的在这的时间比我长的多,甚至工作年限也远比我长,半数成员有约十年的工作经验;四来新团队有新招募的成员,我该如何做好新招募成员和原有成员的工作分工也是一项难题。

面对以上四大挑战,我做了针对性的解决方案如下:

  1. 阅读大数据相关书籍,包括数据产品经理、数据产品架构、数据治理、数字化转型等各类与大数据工作和产品相关书籍;
  2. 快速熟悉大数据产品线已有的资料,与相关负责人沟通,了解产品情况,并给与原产品线负责人充分的时间消化情绪;
  3. 虚心向经验丰富的同事多请教,在产品规划上充分咨询他们的建议和意见,发挥其专业才能,共同制定产品线发展规划;
  4. 召集组员会议,说明合并后的产品线发展计划,按照产品职责和模块,快速划分各成员负责的工作内容,并在组会上强调这只是目前这么分工,后续如果不合适,会再调整,并逐一询问建议和意见,让大家充分表达自己的看法。

最后,在我和团队成员的共同努力下,各商机项目和交付项目平滑有序地推进,并于团队合并后不到一个月,推动某省千万级预算额的大数据项目立项。

区块链和大数据产品线沉淀的标准产品方案、基线产品数量快速增长,在团队成员稳定后的一个月,完成大数据和区块链结合的大数据产品在部门内立项,作为事业部部长亲自指导的重点产品进行规划,区块链和大数据产品线很快成长为事业部最受关注的产品团队之一。

作者:zhili;公众号:智说新语

本文由 @zhili 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

给作者打赏,鼓励TA抓紧创作!

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK