为什么我厌倦了产品研发(2B)

这不是什么丧气的话，只是这条路暂时不太走得通罢了。从这有限的产品经历看起来，构建一个产品并不容易。

产品体系难以建立

彻彻底底的讲DMP的困难是体系建设的问题，以”研发”为核心的产品体系，制作出来的是一个易碎的瓷碗，看起来不错，但是使用的时候得护着它，不要让它碎掉。而一个完整的产品体系，从需求管理，产品研发，测试，产品交付，售前支持，售后支持，销售培训，乃至于文档管理都需要投入，而我们总是关注于 Make it，将这个东西做出来，仿佛事情已经完成了 80%，现在看起来做出来仅仅完成了任务的 20%，我们只是开始一段旅程。而在很多基于项目的产品线，产品经理的作用是与客户对接，交付工程师由开发兼职，测试已应付客户为主的模式下，产品又如何不脆。

技术产品

无论任何依然要认识到制作的并不是一个真正有门槛的技术产品，以前2C产品经理都会有一个问题，如果你们公司被腾讯抄袭，你们会怎么样？我们在做产品时候，也问问自己，你的技术门槛高到别人看了UI也不知道怎么抄袭吗？你的定位是什么？提供给客户一个技术组件还是一个行业经验？实则我们大部分的时候提供的都是一个看似技术产品的经验方案，我们试图用我们多年在行业浸淫的经验，将开源工具更好的组装在一起，以达成输出我们的技术理念，那此时我们提供的本质并不是技术本身，是我们的行业理解与运维经验等…… Wait，我并不是说这么做就是不对的，而是我们要明确我们究竟提供的是什么？如果是基于开源简单的封装，那我们应该在运维的经验铸造更高的城墙，如果我们是自研的，那我们可以更好的做好这个组件本身就是铸好这个坝。切莫调入 科技以换壳为本 为的陷阱之中，贸工技与技工贸 都可以的路径，只要认准的道路就要走下去，忌讳简单的封装 → 科技领先。

产品边界不清

相较于 2C 侧的技术，对于用户开放的是有限的，因此用户和产品的接线有着天然的隔离，当我们做一个 2B 的产品，我们面领着对接客户的应用等可能性，此时应用的问题会蔓延到产品上，也可以是因为产品的问题导致应用出现了问题，变成了你中有我，我中有你的相对局限，导致交付困难，运维困难，经常为了一些简单的事情投入大量的精力排查。这种边界不清也非常容易传到产品的其他部门。

弱产品的体系

产品部门的羸弱是有多个原因的 产品形态由研发主导，这因为’2 和另外一个原因导致。另外原因是什么？因为产品经理并没有很强的产品理解，这并怪产品，从DMP的角度，微服务治理是一个有技术提出的理念，在设立之初没有可以值得参照的竞品，我们从技术组件里面归纳总结出来的部分变成了产品的功能，我认为产品经理是值得培养的，需要2-3年的时间可能我们才能将产品这株花种植成功。

回报周期长

如果真的说做产品，我觉得2年是没有什么声音的，这2年内需要自己找客户不断的磨炼产品，控制好节奏（这个很重要）。尤其是在 2B 行业中，我们不得不去在一个较长的反馈周期内去制造一个产品。

---

我们真的需要客户提供一个产品吗？我也常常问自己，大部分的客户好像不是需要这么个产品，产品的诸多功能都留给控标性，简单的封装一下，按照项目的模式将其输入并且快速的结项，难道就不香嘛。