快生活 - 生活常识大全

我们拥有强大的技术团队但却把产品做砸了


  和很多产品经理不同,我有一支强大的技术团队。我不需要像其他产品经理那样跪求开发去实现需求,也不需要陪吃陪喝第三下四。在团队中,我是当之无愧的和技术老大平起平坐的角色。可是,我仍然做坏了一个前途大好的产品,这究竟是因为什么?
  2014年底,我进入V公司开始做产品,可以和业内享有声誉的技术团队合作,对我来说是一个不可多得的契机,即使在当时我也这么认为。为了能快速上手业务,开始狂啃业务流程设计,希望尽快摆脱C端产品经理流于表面的坏习气而尽早进入B端产品的角色,于是,一段过犹不及的旅程开始了。
  产品究竟是为谁做的
  我一直以为产品是为直接使用者做的,因此处心积虑的考虑怎样能让他们在使用时得到最大的方便。比如流程尽可能做短,尽量设计工具帮助用户填写表单等。现在发现,大多数此类功能都是过度设计。道理很简单,B端产品的使用者虽然是一线员工在操作,但是这些操作流程都是要给他们的老板看的,购买产品的单也是老板买;因此,怎样让老板通过这个产品更好的监控他们的员工是怎样工作的,其意义远大于让员工更舒服的工作。
  显然,作为产品经理,需求都是我自己定的,越强大的团队,越能把这些功能快速实现出来,然而,他们越快速,产品也就可能砸的越快。
  到底要不要做那么灵活
  V公司是一个技术气息浓郁的公司,言必称系统可"灵活配置"。当时觉得牛逼透顶,什么业务都能抽象到如此程度,简直是上帝的逻辑。于是,在互金业务上,我也开始尽量抽象业务。为了抽象业务,我基本上把金融产品分析到自己知识能涵盖的所有疆域,希望抽象出一个大而化之的业务模型,适配所有金融产品,用一个通用模版实现各类型金融产品的生命周期管理,销售模型管理,持有人管理,违约管理,头寸管理,支付渠道管理。当时热情殊为炽盛,但是越设计越发现,字段表术语表内容越来越多,模版要包含的内容越来越多,最后,把自己给整傻了。
  糟糕的是,在我的错误思潮带领下,强大的技术团队也投入到轰轰烈烈的抽象事业中,希望一口气造个航空母舰。
  我想跟技术团队和测试团队说声对不起,如果我能不那么自以为是,把自己当上帝,也许我们的产品早就出来了,我们也不会在年底集体遭到老板的责难,最后走到集体崩盘的状态。
  作为产品经理,我不应该盲目听信老板所说的"先不急上线",就觉得有足够时间去抽象一个完美的产品。老板的想法随时可能根据市场的变化,摇身一变成为"怎么还不上线?"到那个时候,整个团队的主动性就已经完全丧失了。主动承担更多市场分析工作,根据自己对市场的判断来调整版本计划,才是应有的大产品思维。
  不配合BD是什么心态
  团队中,产品和研发都是擅长逻辑思考的动物,不难形成共同语言。而BD是另一种动物。过去我很不喜欢听他们说"你去忽悠他们一下啊","你去用你的专业知识吓唬他们一下啊",或者"你就说我们有这个功能嘛"。现在回忆起来,这的确是一种不成熟的想法。
  一个人,既然追求俗世意义上的成功(即实现财务自由),就要按照俗世的规则去做一些事情,这是必要的代价。在任何时候都清高,只能证明自己的愚蠢。即使BD的语言方式在我的逻辑中是不严谨的,我都应该自带编译功能,用我自己可接受的方式,尽可能配合BD同事的工作,有可能并不是去"忽悠"客户,或者"说我们有这个功能",但是,只要能使用自己的专业能力有效帮助商务拓展工作,配合的工作也应该算完成的不错。
  然而在那个时候,我通常会一个白眼翻过去,"叫我去忽悠?你以为我是你哪!"
  是的,整整一车开发,很大程度上由于我的原因,被带沟里去了。不幸中的万幸的是,由于我不是唯一责任人,他们并不恨我。
  更多更细节的问题,大多是围绕着"这个功能究竟有没有必要现在做"这件事展开的。从沟里爬出来之后,我得到的最大的教训就是:除非有特别确实的迹象证明这个功能要做,其余一律不做。
网站目录投稿:怜珍