ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

产品决策中用户视角与公司视角的平衡之道

产品决策中用户视角与公司视角的平衡之道 1. 为什么这两个视角说着说着就吵起来了最近一次需求评审会上我差点以为自己在看一场辩论赛。运营同事拍着桌子说用户调研白纸黑字写了大家就是想要一个只读模式别整那些花里胡哨的编辑功能。商业化负责人立刻接话没有编辑功能我们拿什么做差异化会员权益免费用户凭什么留下来两边都有数据支撑都觉得自己代表真实世界谁也没法说服谁。这个场景我太熟悉了几乎每隔两个月就会上演一次。用户视角和公司视角的冲突本质是价值判断的时间尺度不同。用户活在当下他要的是我现在打开这个App能不能一口气把事办完公司活在周期里要考虑这个功能能不能带来留存、付费、口碑三个月后我们靠什么增长。这两种视角没有对错之分它们只是在不同维度上回答不同的问题。但问题在于大多数讨论把维度差异误当成了立场对立一开口就变成了你到底站在用户那边还是公司那边。真正让我觉得需要把这件事掰开揉碎讲的是我发现连很多资深从业者也会在这件事上栽跟头。有些人拿用户第一当挡箭牌把一切商业诉求都归类为吃相难看有些人拿商业闭环当大棒把一切用户反馈都解释为噪音。两种做法都在偷懒因为真正难的不是选边站而是在一条具体业务线上把两个视角的诉求翻译成同一个可执行的目标。这篇文章不打算讲什么双赢思维这种正确但没用的废话。我想拆的是用户视角和公司视角各自在什么时候是对的什么时候是失灵的以及如何通过一套可操作的方法让两个视角在具体决策中真正对话起来。2. 用户视角不是无条件妥协单边思维的三个失灵场景2.1 用户想要什么就做什么的产品死于需求疲劳我要先泼一盆冷水用户视角如果被滥用非但不是护身符反而会是产品最危险的惯性力。一个很典型的例子是我接手过的一个工具类产品。用户可劲儿提意见——字体能不能换大一点配色能不能柔和一点那个确认弹窗能不能少一点。我们团队那时候信奉用户即上帝几乎每一个在用户群里被顶到高赞的建议下一周就可以进入开发排期。结果呢半年之后产品变得异常温顺什么需求都满足什么痛点都被照顾但数据面板上的次周留存率反而掉了一截。用户不是不知道自己要什么而是用户只会基于他眼前的使用情境提出局部优化建议他可不会为产品的全局走向负责更不会考虑你的服务器成本和商业目标。每一次点我要字体大一点对于单个用户来说是真实痛点但对于产品整体来说它挤占的是另一个更核心需求的开发资源。当我们把所有反馈都当作圣旨去执行时实际上是在让少数发声用户替代多数沉默用户做决策。更强的声音往往来自更重度、更有表达欲的用户群体这个群体的需求天然偏向加功能、变复杂而沉默的大多数考虑的是简洁、好用、别打扰我。如果只看用户反馈产品会被那10%的重度用户牵着鼻子走最终把90%的轻度用户推开。这并不是说用户调研没有用而是说用户调研适合用来发现目标方向是否需要调整它不适合用来直接决定每一行功能逻辑该怎么设计。2.2 用户付费意愿高的需求未必值得立刻投入这是我踩过最深的一个坑。当时我们做的是一个小众垂直社区的会员服务用户调研报告里写得很清楚78%的受访用户表示如果社区推出年度会员我非常愿意付费。看到这个数字的当天整个团队都有点飘产品经理连夜把会员体系加进了季度规划的第一优先级。结果呢真实会员功能上线之后转化率低得连给投资人的月报都不敢写太细。值还是不值才怪。那78%的用户嘴里说的愿意付费和钱包掏出来的动作之间差了大概十万八千里。调查问卷里说愿意付费可能是给调研团队面子可能是他们设想的是我爱的那个社区就算收费我也支持但等他们真的打开支付页面看到每月18元和使用第三方身份登录二选一时流失率直接爆表。真实的付费转化不是一个单一意愿指标能预测的消费者掏不掏钱取决于当下的感知价值、替代品成本、支付路径的摩擦程度这些细节在调研问卷阶段根本捕捉不到。这种时候如果端着用户都愿意付费了为什么还不做的思路去推进你是在一个虚假共识的基础上盖大楼。正确做法是把调研意愿当成探索信号而非需求验证花极小成本做一个最小可行版本用真实付费行为来检验而不是追着问卷数据的百分比跑。2.3 用户情绪最大的时候恰恰是最不该听用户的时候在一款社交产品做运营的那段时间我对这句话体会特别深。有一回我们调整了消息推送策略把部分通知折叠进小红点而不是直接弹窗上线才一天客服和App Store评论区就炸了你们凭什么把我的消息吞了我就说你们越来越不尊重用户了。评论区一度冲到2.1分当天就有产品同事建议紧急回滚说用户态度都这么明确了我们还不改等什么呢。我没有立刻执行回滚而是做了两件事第一把App Store差评逐条看了三遍发现至少六成差评集中在担心错过重要消息这一条第二翻后台数据看看折叠策略到底导致了多严重的消息漏接。数据出来之后发现真正用户完全没看到而错过的关键通知占比不到0.3%大部分被折叠的消息本身也不是实时性要求高的。用户情绪化的时候他表达的往往不是这个功能要改而是这个故事让我感到恐惧。在这类时刻如果顺从情绪立刻改回去你就永远不知道这个策略本来就该不该做因为你已经被一种短期情绪冲昏了头脑。正确的动作不是无视用户情绪而是先拆解情绪背后的那个焦虑模型——到底用户怕怕的是什么如果怕的是错过那产品的回应方式就不是回滚而是提供一个可感知的我已读了所有重要消息的反馈通道让用户重新建立安全感。3. 公司视角也有僵化的时候商业指标绑架下的四个盲区讲了用户视角失灵的三种情况有人可能觉得我在给公司视角站台。别急着下结论公司视角在落地的时候同样会犯很离谱的错误而且往往比用户视角犯的错更隐蔽因为它裹着一层数据驱动的合法外衣。3.1 指标完成了用户却跑了北极星指标的分裂症日活环比上涨12%这个季度稳了。这句话我听过太多次每次听到都有种说不出的不安。日活确实涨了但它可能是靠几场烧钱活动砸出来的那些被活动带来的用户完成一次任务之后就再也不会点开App。公司视角喜欢看增长留存转化这些一眼能看懂的数字但如果对指标的理解只停留在涨了就行就会陷入一个尴尬的处境你优化的是指标不是业务。我认识一位做电商产品的朋友他们当时定的考核大指标是支付转化率为了把这个数字从一个不健康的低位拉起来团队做了大量让用户更容易下单的动作减少确认页的步骤默认勾选优惠券甚至把再次购买按钮的冷启动做得极其顺滑。转化率确实漂亮了漂亮到老板在全员会上点名表扬的地步。但翻看另一个维度的时候我朋友发现退货率环比上升了40%因为那些被无脑顺滑流程吸引来的用户买完之后冷静下来发现根本不是自己想要的那个尺码、那个色号。指标优化如果脱离了对用户在真实场景中为什么做这一步的理解就是在把沙子堆成塔。等你觉得塔够高了一个浪打过来连地基都要重新挖。3.2 这个功能公司需要做视角单一时的资源黑洞还有一类情况更让人头疼就是自上而下的公司视角不讨论任何用户行为数据直接拍脑袋下了个这个东西战略上必须做的判断。我在前公司亲历过一个大项目高管判定我们必须拥有自己的社区内容生态于是三个前端、两个后端、一个算法工程师、一个设计外加一个专职的产品经理整整投入了8个月契而不舍地往里面塞资源。中间有好几次我们做了一版原型拿去给用户测反馈非常冷淡但上面觉得这个方向是长期主义的短期用户不理解很正常。长期主义这句话本身没有错但它不应该是拒绝沟通的挡箭牌。一个真正值得投入的方向哪怕用户当下不理解也一定存在某种中间形态可以验证底层假设。如果连最小规模的实验都不愿意做那就不是信心而是回避现实。公司视角的最大盲区在于它擅长计算做了能获得什么却很少认真计算不做会失去什么更不愿意承认某些投入其实从一开始就不该发生。3.3 数据会说谎样本偏置与生存者偏差我在另一个团队做推荐系统优化的时候深刻体会到数据驱动这四个字有多容易被滥用。我们当时用A/B实验验证一个新版的推荐排序算法实验结果非常漂亮点击率、人均浏览时长双双提升顺利全量上线。但上线一周后内容投诉率突然上升了70%。查下来发现新版算法特别擅长推荐那些猎奇、擦边、情绪极端的内容因为这些内容的点击率天然就高。用户确实点了但点完之后觉得恶心、不信任平台。这是典型的标签困境你把点击率当作用户满意的代理变量但点击率只能代表好奇心被触发它完全不能代表用户感到被尊重、有价值。这个结论一旦被算法放大它就会越来越偏直到把整个生态带向一个危险的方向。公司视角的问题不在于是不是看数据而在于有没有勇气承认我的数据选错了。如果一项指标背后没有对齐到用户为什么要使用这个产品的真实动机它最终会把团队带到一个表面辉煌、实际脆弱的位置。3.4 只看大盘数据看不到真实用户的样子最后一种公司视角的僵化是平均数思维。我们的用户平均年龄27岁平均月收入一万二平均每天使用时长45分钟。听起来很硬核对吧但如果你去过用户访谈现场你会发现这些平均数背后站着一群完全不同的人有凌晨三点起来喂奶的宝妈有一边写代码一边刷手机的程序员有刚退休在家无所事事的大叔。他们使用产品的动机、路径、情绪完全不一样却被平均两个字抹平了所有差异。我在一次访谈中遇到一位用户他说我每天打开你们App就是为了看那两条固定栏目其他东西对我来说全是噪音。这位用户在产品大盘数据里只是一个普通的日活数字但对这位用户的真实体验来说他的噪音部分与核心部分的比例直接决定了他是留下来还是卸载。公司视角如果只看平均数就会把资源配置在大多数用户的交集上但这交集往往是最没有惊喜感、最没忠诚度、最容易被替代的部分。4. 可落地的平衡方法我从30多个需求评审里提炼出的一套判断框架说完了两个视角各自的失灵场景你可能会觉得这也不行那也不行那到底该怎么办我在大概30多个需求评审、产品迭代、运营策略的拉锯战里慢慢练出了一套自己的判断框架。谈不上什么高深理论但每一次丢到真实业务里都能让会议室里的争论从我觉得用户怎样怎样变成我们可以先怎样测试一下。4.1 用双层清单把两个视角翻译成同一句话第一步拿到任何一个需求或策略提案时不要急着讨论做不做而是先分别回答两个问题用户视角这个需求背后用户想完成的那个核心任务是什么公司视角这个需求背后公司想验证的核心假设是什么然后把两个答案写在同一张卡片上试着找那句能把两者都装进去的共同表述。举个例子。之前有人提了个功能用户主页增加访客记录功能理由是用户想知道谁看过我。这个需求如果只从用户视角看很容易被定义成增加用户安全感然后陷入隐私对不对的伦理讨论。但如果用双层清单翻译一下用户的核心任务是我想在社区里感知自己的存在感公司的核心假设是如果用户能感知到被关注他的回访频率和内容发布积极性会提高。这样一翻译真正要做的就不是访客记录这一个具体形式了而可以是互动提醒内容被点赞后的小动画关注我的人列表——任何一种能提升被认可感的机制都可能达到同一个目标。这个步骤最大的价值在于它逼着双方把自己的诉求从立场下沉到可检验的假设层面。一旦落到假设层面做还是不做就自然变成了先验证哪个假设政治斗争的氛围一下就淡了。4.2 用共识判定法识别真正值得吵的需求第二个方法我在需求评审里用得最多我管它叫共识判定法。方法是把待讨论的需求放在一张二维判断矩阵里横轴是用户核心任务的依赖程度纵轴是商业目标的关键路径依赖程度。两个维度都高既是用户离不开的又是公司业务目标的支点。这种需求不用讨论直接进排期。一个高一个低引入实验思维用小流量做一个最小版本看它能不能顺带撬动另一方获得感。两个都低原则上不做因为它既没有给用户带来不可替代的价值也没有给公司带来战略意义做出来了就是消耗资源。两个都低但有一堆人坚持要做这种往往属于政治正确型需求或刷存在感型需求最好在评审会上直接追问一句如果我们不做三个月后哪个指标会受到实质性影响答不上来就砍。这个方法实际操作起来有一个注意点两个维度的打分不能只由单方拍板。用户视角的分应该由用户研究或一线运营来打公司视角的分应该由商业分析或增长团队来打两边先独立打分再放到一起对表。对表的过程常常就是矛盾公开化的过程但总比在评审会上吵半个小时才发现意见不统一要效率高得多。4.3 用机会成本替代好不好的争论评审会上最浪费时间的问题就是这个功能好不好因为好不好没有标准答案每个人都能拿出一个好的理由。我把问题改成另一个如果我们做这个我们不去做什么了这个问法背后是我亲身经历的一次教训。有一年我们同时跟进了两个方向一个是会员积分体系一个是关键路径上的新手引导重构。积分体系开发周期大概六周引导重构大概三周当时排期冲突团队里吵了很久。积分体系看起来战略意义更强因为未来可以做商业化但新人引导重构解决的是新用户次日留存差这个马上就要流血的伤口。最后我们选了引导重构理由不是积分体系没有价值而是如果这六周不做引导重构损耗掉的那部分次日流失用户未来需要更多成本才能召回而积分体系完全可以等到留存稳定之后再上。这样一算哪个优先级更高就很清楚了。机会成本思维特别适合用来调解长期价值和短期止血之争。它不否定长期价值的存在只是要求每个提长期价值的人都必须先回答一个问题为了这个长期价值我们愿意让哪个短期指标先流血4.4 搭建一个双假说实验来验证你的平衡方案如果前三个方法都走完了两边还是僵持不下别硬吵直接设计实验。双假说实验的核心思路是你不去争论谁是对的而是让两边分别提出自己那套方案可以被检验的假设然后再设计一个实验试图同时验证这两个假设的边界。举个例子。还是说那个用户反馈热烈的访客记录功能。用户侧假设加了访客记录用户感知存在感上升回访频次提高。公司侧假设访客记录会带来隐私异议增加投诉率甚至让部分用户卸载。然后我们怎么做灰度放量10%分两层看一层量用户侧指标回访频次、停留时长一层量公司侧指标投诉率、卸载率。两周之后数据出来如果用户侧假设成立、公司侧担忧没有出现那就证明平衡方案可以继续加码如果两边都被验证为假就说明这个方向本来就是错的如果一边真一边假就需要再做一轮迭代找到那个能带来用户利益但不触发公司风险的中间形态。这套方法我用了很多次最爽的一次是它帮我们砍掉了一个所有人都觉得应该做的功能——数据出来之后发现用户根本没有感知公司也没有收益只有开发时长在燃烧。5. 平衡方案做完不是结束执行落地中的三场硬仗方案在评审会上达成一致只算走完了30%。真正让平衡落到实处的是执行过程中那几场比讨论还要难的硬仗。5.1 第一场硬仗跨部门执行时的目标漂移平衡方案最怕的不是执行不力而是执行着执行着目标就变了。我们之前做过一个老用户召回计划两边的共识是目标是让6个月没有访问的老用户回来完成一次有效操作衡量一次有效操作的标准是发起一个新的内容互动。用户侧和公司侧在这个共识上都很满意。结果执行阶段运营团队为了让召回成功率这个数字更好看把触达文案改成了你有一个优惠券待领取用户确实回来了确实也领了券但领完就走了。表面上看召回成功了实际上那个用户连旧内容都没碰过。到了下一个月他又沉默了而这次他沉默的理由里还多了一条这个产品只会用优惠券套路我。这是手段替代目标的典型错误。平衡方案在讨论阶段已经厘清了什么叫成功的召回但执行团队为了局部指标的漂亮悄悄把操作定义改了。最后我们发现的时候累积已经做了三轮投放浪费了预算不说还伤害了一批核心沉默用户的信任。想要守住这场仗必须在方案启动时就把核心结果指标和护栏指标都写清楚。比召回率更重要的是召回后30天留存率和品牌好感度。任何手段如果伤害了护栏指标不管核心指标多好看都必须立刻停下重新评估。5.2 第二场硬仗用户反馈与内部数据打架时该听谁的平衡方案运行过程中最让人难受的时刻是用户反馈和技术后台的数据走向相反。有一回我们优化了注册流程把原本七步的注册压缩到了三步。后台数据显示注册转化率提升了35%平均注册时长也明显下降整体数据一片大好。但打开客服工单和App Store评论却出现零星用户抱怨你们怎么把我的账号信息都丢了我填了一半想改邮箱都找不到入口。这种时刻最容易引发判断混乱。产品经理如果偏公司视角会说数据这么好说明方向对了那几条投诉是个例如果偏用户视角会说数据再好也不是全部这几条反馈背后是一类用户没有被服务到。我的处理方式是把用户反馈按类型聚类去放大样本看看到底有没有形成模式。如果那几条抱怨只是极少数个体在特定设备上的体验问题那就当bug修而不是推翻方案如果能看出一个群体比如老年用户群、不熟悉智能设备的用户群在同一步骤上普遍卡住那就说明这个简化动作确实伤到了一部分人需要做条件分支——为不同能力层次的用户提供不同密度的引导。平衡并不是谁有理听谁的而是谁代表的群体更大就优先优化谁同时保证不被优先的群体也能走通。5.3 第三场硬仗平衡点会随着版本迭代不断漂移最后一点可能最反直觉今天看来完美平衡的配比下周就可能失衡。平衡不是静态的。用户成熟度在变竞品格局在变公司本身的战略周期也在变。当前这个平衡点只适用于当前的业务坐标。我们有过一个很惨的教训做内容社区时早期我们拿用户视角为主、公司视角为辅大量补贴优质内容生产者社区氛围出奇地好。但到了需要商业化的阶段公司视角比重必须上一个台阶结果刚调高广告密度核心创作群体就开始流失。中间大概经历了一个季度的反复横跳才重新找到一个用户和广告主都能接受的中间档位。从那以后我养成了一个习惯每次版本迭代都要重新做一次双层清单的对表而不是默认上一个版本的决策逻辑还有效。公司战略换了赛道用户群换了画像老平衡就一定会被打破早点承认这个事实比硬撑着旧方案体面得多。6. 平衡的本质是动态调节不同产品阶段有不同的配速做了这么多年的产品相关的工作我最大的感受是用户视角和公司视角的平衡从来不是什么悟了道理就会做的事而是一套需要反复练习的肌肉记忆。如果把产品当成一辆车用户视角是方向盘公司视角是仪表盘。没有方向盘你根本不知道往哪儿开没有仪表盘你都不知道油箱还剩多少油。但关键不在于方向盘重要还是仪表盘重要而在于不同阶段你的脚该放在油门上还是刹车上。初创期的产品用户视角的权重应该更大。这个阶段产品还在寻找核心场景用户反馈几乎是你唯一的光源如果过早用商业指标把自己框起来极容易做出数据合格但没人爱用的伪产品。成长期的产品两个视角的权重开始向着三七开或四六开摆动。你要一边用商业指标验证产品是否有持续创造价值的能力一边持续打磨用户核心路径上的体验因为这一阶段的用户增长往往伴随着体验稀释平衡动作最频繁。成熟期的产品公司视角的权重会进一步上升但上升的前提是你已经有了足够的用户洞察积淀知道什么能改什么不能改而不是真的把用户当成了可以随意调整的活跃数据。每一个阶段切换的时候团队里都会出现一批立场摇摆型同事他们在评审会上强烈拥护用户视角在执行会上又坚定支持商业指标。这种人不一定是墙头草可能是真的还没找到自己的判断锚点。我这里分享一个最简单的心法也是我这几年的实操体验每次做决策前先问自己一句——如果我是这个产品的唯一负责人我会希望三个月后回头看这个决策时给出什么样的评价这个问题逼着你同时站在用户是否受益和公司是否有收益两个时间轴上审视自己而不是被当下会议室里的气氛左右。7. 最后一次次踩坑之后我总结出的三个可复用原则写到这里感觉该做个收尾了。我不打算用什么一套方法论解决所有问题的漂亮话因为平衡这件事本身就没有一劳永逸的解法。我只分享三个我反复用、反复被验证的原则希望能给你一些参照。7.1 原则一平衡的前提是双方都在说同一种语言用户视角和公司视角打架有九成情况是语言的错。用户说我想要的时候他表达的是情绪和场景公司说我们需要的时候他表达的是数值和路径。这两种语言如果不在同一个层面讨论永远只是互相撞墙。把用户的话翻译成核心任务把公司的话翻译成关键假设再放到一起对比戏剧性的矛盾会消解大半。不是因为其中一方错了而是因为翻译之后你会发现大家在说的根本不是同一件事。7.2 原则二宁可要持续迭代的粗糙不要一步到位的完美很多人对平衡的想象是找到一个完美的配比然后照着执行。但真实业务里完美的平衡点根本不存在市场在变用户在变财务在变你只能做到在当下这个时点这个方案是两边都能接受的次优解。接受次优解这个概念能让你避免两个陷阱一是过度分析导致永远不上线二是因为害怕调整幅度大而干脆不做任何动作。正确的节奏是小步快跑每一个版本都在对表发现问题立刻校准接受平衡不是一个结果而是一条逼近的路径。7.3 原则三平衡不是产品经理一个人的事它是一套组织能力最后这点可能已经超出了方法的范畴但它是所有平衡讨论里真正的底牌如果用户视角和公司视角的冲突最终只能靠某个产品经理在评审会上会来事来解决那这个组织本身就没有长出平衡的能力。理想的状态是每一个指责你们为什么不顾用户的人都能回答出这个指责背后的数据证据每一个说我们要为数据负责的人都能说清这个数据指标和用户真实体验之间的因果链条。当每个人都能为自己的立场提供可检验的证据会议室里的吵就变成了实验设计里的讨论。我特别想对刚入行不久的从业者说一句你一定会经历那种两边都觉得自己是对的只有你夹在中间的时刻。别害怕那个时刻它恰恰说明你在同时看见两个真实。那种谁都不得罪的产品多半没人爱用真正活得久的产品都经历过无数个让人血压升高的取舍瞬间然后活下来了。
返回列表