梦老师做产品这么多年，我听过最多也最容易翻车的一句话就是“我们要明确目标用户”。每次立项评审，PPT第一页都写着目标用户，可一旦追问下去——“他们现在怎么解决这个问题”“你见过几个真人”“他们为什么非用我们不可”——多半就开始含糊了。先讲一个让我印象极深的复盘：一个团队花了半年做了一款团队知识管理工具，功能覆盖搜索、标签、自动归档、AI摘要、审批流，上线三个月，日活长期个位数。最讽刺的是，团队的日常工作是帮企业做数字化咨询，工具没人用，客户问起来都不好意思打开。
后来我们不聊功能，只做了一件事：重新定义目标用户。选了一个最不起眼的切入点，把整个产品逻辑推翻重做。四个月后，日活翻了十几倍。这个过程让我确信：明确目标用户不是产品经理文档里的一行描述，而是决定功能取舍、交互细节、运营节奏甚至数据指标的一整套判断标准。这篇文章不讲大道理，就围绕“做产品，要明确目标用户”这句朴素结论，拆一拆我踩过的坑、验证过的方法，以及怎么让这个认知真正落到团队每一天的决策里。
1. 复盘“功能很全却没人用”的知识库产品：问题不在功能，在用户定义
1.1 当初我们是怎么定义目标用户的
那个知识管理项目的痛点很清晰，绝大多数公司内部知识都是散的：文档在钉钉群里、结论在会议纪要里、经验在离职同事的脑子里。我们做的产品想解决的就是“企业知识找不到、留不住、传不下去”。
问题出在我们给目标用户下的定义上。立项报告里我们写的原话是：“面向所有有知识沉淀和检索需求的职场人群，帮助企业构建统一知识库。”听起来覆盖面广、市场空间大，但落到执行层就是灾难。因为“所有有需求的职场人”不是一个用户画像，而是一个购买力为零的统计学概念。
更麻烦的是，产品设计团队为了满足这个宽泛定义，悄悄做了加法：既然研发团队需要技术文档检索，那就加代码片段收藏；既然销售团队需要话术沉淀，那就加 SOP 模板；既然管理层需要了解团队产出，那就加上审批流和数据看板。半年做下来，产品像一个“大而全的管理系统”，没有一个角色觉得它是为自己设计的。销售觉得流程太重，研发觉得搜索不精准，管理层觉得看板数据根本没有权威来源。所有人都觉得“这产品有点用，但不是给我做的”。
1.2 复盘清单：从日活惨淡倒推真正的主用户
这是个很好的反面教材。当时我们做了一次深度复盘，不找外部原因，只问一个问题：如果只能服务一个角色，让这个角色“离不开”我们，应该选谁？
我们把曾经写进需求池的候选用户列了个表，逐一过他们的使用场景：
- 研发工程师：想要的是代码片段和架构决策记录，但这类人搜索习惯极强，往往用 GitHub、语雀或者自己的本地笔记就解决了，没有强迁移动力。
- 销售/客户成功：需要话术库、报价方案沉淀，他们的痛感最明显但也最常被“企微群聊记录”凑合着解决，工具使用能力弱，教学成本高。
- 项目交付顾问：刚服务完一个客户，有大量交付物要整理沉淀，且公司考核要求他们输出案例，他们有人力和意愿整理知识。
- 团队 leader：最想看到团队知识资产沉淀，但他们自己不生产内容，是“受益者”而不是“使用者”。
复盘越做越清楚：谁是使用者，谁是受益者，谁是买单者，这三者不一致让我们犯了两个致命错误。第一，我们把产品重点服务给了“受益者”（管理层），做了管理端看板和审批流，但这部分人一周都不会打开一次工具。第二，我们把UI和交互设计成“通用办公软件”，结果对真正高频使用者（项目交付顾问）来说，录入成本高、查找路径长、价值回收慢。
在这个项目上花的时间没有白费。我们把所有功能重新按角色做了归属分析，最后砍掉了三个管理向模块，重构了录入和查找逻辑。那个月我们验证了一个极其简单的判断：要让产品被记住，必须有一个角色使用它的频率高到形成肌肉记忆。高频率，强痛点