这两年，AI编程工具让软件开发的门槛一降再降。一个懂业务的人，借助大模型，几天就能搭出一个可运行的原型。这本来是好事，但一个奇特的现象出现了：产品功能越来越容易做，MVP（最小可行产品）却越来越难收敛。
我最近看到一个产品复盘，讲的是一个动物医疗AI产品的演变过程。从最初只想做一个AI病历草稿工具，到后来逐渐加入护理说明、用药审核、鉴别诊断，甚至多个Agent协作。功能像滚雪球一样膨胀，但那个“最小可行”的边界，却越来越模糊。这让我想到，在办公自动化和效率工具领域，类似的情况比比皆是。
【技术越强，取舍越难】
过去，产品经理做取舍，很大程度上受限于技术可行性。有些功能不是不想做，是做了成本太高。但现在，Vibe Coding这类开发方式，让技术实现变得异常廉价。你只要描述清楚需求，AI就能生成代码。于是，产品经理的思维从“这个功能能不能做”变成了“这个功能要不要做”。
听起来，后者是更高级的问题。但现实是，当所有功能都“容易做”的时候，人们反而更容易迷失。因为每个功能看起来都合理，每个需求都有价值，每个“顺便”都显得顺理成章。就像那个动物医疗产品，既然能生成病历，为什么不能顺手生成给宠主的护理说明？既然能读病例，为什么不能查指南？既然能查指南，为什么不能做用药提醒？
每一步都合理，但连起来，就偏离了初衷。
【“完整产品幻觉”的陷阱】
我把这种现象称为“完整产品幻觉”。技术越强，人们越容易幻想用一个产品解决所有问题。但真正的MVP，从来不是功能最全的版本，而是能验证核心假设的最小闭环。
在办公自动化领域，这个教训同样深刻。比如，一个团队想做一个智能会议纪要工具，最初核心需求是“把语音转成文字，并自动提炼待办事项”。但技术允许后，他们开始加情绪识别、发言人分析、历史记录检索……结果，MVP变成了一个臃肿的半成品，上线后用户根本不知道主功能是什么。
反观那些成功的产品，比如很多RPA工具，早期版本只做一件事：把重复性的鼠标点击自动化。功能单一，但解决了明确痛点，用户一眼就懂。
【MVP的本质是验证，不是交付】
为什么我们总想把MVP做得更大？因为潜意识里，我们把MVP当作一个“小版本”的产品，而不是一个“验证假设”的实验。
真正的MVP，应该聚焦于回答一个问题：用户是否愿意用这个方案解决他的核心痛点？其他的一切，都可以是“之后再说”的。在那个动物医疗案例中，核心假设是“AI生成的病历草稿能否被兽医采纳”。如果能，那么后续的扩展才有意义；如果不能，那么加再多功能也是白搭。
但现实是，我们在做MVP时，往往把“可能有用”的功能全部塞进去，生怕用户觉得不够完整。结果，开发周期拉长，反馈周期推迟，验证成本上升。而AI让开发变快后，这种膨胀就更容易发生，因为“做”的成本太低了，低到我们不再认真思考“为什么做”。
【把“不做”当作产品能力】
所以，在AI时代，产品经理的核心能力，可能不再是“设计功能”，而是“决定不做什么”。
对于办公自动化领域，更是如此。AI带来的自动化能力，让每个部门都希望工具能覆盖自己的需求。但作为产品负责人，你要敢于说“不”。因为每个功能都有维护成本、学习成本和认知成本。功能越多，用户越难理解产品的核心价值。
我的建议是，在写PRD时，明确列出“非目标”清单。把那些看起来不错、但并非核心假设的功能，统统写进“非目标”里。这不仅是给团队看的，更是给自己看的——防止自己在开发过程中被“顺便”带跑。
【回归本质：从问题出发】
说到底，MVP难收敛，是因为我们太关注“能做什么”，而忘了“该做什么”。技术越强大，这个问题就越突出。
在AI驱动的办公自动化浪潮中，我们更需要回归本质：用户真正的问题是什么？最小的解决方案是什么？这个方案能否验证我们的核心假设？
那个动物医疗产品，最后重新回到“AI Scribe”作为MVP，但依然忍不住加了“Ask HiPaw”的功能。这就是一种挣扎。好在，他们意识到了问题。而我们在做自己的产品时，也要时刻提醒自己：功能膨胀不是进步，收敛才是智慧。
AI让工具越来越强大，但越强大的工具，越需要清晰的边界。因为，真正的效率，不是做更多的事，而是做对的事。