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

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