惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

WordPress大学
WordPress大学
大猫的无限游戏
大猫的无限游戏
酷 壳 – CoolShell
酷 壳 – CoolShell
博客园 - 叶小钗
月光博客
月光博客
Last Week in AI
Last Week in AI
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
人人都是产品经理
人人都是产品经理
阮一峰的网络日志
阮一峰的网络日志
罗磊的独立博客
IT之家
IT之家
美团技术团队
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Hugging Face - Blog
Hugging Face - Blog
博客园_首页
S
SegmentFault 最新的问题
宝玉的分享
宝玉的分享
博客园 - Franky
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Jina AI
Jina AI
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
The Cloudflare Blog
博客园 - 司徒正美
爱范儿
爱范儿

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
在产品规划中,如何做好成本控制和营收利润
产品经理wyy · 2024-03-11 · via 人人都是产品经理

从去年开始,降本增效的要求就在各个公司盛行。原本按照自己意愿开发设计的产品,也会被要求控制成本,增加利润。这种情况下,如何做好产品规划?

从去年开始,公司对营收、成本、利润这些更加重视起来,并且希望通过一系列量化的方式来统计、分析,从而对来年的规划做出合理的预算和控制。

在这过程中,我的直属上级也会时不时来追问产研资源投入的细节情况。例如9月份我们的产研成本投入了多少人?这些合理吗?这些投入是否都在控制之中?这些投入是否都是必须的?

说实话,最开始对这块其实并没有太多的关注,但随着被追问的次数多了,逐步也关注起这块的内容。

目前我们分多条业务线,各业务线自负盈亏,年底结算。所以在2024年的时候,需要更加在意整体的利润情况。

于是,在做24年全年规划的时候,成本控制、营收利润这几个词牢牢地悬在我们脑袋上空。

一、计算逻辑

简单分享一下目前我们在采用的一些逻辑:

“利润=营收-成本”

营收好算,属于我们业务的收入是多少就是多少;但是成本涉及到人员较多,特别是产研部分,因为目前的产研资源都是共享的,看每个月的优先级情况拿资源,且每个人同一时期有可能承担不同业务线的需求,所以比较难计算。

去年我们引进pingcode系统后,把产研这块的成本拆解成两大部分:

“产研=研发/测试+产品/运营/设计”

1、研发和测试同学的人力投入情况直接用pingcode系统上的工单工时做统计计算(因为我们所有的需求迭代都会建pingcode需求单,并拆解任务填写任务工时,所有的需求都要有迹可循,不填的话研发会打黑工,他们也不认);

2、而产品/运营/设计同学则需要每个月由各组组长统一填写各个同学在各个业务线所花费的精力占比。例如一个产品经理同时服务3条业务线,在1月份的投入可以写30%在业务线A,30%在业务线B,40%在业务线B(当然这只是举例子,实际上我们会更加细致,会分配到例如在A业务线什么环节-产品规划?商业化?流量?还是其他什么)。

由此可以把每个月各个业务线的产研投入情况给算出来,然后再根据每个人的占比以及每个人的薪酬待遇情况,财务给出统计的成本结果,我们就可以知道每个月的实际投入人力资源情况和成本数据。

二、想清楚什么是真正要做的

由此其实反向对于产品规划上的要求更高了,在今年制定的利润目标下,一方面要在营收增长上下功夫,另一方面也要严控成本。说人话就是:

产研资源极度有限的情况下,非必要不迭代,想清楚哪些是一定要做的需求。哪些需求做了是可以带来营收的?哪些需求做了是可以优化成本的?如果没想清楚的情况下是不是可以不做迭代?

对于做企业SaaS业务来说,营收来自于三大块:续费+增购+新签。

这三大块的难度依次递增。目前我们最核心的商业化模式是通过售卖年度的会员来收费,根据账号数量的多少决定最终客户的成交价格。

  1. 续费:哪些需求是客户的核心卡点?我们搭建了一套客户健康度监测体系,定义了四个核心指标,当这些指标异常的情况下需要更多去关注这个客户的使用情况。是否是由于产品的原因用不起来?到期后是否会续费?不续费的话核心的卡点是什么?能否通过关键的产品迭代来实现满足?
  2. 增购:是否有增购账号的可能性?由于前面所说的商业化模式所限,目前最可行的增购在于拓展客户的使用人数。我们是给企业提供营销内容设计的工具型解决方案,KA客户在订购的时候往往只是先内部一个部门发起的采购,先给一部分人用,那么这部分人用好了之后,是否有拓展推给公司其他部门来使用的可能性呢?历史是有过类似成功的案例,一方面客观因素中随着客户自身业务发展,作图需求日益增长,本身该部门的人员增长带来该部门的使用人数增加增购;另一方面是该部门的成功案例成功推广到公司其他部门,吸引更多的人来使用。而如何把这类的增购模式复制到其他更多客户中目前也还是我们正在思考的一个问题。因为从「客户原有的订购用户用得好」到「客户就会推广开更多账号来用」这之间的因果关系无法一步到位承接,还缺少了什么关键的因素是我们还没找到的?
  3. 新签:是什么阻碍了我们的新签成单?目前来看整体的KA新签成单周期较长,客单价无法达到相应的合理区间,会导致新签这条路愈发艰难。或许产品层面我们是领先于竞品,但目前该赛道的整体市场情况,新签周期和客单价似乎都处于一个非常恶劣的环境。甚至近年来还有后来者以更低的价格去啃市场的一角,无疑是雪上加霜。甚至让我开始质疑这是否是一个好的赛道?我们销售层面的打法是否还要坚持这样的KA获客方式?公司在销售侧目前有电销、直销为主;但过去两年时间,电销逐步成熟摸出套路,也能在很短时间成交客单价比直销还高的客户订单。成单周期更短,客单价更高,这无疑是对KA直销团队的沉重打击。仍记得之前在易订货的时候,基本没有直销团队,都是以电销+渠道为主,且铱云建立了全国非常完善的渠道体系。冯颉对渠道的重视度非常之高,曾经有一年我们的口号是“产品领先,渠道致胜”,每年也会定期跟渠道伙伴保持强联络。而现在,我们在企业业务这块的出路又在哪里呢?

回到产品规划上来,俞军产品方法论中其实也有讲到,产品做到最后,你会发现,要有「交易模型」的思维去考虑产品规划。即你做的所有产品需求,都要能带来交易的价值。这倒逼我们不断反思,我做的这个需求真的可以为营收、利润带来贡献吗?不能,就最好想清楚,是不是可以不做?

产品做加法真的很简单,编一堆自我认同的用户故事,不断累加功能;但难的是做减法,体现在你在规划需求的时候可以很坚定地砍掉某些需求不做。因为你清楚「交易模型」中,这样的需求并不能带来更多的价值,不必去为了追求「完美」而去做某些需求。B端相比C端来说,更更看重价值的兑现和降本增效。

三、减法思维

这一次次的营收、利润、成本的概念不断在你脑中响起,雕刻在你意识里,只有当把这些概念都习惯性地融入到每一次的产品规划中,才能更进一步筛选出高价值场景和需求。

认清价值,多做减法!

本文由 @勤奋向上的零先森 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。