我以为产品只会提需求，直到我学了 GMV

Sat, 13 Jun 2026 14:57:20 +0800

研发和产品的鸿沟，真的有亿点点大

今天学了一个产品指标：GMV。

本来以为这只是一个很普通的业务词，结果一脚踩进去，发现下面不是小水坑，是马里亚纳海沟。

我原本以为产品经理每天主要在想：

这个按钮放左边还是右边？
这个交互是不是丝滑？
这个需求研发能不能排？
这个版本什么时候上线？

后来发现，产品经理真正面对的世界，远比我想象中复杂得多。

他们不是只在画原型、写需求、开评审。他们还要理解业务、拆解指标、设计路径、判断增长、分析转化、评估商业价值，甚至要回答一个非常终极的问题：

这个产品，到底有没有创造价值？

而作为研发，我以前更多关注的是另一套问题：代码是否优雅，接口是否稳定，架构是否清晰，性能是否达标，系统是否可扩展，线上是否会炸。

这些当然也很重要。没有稳定的工程能力，再好的产品设想也落不了地。

但学完 GMV 之后，我突然意识到：研发和产品之间的鸿沟，不只是“懂不懂技术”或者“懂不懂需求”的差异，而是两种完全不同的世界观。

一、同一个需求，研发和产品看到的不是同一件事

研发面对一个需求，第一反应通常是：

怎么实现？接口怎么设计？数据表怎么建？边界条件有哪些？异常情况怎么处理？性能瓶颈在哪里？上线风险大不大？

这是一种典型的工程思维。

工程思维关心的是确定性、稳定性、复用性、可维护性。它会本能地把一个需求翻译成系统结构。

比如产品说：“我们想做一个优惠券推荐功能。”

研发脑子里可能马上开始建模：

用户表、优惠券表、领取记录表、使用记录表、适用范围、过期时间、库存扣减、并发控制、风控校验、幂等逻辑、缓存策略、灰度开关、兜底方案……

这个过程非常理性，也非常必要。

但产品可能正在想另一套问题：

用户为什么不下单？优惠券是不是真的能提升支付转化？应该发给谁？发多少面额？在哪个节点发？对 GMV 的拉动有多大？会不会只是补贴了本来就会买的用户？会不会提升了短期交易，却降低了毛利？会不会吸引羊毛党？

这时我才发现，同一个“优惠券功能”，研发看到的是实现复杂度，产品看到的是业务杠杆。

研发关心“做不做得出来”。

产品关心“做出来有没有用”。

这两件事都重要，但它们不是同一个问题。

二、产品真正难的，不是提需求，而是证明为什么做

以前我对产品经理有一个误解，以为产品的主要工作是“提需求”。

后来慢慢发现，真正困难的不是提需求，而是回答：

为什么是这个需求？
为什么现在做？
为什么不是另一个需求？
做了之后影响哪个指标？
这个指标为什么重要？
如果指标涨了，是不是说明产品成功？
如果指标没涨，是需求错了，方案错了，还是用户分层错了？

比如 GMV。

它看起来很简单：商品交易总额。

但 GMV 不是收入，也不是利润，更不一定等于真实增长。

GMV 可以拆成订单数和客单价，也可以拆成购买用户数、人均购买频次和客单价，还可以继续拆成流量、点击率、下单转化率、支付成功率、退款率、复购率、补贴率、履约成功率……

也就是说，一个 GMV 上涨，背后可能有完全不同的原因。

可能是流量变大了。

可能是转化率变高了。

可能是客单价提升了。

可能是活动补贴太猛了。

可能是刷单。

可能是大促透支了未来需求。

可能是退款还没有算进去。

同样，一个 GMV 下跌，也不能简单说“用户不喜欢了”。它可能来自入口流量、商品供给、价格竞争力、支付链路、优惠券规则、渠道质量、履约能力，甚至只是数据口径变了。

产品经理不能只看一个结果指标，还要不断拆、不断问、不断验证。

这和研发调 bug 有点像，但又完全不一样。

研发调 bug，通常是在一个相对确定的系统里找原因。产品分析问题，面对的是人、供给、价格、渠道、体验、竞争、周期、市场情绪、组织资源等一堆变量。

代码会按逻辑执行。

人不会。

这就是产品世界的复杂性。

三、研发眼里的上线，只是产品眼里的开始

研发做完一个需求，测试通过，灰度没问题，发布上线，长舒一口气：

终于结束了。

但对产品来说，上线可能只是开始。

上线之后要看数据：用户有没有用？有没有达到预期？核心指标有没有变化？新用户和老用户反应一样吗？不同渠道来的用户反应一样吗？有没有副作用？有没有伤害留存？有没有拉高投诉率？有没有增加客服压力？有没有让履约成本变高？有没有影响长期利润？

研发交付的是功能。

产品要交付的是结果。

这句话我以前只是听过，现在才有点真正理解。

一个功能做出来，不代表它创造了价值。

一个页面上线了，不代表用户会买账。

一个流程变短了，不代表转化率一定提升。

一个按钮变大了，不代表点击率一定健康。

一个活动带来了 GMV，也不代表业务真的增长了。

产品世界里，“做了”不是答案，“有效”才是答案。

而“有效”这两个字，又必须被指标证明。

四、指标不是数字，而是产品理解业务的语言

这次让我震撼的，不只是 GMV 本身，而是产品指标体系的庞大。

用户规模有 UV、PV、DAU、WAU、MAU。

增长有新增用户、注册转化率、激活率、CAC、渠道 ROI。

交易有 GMV、订单数、客单价、支付转化率、退款率、复购率。

收入有 Revenue、ARPU、ARPPU、LTV、Take Rate。

留存有次日留存、7 日留存、30 日留存、月留存、滚动留存。

体验有 NPS、CSAT、投诉率、崩溃率、任务完成率。

SaaS 还有 MRR、ARR、续费率、流失率、NRR、GRR。

内容产品还有点击率、完播率、互动率、关注转化率、人均消费时长。

这些指标一开始看起来像一堆黑话。

但深入理解之后会发现，它们其实是产品经理观察世界的坐标系。

研发看系统，习惯用模块、接口、服务、数据库、缓存、队列、日志、链路追踪来理解世界。

产品看业务，习惯用用户、场景、漏斗、转化、留存、复购、收入、成本、效率来理解世界。

所以，当研发说“这个接口响应时间从 800ms 优化到了 200ms”，产品会继续问：“那转化率提升了吗？”

当研发说“这个功能我们做了缓存，性能提升了”，产品会继续问：“用户体验指标有变化吗？”

当研发说“这个页面重构完了”，产品会继续问：“对核心路径有帮助吗？”

这不是产品在找茬。

这是职责决定的。

研发要确保系统正确地运行。

产品要确保系统运行在正确的方向上。

五、我以前以为产品在拍脑袋，后来发现他们也在和复杂性搏斗

研发经常吐槽产品：

需求天天变，逻辑不严谨，边界没想清，排期想得美，一句“很简单吧”让人血压飙升。

这些吐槽当然不是没有道理。

有些需求确实不成熟，有些方案确实没想清楚，有些产品确实会把复杂问题轻描淡写地扔给研发。

但如果反过来看，产品也有他们的难处。

他们面对的不是编译器，而是市场。

不是单元测试，而是用户行为。

不是固定输入输出，而是不确定的人性。

不是一个服务报错就能定位日志，而是一个指标掉了之后，要在一堆可能性里找真实原因。

比如 GMV 下降 10%，背后可能是流量问题、供给问题、价格问题、活动问题、渠道问题、体验问题、风控问题、履约问题、竞品问题、季节因素，甚至可能只是数据口径变了。

研发看到异常，可以查日志、看监控、复现问题。

产品看到异常，要拆指标、看趋势、分人群、跑漏斗、做访谈、猜假设、验证假设，有时候还得承认：暂时不知道。

这么一想，产品经理也不是每天坐在那里“画个框框”那么简单。

他们也在和复杂性搏斗。

只是研发面对的是技术复杂性，产品面对的是业务复杂性。

更进一步说，研发和产品的鸿沟，本质上是“确定性”和“不确定性”的鸿沟。

研发的世界当然也有不确定性。线上环境复杂，分布式系统复杂，历史包袱复杂，人写的代码更复杂。

但总体来说，研发追求的是把问题变得确定：需求明确，边界清晰，流程可控，异常可处理，系统可观测，结果可复现。

而产品的世界，很多时候天然就是不确定的：

用户会不会喜欢？市场会不会接受？补贴有没有效果？留存能不能提升？这个功能是不是核心需求？这个指标涨了是不是因为我们做对了？竞品突然降价怎么办？大促之后需求会不会被透支？

产品经理要在不确定性里做选择。

更难的是，这些选择还会消耗研发、设计、运营、市场、客服、供应链等一堆资源。

所以好的产品经理不是“想点子的人”，而是能在复杂约束下判断优先级的人。

六、研发懂一点产品，不是为了转岗，而是为了减少误判

我以前对“研发要有产品思维”这句话有点警惕。

因为它听起来很像：

你不仅要写代码，还要理解业务，还要关注用户，还要对结果负责。

打工人的负担突然又加了一层。

但现在我觉得，研发理解产品，不一定是为了变成产品经理，而是为了减少沟通损耗，也减少技术判断里的误判。

当产品说要提升支付转化率时，研发如果只看到“改页面”，就很难理解为什么这件事重要。

但如果知道支付转化率影响 GMV，GMV 又影响业务规模，业务规模再影响收入、预算、资源投入，很多优先级就更容易理解。

当产品说要做 A/B 测试时，研发如果只觉得“麻烦，又要做实验分流”，就会很痛苦。

但如果理解产品需要验证因果，而不是凭感觉上线，就会知道实验系统本身是一种决策基础设施。

当产品说要埋点时，研发如果只觉得“又加字段”，就容易敷衍。

但如果理解埋点是后续分析漏斗、转化、留存的基础，就会知道数据质量本身就是产品质量的一部分。

这点对研发也很有启发。

因为研发不应该只停留在“完成需求”。

如果能进一步理解业务目标，就能更好地判断技术方案的轻重缓急。

不是所有需求都值得重架构。

不是所有功能都需要一步到位。

不是所有系统都要追求完美抽象。

有些需求只是验证假设。

有些需求是短期活动。

有些需求是战略入口。

有些需求会变成长期基础能力。

如果研发不理解业务，就容易在不该重的地方做重，在该稳的地方做轻。

七、不要只看功能，要看价值链路

作为研发，很容易把工作切成一个个功能点：

登录模块、支付模块、优惠券模块、搜索模块、订单模块、推荐模块、报表模块。

但产品指标让我意识到，用户和业务并不是按照模块来理解产品的。

用户只有一个目标：

我能不能更快、更便宜、更放心地完成我的事情？

业务也只有一个目标：

这个产品能不能持续创造价值？

所以比“功能模块”更重要的是“价值链路”。

比如电商的价值链路可能是：

用户进入首页，看到感兴趣的商品，点进详情页，产生信任，加入购物车，确认优惠，提交订单，完成支付，收到商品，满意后复购。

每一个环节都有指标，每一个指标背后都有体验，每一个体验背后都有系统能力。

研发做的不是孤立功能，而是这条价值链路上的基础设施。

搜索慢一点，用户可能找不到商品。

推荐差一点，点击率可能下降。

支付不稳定，转化率可能崩。

库存不准，退款和投诉会上升。

优惠券规则复杂，用户可能在订单页流失。

页面加载慢，用户可能还没看到商品就走了。

所以，研发不是离业务很远。

研发其实就在业务链路里面。

只是我们以前经常只看到代码，没有看到代码背后被影响的指标。

八、真正有价值的协作，是在技术和业务之间架桥

我现在越来越觉得，研发的成长路径不只是技术深度。

当然，技术深度非常重要。

架构能力、编码能力、性能优化、稳定性治理、工程效率，这些都是研发的基本盘。

但越往后走，只懂技术可能会遇到瓶颈。

因为在真实公司里，技术方案不是在真空中产生的。

它永远和业务阶段、团队资源、用户规模、成本预算、交付节奏、长期战略绑定在一起。

一个高级研发需要能回答：

这个系统为什么要做？
现在做到什么程度最合适？
哪些地方要追求稳定性？
哪些地方可以先快速验证？
这个技术投入能带来什么业务收益？
它会提升效率、降低成本、支撑增长，还是减少风险？

如果一个研发能听懂产品指标，就更容易从“需求执行者”变成“方案共创者”。

产品说：“我们要提升 GMV。”

普通研发可能等产品拆需求。

更成熟的研发可能会问：

现在 GMV 的瓶颈在哪？是流量、转化率、客单价，还是支付成功率？

如果是支付成功率，我们可以看支付失败码、接口耗时、超时率、渠道成功率。

如果是搜索转化，我们可以看搜索无结果率、结果点击率、排序相关性。

如果是履约问题，我们可以看库存准确率、配送超时率、取消率。

这时候研发就不只是写代码的人，而是能用技术能力参与业务诊断的人。

这才是真正有价值的跨职能协作。

同样，产品也应该懂一点研发。

不是为了自己写代码，而是为了知道什么叫技术债，什么叫系统边界，什么叫历史包袱，什么叫并发风险，什么叫数据一致性，什么叫灰度发布，什么叫“这不是改个按钮那么简单”。

好的协作，不是一方完全变成另一方，而是双方都多理解一点对方的世界。

结语：鸿沟不是为了隔开人，而是提醒我们别轻易评价对方

学完 GMV 和一堆产品指标之后，我的第一反应是：

产品经理要学的东西也太多了。

第二反应是：

研发和产品之间的鸿沟，真的有亿点点大。

但第三反应是：

这条鸿沟并不是为了把人隔开，而是提醒我们，不要用自己的世界观轻易评价对方。

研发不要以为产品只是画原型、催排期、改需求。

产品也不要以为研发只是写代码、估工时、说不行。

大家面对的是同一个产品，只是站在不同的位置。

产品从用户、市场、指标和商业价值看它。

研发从系统、数据、架构和工程稳定性看它。

设计从感知、表达、路径和体验看它。

运营从流量、活动、内容和用户触达看它。

每一个视角都不完整，但每一个视角都必要。

好的产品，不是某一个角色单独做出来的。

它需要有人发现问题，有人定义问题，有人拆解问题，有人设计方案，有人实现方案，有人验证效果，有人持续迭代。

所以，今天学 GMV，看似只是学了一个指标，实际上像是打开了一扇门。

门后面是产品经理的复杂世界。

也让我重新理解了研发自己的位置。

代码当然重要。

但代码不是终点。

功能也不是终点。

真正的终点，是用户价值和业务价值被稳定、持续、可验证地创造出来。

研发和产品的鸿沟确实大。

但也正因为这条鸿沟大，愿意跨过去看一眼的人，才会拥有更大的视野。

至少现在我知道了：

下次产品再说 GMV、转化率、留存、复购、LTV、CAC 的时候，我不会只觉得这是黑话。

我会知道，这些指标背后，是他们理解业务的方式。

而我写下的每一行代码，也许都在悄悄影响其中某一个数字。

这感觉有点吓人。

但也有点迷人。

GMV on 雨的味道