算是近期轻咨询服务的一些记录。
所谓乙方产品经理转型甲方，在一个大组织内，也可以说是交付型产品经理转向创新型产品经理。
发起方嘛，通常是自上而下。而老板心里的话，乔老帮主已经做了最好的嘴替，如下。其实，图里的engineers换成任何岗位都同理。
注：首先，现有团队是为了交付搭建的，人员能力也与之匹配，是否能转过去，本身就值得讨论。可能有很多人会认为，重新招募、搭建创新产品团队才更靠谱。当然，这两个选项也并不是非零即一，这篇不讨论这个，只聊聊转型会碰到的问题。
当一个交付团队开始做创新项目，马上会碰到的问题就是似乎没有时间精力投入。因为各种“需求方”并不会因为某老板的想法而马上停止提需求，而习惯了被动接需求做产品的团队，也一定会被动地把时间排得满满的。
但这种被动的工作模式必须改，既然成立了创新产品的项目组，就意味着高层希望团队做出一些主动的创新，也可以容忍一些交付产品的优先级降低，所以，团队的意识要变，意愿要有，如果你觉得被动接需求也挺好，那就专心做交付，去问问公司，应该也有需要。
团队的思路应该做个转变，不是“如此忙的现状导致我们很难创新”，而是——如果要创新，需要什么支持，需要什么资源，如果我们能证明“我想做的，比现在接的需求更有价值”，我相信是可以向老板申请更多资源的，现在机会给到大家，能不能抓住其实看自己。
当然，老板要做的，是真心想要创新，要有条件地给机会和资源。
对于工作模式改变，有一个实际的阻碍需要老板们讨论，就是产品经理们的考核，如果只考核他们“完成度、质量”这类指标，可能无法触动他们真的去探索尝试，所以，建议可以把这部分加到考核中去，哪怕是后置的。
转型期间，会有一系列之前做交付产品留下的小习惯，变得不合理。
比如，过去的交付项目，并不对数据负责，甚至都看不到完整的业务数据。但做创新产品，就必须关注数据，对自己所负责产品的关键数据，要建立起数据报告的机制。
又如，文档管理模式，交付型产品经常采取“接力跑”模式，一关一关的评审。而创新产品更适合建立共享的在线文档空间，便于信息共享，让团队各人从头到尾都可以方便协作。
再如，需求的获得，交付型项目通常是和甲方开会得来的，团队并不会直接去见用户。但创新产品必须主动去调研，走出办公室，到“田间地头”，这种看起来没什么“交付产出”的工作反而是最重要的。
……
以上，有个客户总结得挺好，希望产品部门可以完成三步走，依次做到业务方的满足者、合作者、引领者。
时间周期么，还是那句话，三五年打底。
相关内容，还可以参考如下几篇旧文：
再谈企业内的乙方（科技部），如何和平演变，翻身做主人（2022）
_________
苏杰（iamsujie），产品创新顾问，《人人都是产品经理》系列4本书的作者，前阿里8年产品经理，集团产品大学负责人，良仓孵化器创始合伙人。如需产品经理/产品思维/产品创新相关领域的培训咨询服务，欢迎联系这个微信（13758212411）。
原文作者：iamsujie；如有侵权，请联系管理员删除。
