文章来源：然阿姨的产品课（id：illusionland）作者：然阿姨

原文链接：后台产品经理量化产出真的这么难？

你好，我是九年产品经理然阿姨

前几天有个读者问我：

做后台产品经理的时候，怎么量化自己的产出？

哈，这就是问对人了。这个问题我曾经很疑惑，痛苦不已，经历了多番思考，终于渐渐的把它解开来了。

我也不止收到这一个提问。很多做后台产品的同学都有同样的感受：我做的功能上线了，运营或者销售用起来了，获得更多的用户，卖掉更多的东西……但是，好像这些动作我并不能直接干预。我在其中的价值是什么？如果定性的说，是从 0 到 1 让流程线上化了。那么定量的呢？我们的价值和业务指标怎么关联起来？比如用户增量、订单增量、GMV 增量，我们怎么才能直接影响它们？

如果后台产品经理直接能决定激励（预算）、订单、客户的分配机制，是有可能直接影响业绩指标的，比如一些策略型产品经理。但如果做的是业务流程系统功能设计，那么产品经理的定位，更接近于“ saas 开发者”，有时候还是定制版的 saas 。

咱们首先得真实面对。在《他说，大厂产品经理不是产品经理》一文中，前大厂产品经理/现独立创业者胡延瑞和我探讨了这个问题。大厂产品经理现在越来越中台化了，思维模式越来越技术化了，相应的离业务决策也会越来越远。因为现在的互联网大公司，分工越来越明确。这也很符合经济学原理和商业发展的基本规律：社会分工带来效率提升。一个人长期从事某一项工作，熟能生巧，效率必将提升。雇佣在某一领域有深度经验的专业人士，公司可以获取最大的效率确定性。我们要看清我们所处的位置。在一场战役中，你是后方保障，还是前排冲锋？其实都有价值。一个公司存在的目的就是组织人们高效协作起来，承担各自的岗位职责。不可能人人都是上战场扛枪的，也需要造枪造子弹的人，也需要做后勤保障的人。

现象咱们理解了，那么再说，我们怎么量化产出这个事情。

我总结了三种量化的方法：

1、人效提升量化法

2、开发成本量化法

3、以终为始衡量法

1、人效提升量化法：

我们做的一些产品功能，能直接影响的就是「办事效率」。

这个功能不做，业务方要多投入几个人进去维护这个流程，办这个事情？多投几个人不只是带来的固定人力工资成本，还带来了组织协同上的低效。

人越多，传递信息越容易出现遗漏；人为控制的环节也容易出现风险，excel 飞来飞去不合规；遇到重要的问题时，人越多越难快刀斩乱麻的解决问题。这些潜在风险其实也算成本的一种。

那么我们可以这样量化：

这事儿做完以后能节约几个人力/月（效率指标）？

能降低多少沟通成本（效率指标）？

能减少多少潜在风险（姑且称它为“安全指标”吧）？

最终有多少比例的相关员工在日常使用这个系统（渗透率指标）？

此外，按照常规经验，给职级越高的人提供的产品功能，越容易被认可价值，越容易拿到资源推动。因为越高职级的用户，在组织内要做的决策更多更重要，让他们省心提效，降低风险，是更重要的事情。

当然，我们也要看清业务所在的阶段。业务早期，需要快速/低成本/低扩展性上线，可能效率问题无法取得最优解，在产品设计时总有些妥协；而到了业务发展中期，产品设计就要考虑如何极致提升效率，如何保障高扩展性和系统的稳健性了。

2、开发成本量化法:

我也听说过一些公司会给产品研发“明码标价”，开发这个功能消耗了x人日的开发+测试+产品人力，算一下大概是多少钱。

提需求的业务部门，对于这个成本认不认可，接不接受？如果接受，就要放到这个部门的成本项里，看最终这个部门给公司创造的「收入-成本」是多少钱。这样的方式能够约束业务方别胡乱提需求，只提刀刃上的真的亟待解决的需求，而不是”我全都要“。

3、以终为始衡量法：

如果不盯着眼前的这些成本和效率问题，把眼光如果放的更长远，以终为始，也是一种做法。类比当年沃尔玛直接发射卫星，做信息系统建设，彻底提升供应链效率，领先了一个时代；再看亚马逊，当年的技术能力已经可以溢出到做了个云服务，成为公司的又一巨型增长引擎。虽然眼前做的一些功能，可能是当下“不经济”的决策，但是对公司长远发展来看是有价值的。

当然，如果你是在创业公司，要习惯小米加步枪，后台系统破破烂烂也能扛。甚至有时候选择外采 saas ＋共享文档，是一种更经济的选择。想起个题外话，我的一个朋友常拿某个 saas 的功能列表去和他家的研发团队沟通，说：你们要是不抓紧做这个功能，我就不得不去外采这个 saas 了，研发们赶忙努力提升开发效率，效果拔群。

如果你是在大厂，习惯了高举高打，做长期有价值的事情，那么不用太纠结“量化不了”的问题，就“以终为始”去做吧。公司也不是面临生死存亡，而是要全面提升赢的几率，眼前的一些研发成本，不是大问题。产品经理做的功能是不是眼前最经济的，也不是大问题。

以上。