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

推荐订阅源

D
DataBreaches.Net
IT之家
IT之家
The Cloudflare Blog
Apple Machine Learning Research
Apple Machine Learning Research
WordPress大学
WordPress大学
N
Netflix TechBlog - Medium
阮一峰的网络日志
阮一峰的网络日志
P
Proofpoint News Feed
L
LangChain Blog
博客园 - Franky
美团技术团队
J
Java Code Geeks
Microsoft Security Blog
Microsoft Security Blog
博客园 - 叶小钗
小众软件
小众软件
Y
Y Combinator Blog
B
Blog RSS Feed
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
D
Docker
Hugging Face - Blog
Hugging Face - Blog
Jina AI
Jina AI
罗磊的独立博客
大猫的无限游戏
大猫的无限游戏
Vercel News
Vercel News

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理,
用户增长框架与实战(10)用增的能力储备和团队结构
达太 · 2024-04-18 · via 人人都是产品经理

本篇文章作者在讲解用户增长的能量储备与团队结构,逆向拆解目标系统构造,从而清晰理解运作原理。让我们来一起看看吧~

一、用户增长的能力储备

1. 逆向拆解目标系统构造

逆向拆解目标系统构造,从而清晰理解运作原理。比如你想做好在facebook上投放,或者你想做好在小红书抖音上一个账号的粉丝数、订单量。假设自己是这个平台的产品负责人,能清晰表达系统都有哪些主要模块,如何从零搭建起来的,模块之间如何运作的。如果整理好思路,给一个技术团队讲清楚,基本就做到了。

对于付费渠道的增长,还需要理解这个系统的计费逻辑,也就是它如何把资源计价卖给我们的。理解预算和流量是如何分配才是合理的,为了平台自身的良性发展,他们会用什么策略。他们的成本是什么,目标是什么,平台自身增长的抓手是什么。

举个反例,我在给某个付费渠道团队讲,为什么我们浪费了大量预算,结果混入了大量无效流量。是由于这个campaign设置了转化事件,计费逻辑我们设置的tROAS,平台是按照近期历史统计,找到相似特征的目标受众,预估CTR,受众的当前竞价,然后从实际的 cost per event,反推出eCPM。所以我告诉他们,平台本质是按照 cost per event收费的,由于我们发送给平台的event有业务逻辑错误,导致了这个结果。但是这个团队从执行者到管理层,给我一致答复是:平台是按照click来计费,并不是按event。这样就属于纯按字面意思理解,很难做到增长价值了。

2. 对业务的深刻理解

比如大促、电商平台的商家运营,电商平台的买家运营。简单的说就是这个业务的付费方是谁,我们给他提供的价值是什么,他通过我们获得了什么收益。

举个反例,我问一个顶级资深运营同学,电商大促的底层逻辑,如果二选一,你会选哪个?

  1. 优化卖方资金、货物、物流、仓储等周转效率,提高资金的年化收益率,从而他们给用户让利。三赢。
  2. 让用户集中被广告触达,认为这个期间大量产品应该让利,但实际上却冲动消费。平台GMV有明显提升。

我得到的答复是#2。所以不难解释KPI为何那样定了。在我看来,那种KPI与公司业务的增长,并无正相关性。因为这不符合业务逻辑,提供的业务价值相当有限。

再举个反例,我在立项阶段问一个资深业务同学做的内容项目给用户提供了什么价值。他回答说,用户看了我们的内容,就会点击,我们就获得了流量。更可怕的是这个同学在晋升答辩时也是这样叙述的。

做到真正的“点线面“。通过深刻的业务理解,先抓到一个重点,做出成绩。思考相似业务的共性,合并逻辑,减少重复劳动,甚至抽象成算法逻辑,进一步提高效率。再思考更底层的共性,是否可以延展到更多部门,形成更庞大的体系,扩大影响力。少数同学可能会为了体系而做体系。把一个不重要的点放大,设计出一套复杂的体系,甚至称之为“点线面”。我见过太多例子,浪费了极大的资源。

千万不要钻牛角尖。比如当我给付费流量团队讲框架的逻辑和数据分析的过程,我说需要找到波动性最大的特征维度,暂定用标准方差计算。这个同学居然问我,”标准方差是线性的还是非线性的?”。我说,”随便你怎么算,合理即可,我只是为了省事,用excel默认公式算的,其实肉眼看就很明显了”。

二、团队结构

可能有的部门设计,把流量运营改名为用户增长,与产品、自有流量等运营团部并行。在我看来确实方便管理,结构清晰,但很难做出成绩。用户体验非常容易割裂,每一个环节还要重复劳动,重新思考,方向很难把控。按我的理解,用增就是用户运营下面的增长策略团队。策略之间是并行的,但是任何一个策略从头至尾应该是同一个团队在所有环节和部门中贯彻。

用户增长框架与实战part10 - 用增的能力储备和团队结构(草稿)

甚至有的团队设计,按照用户生命周期分组,例如:新用户、激活、促活、忠实度、召回。每个组下面再重新思考策略和抓手。我所看到的抓手,几乎是相似的,总结一个词就是买曝光。业务早期是可以的,中后期会发现成本升高,效果降低,无法持久。

应按用户画像分组,例如交友app按男女来拆,视角、需求、完全不同。每个组的负责人只要抓到需求痛点,用户生命周期各个阶段的策略也就非常容易想清楚,各个产品、算法团队该如何配合,也都可以讲的很清楚,更容易形成合力。

本文由 @达太 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议

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