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

推荐订阅源

cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
云风的 BLOG
云风的 BLOG
aimingoo的专栏
aimingoo的专栏
Vercel News
Vercel News
T
The Blog of Author Tim Ferriss
F
Full Disclosure
A
About on SuperTechFans
C
Check Point Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
量子位
Know Your Adversary
Know Your Adversary
K
Kaspersky official blog
L
LINUX DO - 热门话题
Recorded Future
Recorded Future
C
Cisco Blogs
M
MIT News - Artificial intelligence
T
Tenable Blog
G
GRAHAM CLULEY
月光博客
月光博客
Recent Announcements
Recent Announcements
V
Visual Studio Blog
IT之家
IT之家
T
The Exploit Database - CXSecurity.com
The GitHub Blog
The GitHub Blog
T
Threat Research - Cisco Blogs
D
DataBreaches.Net
P
Privacy International News Feed
P
Proofpoint News Feed
I
Intezer
博客园 - 叶小钗
C
CXSECURITY Database RSS Feed - CXSecurity.com
The Hacker News
The Hacker News
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
博客园 - Franky
SecWiki News
SecWiki News
宝玉的分享
宝玉的分享
P
Palo Alto Networks Blog
Last Week in AI
Last Week in AI
小众软件
小众软件
Hacker News - Newest:
Hacker News - Newest: "LLM"
O
OpenAI News
N
News and Events Feed by Topic
Microsoft Security Blog
Microsoft Security Blog
Security Archives - TechRepublic
Security Archives - TechRepublic
N
News and Events Feed by Topic
The Cloudflare Blog
Spread Privacy
Spread Privacy
酷 壳 – CoolShell
酷 壳 – CoolShell
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
B
Blog RSS Feed

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
当接过一个新业务/需求时,底层的思考框架都有什么
跳跳堂 · 2025-06-20 · via 人人都是产品经理

在面对新业务或需求时,如何系统地思考并制定有效的策略是每个产品经理和业务负责人都需要掌握的关键技能。本文通过一个具体的项目案例,详细介绍了在接手新业务时可以采用的底层思考框架。

当你向别人介绍你做过的某个项目时,你可以从以下思路进行说明:

  1. 我做的业务是XXXX,我在这个业务里负责的是XXX环节(或我是这个业务的负责人),对XXX指标负责。
  2. 当时的业务现状是XXXX,但是我们希望达到XXX的目标,可以描述一下这个目标达成的难度。
  3. 围绕目标,我构建了XXXXX的公式,围绕公式针对XXX参数,提出了假设123,最终达到的结果是XXXX。
  4. 如果你的业务公式认知或项目整体还有逐层迭代,细化,深化的过程,也可以描述出来。

在实际工作中,当我们接手一个新业务/项目时,也可以从上述框架进行入手思考。

下面,我用一个项目举例,业务和数据脱敏:

业务背景:某APP,”工具+内容”带增长进入相对瓶颈期后,急需新的思路或方向将增长迈向新的台阶(场面话)。人话就是,就这么些资源,这么些时间,赶紧“不择手段”的给我提增长。于是,分析分析分析,梳理梳理梳理,“社交带增长”思路在某个神经元的临界点调了出来。抓住先,想要立项说服老板们,你得给出逻辑证明,于是,开始做立项前的业务可行性的纸面逻辑推演论证。

纸面论证阶段,两个假设:

  1. 用户价值假设;
  2. 业务增长假设;

先后依次论证这两个假设从逻辑上(包括定性定量-数据/调研,科学类比)是否成立。有一个不成立,都不必继续了,即使继续做下去,也大概率会失败。当然,这里可能有人会问,万一只是逻辑论证的过程不对呢,实际可能是成立的呢?是有这种可能,但是你想,负责这个业务的人连论证这一步都做不对,那即使后续进入项目阶段,所对应的产品方案,增长策略等等,都是基于同一个负责人的,那你说后续成功的概率能有多大呢。

所以说,一个人有多少分的认知,TA就能解决多少分的问题,超分是小概率事件,长期来看,都将均值回归。所以说,做增长,做创业,本质上都是在做概率,概率的大小取决于做事的人的认知水平和一点点运气。

如果存在一个上帝视角(上帝视角下:一切客观的事实/理论/规律,都客观的存在在那里,上帝视角能看到全局,人类视角只能看到局部,人类所做的一切,都是在无限逼近上帝视角-假设上帝视角的认知是100分的话),那么每个需求都有两种客观状态:要么成立,要么不成立。上帝视角知道这个事实。而我们,不知道。我们能做的,就是先推演,看从逻辑上,是否成立,如果逻辑上都不成立,就不用继续了。上线了也大概率会失败。如果成立,再提出关键假设(假设驱动),(基于科学类比/xx模型或方法/定性定量分析)给出最小解决方案,放到用户面前(实践-迭代认知),实际去验证,如果怎么都跑不通,那大概率是需求不成立,即用户价值假设被证伪。

1、先论证用户价值假设是否成立;

首先明确什么是用户价值:

即什么用户在什么场景下遇到了什么问题,我们能提供什么解决方案解决这个问题,这就是用户价值。换句话总结下就是:用户愿意选择你的最小产品解决方案。产品要的就是,“不择手段”的让更多的用户更快感知到这个用户价值,用户群体留下来的概率就会更大。

论证:明确目标用户群体,预估群体范围大小,带入场景,判断是否存在需求。

比如,(陌生人)社交带增长:大盘用户都可以是潜在用户,分为社交主动发起者和被动接收者。最小内核是陌生人彼此之间一对一的社交关系的接触-维持-建立。场景是基于产品主业务“假设是内容”场景,所以用户彼此对场景拥有共同的载体,有可能产生共同的话题。所以,逻辑上判断,群体是客观的,内核是成立的。

2、再论证业务增长假设是否成立(即业务目标可做的空间有多大);

论证步骤:基于用户价值假设>>明确业务目标>>根据业务目标将业务目标公式拆解出来>>再根据公式中各项因子,衡量业务目标可提升空间的大小。

上述两个假设论证后,再根据业务目标公式各项的因子,判断影响业务目标(等式左侧)达成的关键卡点是什么,各因子对业务目标的影响权重大小如何,你能针对各因子分别提出哪些关键假设-验证(包括对因子进行二级三级指标下拆),要提升因子所依赖的协作方都有哪些,开发成本如何,由此预估各假设的ROI>>需求池就出来了,优先级也出来了。

如何拆解业务目标公式:以终为始~

业务公式定义:把业务的结果指标用关键因素按数学公式的形式表达出来。

  1. 先确定业务最需要拿到的结果;(如下方案例中的最需要拿到的结果是“用户建立社交关系”)
  2. 再根据该结果找出相应的数据指标即业务目标;(“社交成对数”)
  3. 围绕业务目标,把所有的核心过程指标找出来;
  4. 再确定这些指标之间的关系,或乘或加;(到这一步,公式已经出来了)
  5. 找出影响业务生死的核心因素
  6. 针对各因素提出关键假设(每个假设,都可能是业务迭代过程中的一个需求,可能来自数据分析,可能来自用户调研,可能来自竞品分析,可能来自…)

注意:区分雪中送炭锦上添花

详细说明下上述步骤中非常关键和重要的第“5”步:

基于拆解出来的公式,找出影响业务生死的核心因素,基于核心因素提出多个关键假设,找出其中最重要的关键假设,即我们要从多个假设中,确定哪个假设是如果做不好业务就会死掉的那个(雪中送炭的),这个问题在业务发展的不同阶段,面对同一个业务公式,答案可能会发生变化。因此要在每一个业务阶段,每一次重要的复盘时,时刻反问这个问题,让自己和团队时刻进入深度思考状态,这能够提升团队对于业务的理解深度,对达成业务共识也有帮助,进而对业务目标的制定和理解,计划的制定和落地,都会带来一系列推动作用。

接着,还需要重新评估公式里的这些过程指标,理想的情况是,每一个核心过程指标,都可能是一个相对独立的目标结果,且能继续下拆出它的二级指标公式(根据需要选择是否继续下拆)。同时,要将其他各因子对等式左边一级指标的影响权重大小做预估,确定哪些因子更重要,先做哪些因子(雪中送炭的),后做或暂不做哪些因子(锦上添花的)。

最后,再针对对应因子提出关键假设>>验证>>迭代认知>>继续提假设。

第6步的提出关键假设是什么意思?是指,针对等式右侧某一因子(指标),如果我们要想提升它(因为右侧因子的提升会带来左侧业务目标的提升),你能想到哪些办法/方案/策略等–这些办法/方法/策略就是关键假设,假设是需要待验证的,可能被证实,可能被证伪,是个概率事件。所以做增长/创新/创业,本质都是概率。几分的认知,解决几分的问题(见上图描述),解决超出认知的问题,失败的概率会更大。这里很重要一点是,它和“我觉得你这个不对”“我认为应该这样”“我感觉这样更好”等等很像,但这些都是“主观”观点,而假设是客观判断,一个假设,在被验证之前,只是假设,不是事实。而“我认为应该这样更好”潜意识里表示当前你的认知下这个是对的,带有主观倾向,一旦带有主观倾向,你就有可能不想去验证它(当然,除非你之前有验证过类似的,或者其他人验证过),而它,有很大概率是错的。

以上过程,基本上也同时完成了对业务目标的制定,过程指标的考核,团队分工的标准,核心任务的优先级的全部确定。从这个时候开始,就完成了业务管理上“复杂的事情简单化”“简单的事情标准化”的过程

(这,就是业务目标管理的过程)

以上,举栗说明-具体过程如下:

栗-社交业务,用户价值假设前面说明过。现在基于用户价值,把阶段性业务目标确定下来。

社交业务服务于增长,即服务于留存提升和收入提升。也就是我们需要通过用户与用户之间建立社交关系(上面拆解步骤中的“1、先确定业务最需要拿到的结果”),通过“关系”来提升用户活跃,进而提升留存(收入暂不谈,路径太长)。那么,用户通过什么样的形式建立社交关系呢?直接能想到的就是IM会话场景,脱离这个场景还能想到一个创作型用户(比如该用户发布一个什么内容时,因为TA既然有发布内容的诉求,我们就假设TA当前是有对外社交的诉求的,这里的社交诉求可能是IM会话这种,也可能是想收到他人看到我发布的内容后的互动回应这种),我们主要以IM场景举例进行说明,也会带上互动场景。

补充说明:“关系”的建立即在一定时间周期内有会话交流或后续有其他形式的互动交流。即使他们在这个周期过后,交流不再持续,那他们彼此也已经建立了关系-从陌生人进阶为相对熟人。他们在后续的其他“互动”上,比如浏览对方作品,给对方点赞评论等从数据上来看,都比没有进入这个阶段的用户的数据相对更好。

所以,我们可以围绕“关系”来定业务目标,要想留存影响足够大,这里的“关系”就需要渗透的足够广,所以,我们可以想到“陌生人社交关系数”这个指标来衡量我们的业务目标,即成功建立社交关系的用户对数,我们换个词,叫“陌生人社交成对数”(上述拆解步骤中的“2、再根据该结果找出相应的数据指标即业务目标”)。

到此,阶段性业务目标确定了:

陌生人社交成对数

  • 陌生人的口径:历史从未有过IM会话记录
  • 社交成对的口径:首次会话的n天内有m天有过会话记录 (n和m前期可通过圈目标用户跑数据找拐点得到,后期根据假设检验的实际结果可能有调整)

接下来,我们需要基于业务目标将公式拆出来(即等式右边),因为我们的产品策略无法直接作用于“社交成对数”这个指标上来,就像策略难以直接干预DAU一样。另外,如果不拆业务公式,结果就是后续项目推进都是散点的,主观的。

正式拆解过程:(上述拆解步骤中的“3、围绕业务目标,把所有的核心过程指标找出来;4、再确定这些指标之间的关系,或乘或加”)

陌生人社交成对数 = DAU * 消息页访问率 * 发送会话率 * 发送回复率 * 首聊n天内m天会话率

其中,(上述这个公式不是一个好的拆解,只是为了说明为什么不好举个例子):

  • DAU是一个相对稳定的值,我们短期内很难干预,且前面也提到策略难以直接干预DAU。所以,DAU不应该出现在这里。
  • 消息页访问率,消息页是APP的一个一级Tab页,直接和具体某个功能场景关联上了,应该向上归因,用其他不含具体场景的指标替代。(一级公式通常尽量避免含有具体场景的指标,否则等式左边的值就被局限在了当前这个场景的流量大小下了)访问消息页是为了发送的,所以向上归因,真正的指标应该是“发送数”。
  • 发送会话率(DAU中有多少人会发),这个没问题,不含具体场景。
  • 发送回复率(接收到会话的用户中有多少会回复),这个没问题,不含具体场景。
  • 首聊n天内m天会话率,类似这种因子通常称为“”因子,根据实际业务具体确定。意思是首聊后,未来n天内有m天有过聊天行为。作用时衡量关系是否成对的标准。仅首聊了不算成对(说明,怎么算成对,根据实际业务目标自己定就好)。另外,这个指标是一个滞后指标,其提升难度应该不会小,退一步讲,即使它能翻倍,又能怎样呢,先放这。

所以,公式变成:

社交成对数 = 发送会话数 * 发送回复率 * 首聊n天内m天会话率

这时,发送会话数就不仅限与消息页场景了,其他地方也可以想办法让用户去发会话,这个指标又有一定的提升空间了。但根据指标的数据现状,即使因子“发送会话数”翻倍,等式左边的社交成对数也会翻倍,但绝对值还是太小。社交成对数的绝对值起码要有上百倍的提升(目标达成难度),平摊到大盘留存上才会有明显效果。解释下这段描述:

比如DAU100万,愿意主动社交的用户假设有1%,即1万。每个人每天发1条,那么有1万人能收到,假设人群不重合,那么就有2万人被“社交关系”覆盖了,另外98万呢?都“空着”。怎么填补这个空呢?两种方式:其一让更多的用户主动“发”,其二让更多的用户被动“收”。主动发:由于人性,天然仅有少部分人愿意主动对外社交(真的行动起来),所以,即使我们能将1%翻3倍(难度很大了),也 还有90多万“空着”。那么,我们是不是可以从被动收入手,即当用户给另一个用户发消息时,想办法让这个消息发给更多的用户(经发消息的用户同意后)。比如,假设每条消息可分发给100人,那么1万用户发,就会有100万用户收到,社交关系渗透率就上来了(这个假设也是达成业务目标的最关键的一个假设–上面拆解步骤中的“5、找出影响业务生死的核心因素”)(诶,超了,没事,假设而已)于是,上述公式中就缺了一个关键因子:单会话发送人数。加上这个因子,业务目标可提升空间从逻辑上就直接提升了100倍。

于是,公式变成(最终公式):

社交成对数 = 发送会话数 * 单会话分发人数 * 发送回复率 * 首聊n天内m天会话率

上述因子,都是乘法关系,每一个因子提升多少,都会直接导致左侧的值提升多少。业务目标拆解后(公式),接下来,就需要判断各因子的提升空间大小以及针对因子提出关键假设(上面拆解步骤中的“6、针对各因素提出关键假设”),然后预估各假设的ROI,给出优先级。

针对各因子提出关键假设:

发送会话数,前面有分析,假设能提升3倍;

针对这个因子,提出假设:

  • 假设1:用户进入会话页时,将打招呼话术文案以某种形式比如标签等外显给用户,这样能提升用户发送的概率。
  • 假设2:用户进入会话页时,利用大模型生成打招呼话术文案,这样能提升用户发送的概率。
  • 假设3:在用户主路径上引导用户发起会话(比如,如果站内用户主路径有一个功能,用户对外发布一个什么内容时,在这个节点,我们提取当前内容的相关信息,结合大模型生成相关话术文案,再包装一下,让用户决定要不要将这个“包装”同时发给很多人),能提升用户发送会话的概率。因为当前场景下既然用户准备对外发布内容,那我们就可以假设用户有对外社交诉求–将内容发出去,想收到别人的认可互动等。
  • 假设4:后期,如果玩法跑通(下方单会话分发人数这个因子跑通),给用户提供一个主动向外发起“会话”的功能A,能提升会话发送率。

其他还有一些迭代过程中的分支假设就不一一列举了。

所以,这个因子,在经过上述假设验证后,得到了该因子自己的拆解公式:

发送会话数 = 消息页发送会话数 + 主路径发送会话数 + 功能A的发送会话数

发送回复率,前面有分析,假设能提升10倍;

分析数据发现,回复率和打招呼的话术内容形式强相关,和发送会话时对方是否在线强相关。所以:

假设1:用户发送会话时,引导用户发送“高回复率(相关性)”话术,能提升回复率。

上线AB实验后(假设检验),确定话术内容形式和回复率有因果关系。

假设2:基于被验证后的假设1(现在它已经成为“事实”了),利用AI根据用户场景实时生成高回复率形式的话术内容,能提升会话回复率。

假设3:算法分发策略增加根据对方是否在线,优先发给当时在线的用户;

上线AB实验后(假设检验),确定“在线”和回复率有因果关系。

假设4:基于被验证后的假设3,将一部分分发给当时在线的用户,留一部分分发给当时不在线,但当日n点前如果打开APP的话,打开后在分发给他们(这中间可以对“n点”的“n”提出假设进行验证,还可以提出打开后m分钟分发对回复率提升等等更多的假设)

假设5:新用户的发给新用户,老用户的发给老用户,新老用户交叉分发。(其中,新用户还可以根据时间做切片,比如7日内新用户,14日内新用户等几种假设检验)(但这里可能因为新老用户比例差别太大,所以平摊下来看整体效果可能会很小,所以,这里的假设价值就不高)

假设6:新用户人均收到会话数1条/2条,高活跃老用户人均收到会话数0条,1条、2条;(比如,假设验证前,不确定给新用户发1条好,因为怕发多了打扰新用户导致流失,还是发2条好,因为可能发多条,用户对其中1条感兴趣呢,那就可能提升回复率了。因为回复率和留存有正向因果关系;高活跃用户也是,比如用户已经很高活跃了,给他发会话很难说再提升他的留存搞不好还会起反作用。或者说他已经很活跃了,那他回复的概率应该也会更大,这样能反过来提升发送者的留存等等)(但,这里提前可以考虑到的是,受发送会话数影响,只有很少部分用户能发到2条,因为优先要保证用户收到1条,有剩余的会话数才会继续发,所以,这里的假设的价值也不高)

假设7:接收会话的用户,在进入会话页后,大模型给他生成好回复的话术,直接点击即可回复,能提升回复率;(但,这个假设可能会让用户觉得好假,影响后续-当日之后后续的社交关系的持续,所以这个假设需谨慎)

其他假设:将“消息页发送会话数”这个因子下拆一层:

消息页发送会话数 = 消息页访问数 * 消息页陌生人会话曝光率 * 会话列表点击率 *IM 会话页消息回复率 (如果需要,还可以继续下拆)

针对这个子公式的各因子也可提出相关假设,但评估ROI后,这块假设的优先级较低。暂不考虑。

为什么这个因子(发送回复率)的假设多余上面的因子(发送会话数)?因为对这个因子信心更大-10倍;且实现策略相对上一个因子要简单,很多都是算法调分发规则就行,而上一个很多都依赖功能上的调整,依赖客户端,开发成本和周期都要更大,说到底就是ROI的对比。

首聊n天内m天会话率,前面有分析,暂不考虑;

单会话分发人数,这个现状值为1(每个用户平均给1点几个陌生用户发送会话),算法分发接入后,分发给多少用户–主要由3个数决定,一是DAU,二是发送会话人数,三是一个用户最多收到几条会话而不会被打扰。因为,假设每条会话都分发给全量DAU,如果有100条待分发的会话,人均会收到100条会话,太可怕了,卸载吧。最终经过几轮测试,单会话分发人数的值大概在100(脱敏数据)左右,人均15天内最多收到2条会话(脱敏数据)。(这里的几轮:指过程中提出和测试过多个子假设,假设同一个用户n天内最多收到m条会话,这里的n和m都有对应的假设

如果DAU为40万(假设),会话发送率1%,那么4000人每人每日发1条(注意,每日切片里的人群是动态变化的,因为DAU是动态的,不是说今天是这一群人,明天还是这群人,有新来的,有回流的,有昨天来了今天也来的)每条发给100个人,那么DAU中有 4000*100=40万人会收到会话,即所有人都会收到,相对于会话渗透做到了100%。实际情况是用户是否收到会话,以及影响会话回复率的因素等,都会决定分发的时机,也就是说实际上单会话分发100人这里的分发策略很复杂,很难做到按理论逻辑规则进行分发,当然,实际效果和上述结论差别不会太大。

为什么这个因子有100倍空间,但提出的“假设”并不多。因为这个关键假设很容易验证,验证后(如果验证不成立就么有后续了)后续提升的空间就不大了。也就是说,相对于这个100倍是靠1个假设就拉起来了(忽略过程中对分发给多少人的测试过程的话),但这个假设又至关重要,若假设被验证不成立,则整个项目的价值就不大了。

从定量角度补充说明下公式中为什么加了“首聊n天内m天会话率”这个因子:若去掉这个因子,则:

社交成对数 = 发送会话数 * 单会话分发人数 * 发送回复率 即,该公式指陌生人之间只要开启了一轮你来我往的会话即算成对关系建立。但这个指标和增长的一级指标(留存)并无显著的因果关系,即用户即使完成了这个行为,只是次留有一定提升,次留后的比如3 7 15等留存几乎无变化。所以我认为,从更上层的业务目标增长来看,这并不是一个高ROI的指标拆解。

小结:业务目标管理

  • 验证用户价值假设和增长假设;
  • 确定业务目标;
  • 基于业务目标拆解业务公式;
  • 找出影响业务公式成败的生死因素,提出关键假设;
  • 根据情况,进行下级指标公式拆解;
  • 预估各因子对业务目标提升空间的权重大小;
  • 根据因子权重,提出关键假设>>MVP验证>>迭代认知。

本文由 @弋十三 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议。

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