周一与合作公司开例行产品早会，这次我主要旁听，除了日常工作同步外还有一个主题，招人。
他们公司今年业务增长比较快，研发和运营团队已经在去年底扩张了 10% 左右，这次准备给产品团队增加人手了。
对此，我是有不同意见的。
在我看来，按照他们现在的迭代节奏和需求去化率来说，当下的团队规模是效率最佳状态，再招人只会加剧熵增。
目前产品迭代周期是一周半，平均在 10 天左右。从业务需求提出到响应上线，最多不超过两周。
每个迭代周期的后半段，就会开始评估下一个周期的需求排期和产量，从过去一个月的需求去化率来看，整体能达到 90% 以上。
也就是说，九成以上的业务需求可以在现在的产品团队规模下被消化掉。
整个迭代周期内，产品经理要完成三类工作，分别是开发需求跟进、新需求方案设计、已上线需求复盘，其中工作占比比较高的是新需求方案设计。
这部分工作既包含前期沟通、中期设计、后期评审，还包括方案修改和对原有已上线功能的迭代。
从现状来看，已有团队规模能去化掉 90% 的需求，那为了 10% 的空间去扩张团队划算么？
我觉得，是不划算的。
这不是一种感觉，而是我根据他们历史数据和客观落地情况得出的结论。
会后我拉出了过去三个月的需求清单算了下，真正进入开发的业务需求在所有提出的业务需求中占比只有 70%，剩下的 30% 有如下几个原因被遗弃。
第一，当时优先级不高，后续没有优先级被无限积压。
这种情况在很多团队都比较常见，一开始收集了一堆需求，评估后总有一些优先级不高的垫底。
每隔一段时间，都会有优先级更高的需求进来，那这些垫底需求就会被无限积压。
看似有很多没做的需求，实际上真正重要且紧急的并没有那么多。
第二，需求没变，问题变了。
业务需求通常有即时性的特点，当时当刻确实是一个成立的需求，但一段时间后会因为外部环境和问题的变化，原有需求就失效了。
做产品的读者可以去看下历史需求清单，一定会发现不少类似需求。
简单说，就是需求没变，但是问题变了，原有需求不再适应当前问题。
第三，需求不成立。
这基本是通过产品团队的分析转化后否掉的需求，或者是通过其他不需要开发的方案满足的需求。
所以，看似很多的业务需求其实在进入生产环节时是需要打折扣的。
对于他们团队来说，现有规模足以支撑现阶段业务需求的去化，不满足的那 10% 有很大可能符合上面提到原因的第一和第二点。
如果再从产品团队工作方法和效率方面入手，去化率还能有所提高，这都是在不增加工作量的前提下。
会后老板问我的建议，我一开始回了四个字，别招人了。
一个小时后，我把这些逻辑用文字发给了他，同时也顺便拿出来跟你们分享一下。
对于创业公司来说，势必会经历这么几个阶段，小作坊、上规模、再瘦身。
尤其是在上规模这个阶段，很多时候都是对扩张的一种执念，认为规模大代表业务才有更大增量。
还是前面说的，企业熵增带来的弊端会大于业务增量，如果此时组织能力跟不上，其实是很可怕的。
瘦身是为了增加核心力量，而不是靠原本不强的核心去支撑一身肥肉。
关于这个话题，如果你们感兴趣的话点个赞，下次我会专门开个直播聊一聊。
················· 唐韧出品 ·················
安可时刻
今天的文章封面图依然是 AI 生成的，在图片左下角有一个「AI生成」的水印，有很多读者误会这篇文章是 AI 写的。
这张图片的咒语是：一个在找工作的产品经理背着包在看公司的招聘要求。
