立即登入 做产品刚好满一年。这段时间，我基本是在实践和复盘之间来回打转。比起摸索什么万能方法论，更真实的感受是：在一次次的试错里，慢慢攒出一点属于自己的产品直觉。前阵子聊到“惰性思维”对产品经理的消耗，很多人深有同感。如果缺乏扎实的业务逻辑，很容易陷在需求堆砌和惯性执行里，甚至开始怀疑自己走的路对不对。
最近我在跟进一个G端的大数据监管项目，正好想借这个机会，跟入行三年左右的同行聊聊一个老生常谈却极易踩坑的概念：MVP。很多人习惯把它当成“砍需求、做减法”的捷径，但在政务或企业级这种复杂业务里，照搬这套逻辑，往往会让产品一开始就跑偏。
这个项目的初衷很直接：用数据手段规范执法行为，实现全过程监督。顺着这个目标，业务链条自然摊开成五块：风险识别、分类审查、纪律问责、整改考核，最后是奖惩闭环。刚接手时，甲方很痛快，直接梳理出三十多个风险点清单。作为新人，我当时的第一反应很直接：赶紧排优先级，做减法。我搭了个简单的评分模型，按痛点程度、数据获取难度和开发成本打分，挑出分高的先做。两个月后，系统雏形出来了，赶出了二十七个风险点，顺利进入试点。那阵子各级领导来视察，兄弟单位来交流，表面上看一切都很顺理成章。
但试点反馈很快给了我一记闷棍。一线人员抱怨数据不全、监督形同虚设，大量风险数据误报乱报；业务部门觉得系统就是个“扣罚工具”，一点服务感都没有；甚至有人直白地说“这平台根本没法用”。站在试点现场我才突然醒过味来：之前的路完全走窄了。我们只顾着按分数切需求，却忘了B端或G端产品最核心的命脉——业务流和服务链。
回过头看MVP。《精益创业》里提到的这个概念，本意是用最小成本验证核心假设。但在ToB或ToG的语境里，很多团队会下意识把它等同于“功能缩水版”。我早期的设计看似分阶段交付，实际上只是把需求切碎了，根本没跑通业务闭环。B端产品的本质是工作流协同，它服务的从来不是单个角色，而是一整条业务线。吃一堑长一智，我把B端场景下的MVP重新理解成了“最小可用服务闭环”。也就是说，哪怕功能再精简，也必须完整覆盖业务链条上的关键角色，让每个参与方都能在自己的节点上顺畅跑起来，产品才算真正“可用”。
想通这一点后，我彻底调整了后续的节奏。不再贪多求全，而是挑了一个业务逻辑相对清晰的监管品类作为切口。围绕这个品类，我梳理出三类核心干系人：责任主体、监督主体和考核奖惩主体，系统必须同时兜住这三方的基础诉求。功能设计上也不再孤立地做“风险预警”或“数据报表”，而是强制补齐从风险识别、预警推送、异常核查、整改反馈到归档统计的全链路节点。看似只做了一个细分品类，实际上已经搭出了一个完整的服务闭环。这时候再去推试点，阻力明显小了一圈。
这种打法带来的变化很直观。系统上线后，我们只在固定的几个县区和特定业务部门里做小范围验证。门槛降下来了，跑通的速度反而快了。业务人员能直接在系统里完成日常工作，不再觉得它是个额外负担；给领导汇报或做演示时，也能清晰展现一类业务从发现到处置的完整路径，系统价值一目了然。更重要的是，这个轻量级的闭环成了后续迭代的骨架。之后每次加需求、扩品类，都不用推翻重来，而是沿着已有的服务链路自然延伸。设计成本下来了，系统的稳定性反倒上去了。
回头看这一年的踩坑经历，我越来越确信一件事：做B端或G端产品，MVP从来不是“功能残缺版”，而是“服务闭环版”。它得能串联起业务参与方，能嵌进具体执行人的日常操作里，也能让决策者看到清晰的治理成效。入行头三年，人很容易急于求成，迷恋大而全，或者被进度压力和惯性思维推着走，盲目堆砌功能。其实不妨把步子迈小一点，先老老实实跑通一条完整的服务线，再去考虑扩展。产品这条路还长，少一点惯性执行，多一分对业务流的敬畏，路自然会越走越稳。
