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

推荐订阅源

WordPress大学
WordPress大学
Vercel News
Vercel News
博客园_首页
Y
Y Combinator Blog
美团技术团队
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
阮一峰的网络日志
阮一峰的网络日志
aimingoo的专栏
aimingoo的专栏
H
Hackread – Cybersecurity News, Data Breaches, AI and More
MyScale Blog
MyScale Blog
GbyAI
GbyAI
人人都是产品经理
人人都是产品经理
T
Tailwind CSS Blog
MongoDB | Blog
MongoDB | Blog
D
DataBreaches.Net
博客园 - Franky
Engineering at Meta
Engineering at Meta
量子位
The GitHub Blog
The GitHub Blog
F
Fortinet All Blogs
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
酷 壳 – CoolShell
酷 壳 – CoolShell
N
Netflix TechBlog - Medium

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理,
过程结论与价值结论的偏离问题探讨
产品老高 · 2025-08-12 · via 人人都是产品经理

在问题处理中,人们常得出与核心目标偏离的 “过程结论”,即过度聚焦于方案的可行性与细节,却忽略了最初的价值目标。需通过与原始目标的持续比对,确保结论不偏离核心价值,避免因折中或替代而导致价值衰减。

今天我们来聊一聊,在处理问题时我们所得到的结论,为什么有时候并不一定是真正的“结论”。

我们通常认为,结论是针对一件事情或一个目标,最终达成的方案或内容。为了形成这个结论,我们会进行大量的论证和讨论,过程中包含了许多推理、判断和决策。但实际上,很多时候我们得到的所谓“结论”,未必是真正意义上的最终结论。

这句话怎么理解呢?我们举个例子来看。比如说,今天有一个业务方找到你,提出一个需求:希望做一次活动分析,以便了解活动的转化率。这个需求很明确,但在做活动分析时,可能会遇到数据不全的问题,因此需要进行埋点。埋点的工作具体要做哪些、在哪里埋点,就是我们今天要讨论的内容。

首先,我们要确定需要在哪些地方埋点,这是第一个讨论点。其次,具体应该如何埋点,是第二个论题。基于这两个方向,我们会在日常沟通中展开讨论,评估埋点的可行性和合理性,并给出具体的埋点方案。

比如,我们得出的结论是:需要在某些页面埋点,比如结果页、流量入口、活动兑换页、10号页面等等。但在沟通过程中,可能会有人提出反对意见,认为这些页面由于某些客观原因无法埋点,于是大家会继续讨论,寻找更合适的解决方案。

经过一番讨论,最后我们可能会确定在哪些地方埋点。但实际上,这个所谓的“埋点结论”,有时会和我们最初的目标产生偏离。为什么会这样?因为在整个讨论过程中,常常会出现一种“跑偏”的情况。

我们讨论埋点的初衷,是为了统计转化率,这是我们的核心目标。然而,在讨论方案的合理性、可行性以及其他度量标准时,大家往往不再过分强调最初的目标。于是,讨论很容易变成:为了让方案看起来合理、可行,或者满足其他因素,最终给出的方案却偏离了核心目标。

简单来说,最开始我们讨论的是,如何埋点才能获得与转化率相关的指标和数据。但在实际讨论过程中,可能某个A点或者B点因为各种原因无法埋点,大家就会尝试寻找替代方案。找着找着,最后你会发现,讨论变成了“为了埋点而埋点”。大家的争论也变成了:“这个地方不能埋,那能不能埋别的地方?”“这里不行,那换另一个地方试试?”最终,当大家终于找到一个可以埋点的位置时,结论就变成了“这个点就是我们要埋的点”。

然而,这个点是否真的和我们最初的目标一致,很多时候就被忽略了。于是,最后得出的结论只是“我们要在某某地方埋点”,而这个结论本身,可能已经和最初的目标产生了偏差。

这就是我在标题中提到的”过程结论”。什么是过程结论?我们原本是为了实现某个特定目标而展开讨论,但在讨论过程中,由于大多数解决方案都聚焦于”如何解决”和”怎么解决”的问题,不可避免地会涉及方案的合理性和可行性评估。这两个方面是方案评估的关键点,但在讨论它们时,往往会出现偏离初衷的情况。

如果这种偏离没有及时纠正,我们的认知就会停留在”为了埋点而埋点”的阶段。在讨论可行性时,为了让方案能够落地,我们会做出各种折中。然而,并非所有折中都是可取的。在激烈的讨论场景中,有些同学在分析和思考时容易被带偏,最终导致我们为了埋点而埋点。表面上,埋点的问题似乎解决了,但实际上,我们得到的只是”过程结论”,而非”价值结论”。

那么,什么是价值结论?当我们判断某个埋点或若干个埋点后,需要将这些埋点的底层逻辑重新梳理一遍,看看是否能够满足转化率的获取需求。因为替代方案叠加替代方案,最终得出的结论未必等同于原有价值,可能只是一个经过系数调整的价值。

这是我们常说的1/2×1/2,它得到的不是1/2,而是1/4,这就是衰减效应。因此,在讨论整个过程的可行性时,当我们确定某个结论时,需要快速还原到原有的价值,并与目标进行验证,从而得出是否可行的结论,然后再进行下一步。

在大多数情况下,由于资源等客观原因,我们往往需要对某个环节进行替代、折中或取舍。然而,这些替代、折中或取舍的前提是必须保留目标的核心价值不变。如果为了推进方案而采用了一种新的解法,但这种解法无法达到目标,或者严重降低了目标的价值,那么我们就需要重新考虑这个方案是否可行,而不是为了推进而推进。

初中级的产品经理经常会出现这种情况:为了有效推进方案,他们尝试走捷径或走小路的逻辑。什么是走小路的逻辑?就是在这条路上,他们不停地向前推进,不停地判断,却从不考虑回头。因此,当他们遇到开发人员说”这个我做不了”时,他们会不停地想新的思路。但这些思路始终建立在他们当前的过程中,埋点、怎么埋、这儿不行、那儿行不行,不停地纠结于这些细节,而忽略了整体目标。

可能他在埋点的过程中,那个位置已经与原有的转化率无关,甚至几乎不能等同。在大多数情况下,这种不等同意味着它已经无法证明是转化率了。虽然它与原有目标近似或相似,但已不能完全相等,甚至不能代表原有目标。这时,我们得出的结论就是过程结论。

复杂的项目特别容易出现这种过程结论,尤其是在需求整体框架确定后,讨论细节时。特别是在复杂的方案中,当领导或中高层定好整体架构后,讨论细节时,我们很容易忽略最初的目标。这导致我们得出的结论往往是过程结论,而非价值结论,因为它们离目标有些远。因此,我们在讨论时,需要时刻提醒自己关注最初的目标,避免偏离。

所以在讨论复杂项目的某一个需求点的时候。要避免为了满足合理性和可行性获取到过程结论,在得到每个会议结论后需要和原有的价值结论即目标进行匹配,确保始终围绕着统一要求进行方案的设计、取舍、折中等行为。

本文由人人都是产品经理作者【高晖】,微信公众号:【产品老高】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

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