企业需要的是增长型IT专家，而不是产品经理

2025-09-05 08:54:28 · PM杨堃 · 杨堃

关注

这两年，越来越多的公司IT团队进行产品化转型，设立产品经理岗位，希望IT系统能够以产品化的运作方式，更好的参与、赋能业务。我服务过的众多公司中，产品经理岗位的设立，有着各种各样的方式。

这两年，越来越多的公司IT团队进行产品化转型，设立产品经理岗位，希望IT系统能够以产品化的运作方式，更好的参与、赋能业务。

我服务过的众多公司中，产品经理岗位的设立，有着各种各样的方式。

例如：

1、需求分析部直接改名产品部，需求分析师直接改名产品经理；

2、需求分析部和产品部并列，对前者的定位是协助产品岗位做软件需求设计；

3、如果没有需求管理部，则将项目经理等岗位转制产品经理；

4、保留所有之前团队和岗位，直接从互联网公司招聘产品经理；

不论方式如何，管理机制如何，企业CIO和数字化负责人的诉求很明确：以前IT团队做系统都是做项目，只负责上线，不负责结果；希望吸取产品化运作模式的优势，让IT系统以产品的方式建设，最重要的是能交付价值，解决问题。

可以说，这是目前IT发展的趋势，也是企业对IT最新的期待和要求，出发点和改革模式没有问题，但过程中也可能存在一些误区和偏离。

首先，我们应该有一个基本认知：

甲方IT系统建设的目标，是服务业务，而非商业化售卖，这就决定了系统建设的过程、方法论、架构，和商业软件有本质区别：

自研系统建设的核心思路，是以最小的代价支持赋能业务；

商业化产品建设的核心思路，是以正确的架构设计，支持战略诉求下对目标客户群体痛点的解决。

我接触过一些负责人，一方面要求员工交付价值解决业务问题，一方面要求员工设计软件对外售卖，导致软件设计人员工作中非常困惑迷茫，不知道自己的定位和出发点到底是什么。

要知道，标准化产品建设，和个性化需求的满足，天然存在矛盾；不能既让员工设计一个灵活支持未来客户需求的商业化产品，又要求员工设计方案快速实现业务方独特需求避免对方投诉。

如果团队不能客观理解两者的区别，就会在产品化转型中让成员产生困惑；

我认为甲方IT产品化转型中几个典型的错误认知如下：

1、强调打磨迭代完美产品，偏离本质：

自研系统本质是支持业务的工具和手段之一，并且并非唯一手段；过度强调对产品的打磨，反而会让软件设计人员偏离工作重心，关心手头的系统设计的是不是像一个产品般“完美”，而非以最低成本解决问题。例如：过度的建模、抽象、组件化、灵活架构。

2、对员工安排聚焦产品，视野受限：

产品经理管理模式，更强调软件人员对独立产品的全生命周期负责；但说实话，自研系统并没有像商业化软件那样严格的生命周期管理要求。

如果自研系统产品经理过渡关心产品的演化，可能导致忽略业务全局的发展，甚至对业务的变化和不确定性产生抵触，从而错失对业务更积极的介入和影响。例如：某CRM产品经理，只负责线索管理系统的设计，但缺乏客户全生命周期管理的业务视角，对业务的理解片面。

3、要求员工考虑未来商业化，造成困惑：软件设计人员既要处理业务方个性化需求，又要考虑未来商业化的标准功能建设，这着实不太可能，不仅是研发资源无法支持，更重要的是对软件设计人员的专业能力要求也不同。

实际上，甲方企业更需要具备宽阔视角的业务型IT软件人才，而非聚焦于独立产品精确打磨的产品经理。

所谓业务型IT人才，是指对某个业务领域或主题有着深刻的理解认知，对相关软件产品解决方案有着深刻的理解和见解，能够针对公司战略经营发展的要求，设计合理的IT软件解决方案。

相对于做商业软件产品经理的专才，企业自研系统产品经理更应该是一个全才：

不一定最擅长软件抽象设计，但一定擅长用低成本方案解决问题；

不一定懂商业市场分析，但一定对业务领域的典型问题和解法如数家珍；

既要懂业务，又要懂系统；

既要懂企业整体经营运作模式，又要在某个专业领域具备扎实知识储备；

既要有主动发掘问题的自驱力，又要有协调资源达成结果的技巧和情商；

业务型IT专家，首先强调业务，其次才是IT；老司机都知道，做了十年以上IT，最后拼的都是业务知识积累。

写到这里，并不是否定现代企业IT团队的产品化转型和产品制建设，而是强调，在这个过程之中，不要忘记工作的本质：甲方IT借鉴的是产品化建设中，聚焦解决客户问题，以用户为中心，数据驱动，闭环迭代的理念，而不是把自研系统打磨成一个完美的“艺术品”。

阅读全文