--- title: "MVP 用法偏离预期，该转型还是改流程？Offlinery 案例" canonical: https://wavect.io/zh/blog/mvp-pivot-or-change-user-flow/ language: zh description: "用户绕开了 MVP 预设的路径，下一笔开发预算该花在哪？Wavect 产品团队借 Offlinery 客户项目复盘一次取舍，说明怎样区分需求变化与使用顾虑，以及该观察什么结果。" image: "https://wavect.io/img/blog/headers/header_mvp-pivot-or-change-user-flow.png" author: ["Kevin Riedl"] published: "2026-11-11" updated: "2026-11-11" reviewed: "2026-11-11" --- # MVP 的实际用法偏离预期，该转型还是改流程？ [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 5 分钟 阅读 · 2026年11月11日 最近审核 2026年11月11日 [**下一篇**](/zh/blog/product-factory-kills/) 要点速览 先追踪用户绕开某个步骤之后做了什么。如果他们仍想达成原来的目的，可以先改动卡住的那一步。我们协助客户开发 Offlinery 时，有些人在收到附近匹配提醒后先发消息，再当面见面。我们和客户保留了线下认识的产品定位，让被搭话的人决定，对方能否在走过来之前先发一两条消息。 我们协助客户开发 Offlinery 时，原本设想，一条附近匹配提醒就能让人鼓起勇气，走过去打招呼。实际发生的一个细节改变了我们和客户的判断。有些人收到提醒后先写了几句话，临时约好在哪里喝杯咖啡，才过去见面。双方都在附近，为什么还要多这一步？ 这个区别关系到下一笔开发预算怎么花。把产品改成以聊天为主，团队就得围绕持续的线上对话做设计。保留当面认识的目标，团队要解决的则是一个更小的问题：让人知道此刻走过去，对方是否欢迎。我们和客户先做了后者。下文是我在 2026 年 11 月回顾这个项目时，对这次取舍的解释。 [Offlinery 的公开代码仓库](https://github.com/wavect/offlinery) 记录了最初的线下结识设想。应用曾在 iOS 和 Android 上发布，已于 2025 年停止运营。有关移动端如何在有限的时间内发出附近匹配提醒，可参阅 [Wavect 的 Offlinery 技术案例](/zh/case-studies/offlinery/) 。 ## 用户的哪个行为，让我们重新检查了最初的假设？ 开发前，项目团队做过一手和二手调研。我们据此形成了一个具体的假设：有些女性希望在公共场合被男性当面搭话。要把这个意愿做成产品，还得多走一步，假定双方知道彼此就在附近后，就愿意直接接触。调研中表达的意愿，回答不了这第二个问题。 按我的记忆，提醒会在双方相距约 25 米之内时出现。 [应用的偏好设置](https://github.com/wavect/offlinery/blob/681716145e03f268be24f1828b33441b842d828d/mobile/localization/en.ts#L91-L105) 允许用户选择主动搭话、希望被搭话或两者皆可，也可以限定时段。有些人却对陌生人能知道自己就在附近感到不安。另一些人先通过消息确认地点或当下是否方便，随后真的见了面。这后一个动作，是我们决定保留线下认识这一目标的依据。 ## 我们和客户改了哪一步？ 我们把决定权交给被搭话的一方。想让对方直接过来的人，可以在见面前关闭消息。希望对方先问一声的人，可以允许对方在走过来之前先发一两条消息。两种方式通向同一次当面认识，也让个人可以自己决定接受怎样的接触。 | 接收方的偏好 | 走过来之前 | 当面认识之后 | | --- | --- | --- | | 希望对方当面打招呼 | 可以关闭消息，把第一声招呼留在现场。 | 双方可以再通过应用联系。 | | 希望对方先问一声 | 可以先交流一两条消息，确认是否方便。 | 双方同样可以继续联系。 | [应用内的新手引导](https://github.com/wavect/offlinery/blob/681716145e03f268be24f1828b33441b842d828d/mobile/localization/en.ts#L365-L370) 举过一个见面后留言的例子。两个人聊完，分别后才想起忘了交换电话号码，这时可以补上一条消息。见面前那一两条消息解决的是另一个时机问题：人已经看见了，现在走过去合适吗？ 安全顾虑也影响了这个决定。想主动搭话的用户要和项目团队通话核验身份。产品支持事后评价，团队可以根据反馈调整匹配或处理账号。 [当时的应用文案](https://github.com/wavect/offlinery/blob/681716145e03f268be24f1828b33441b842d828d/mobile/localization/en.ts#L313-L322) 也说明了核验要求。核验可以帮助了解对方是谁，至于此时此地是否愿意被接近，最有资格回答的人仍然是用户本人。 ## 用户多走一步，是为了做什么？ 做下一轮开发计划前，可以把最近一次偏离预期的使用经过写成三行。第一行记用户当时想办什么事，第二行记他绕开了哪一步，第三行记他随后实际做了什么。以 Offlinery 为例，“多发了一条消息”只填了第二行。知道两个人随后约好去喝咖啡，团队才有依据决定该把功能做到哪里。 ## 哪些观察值得让团队重新分配开发预算？ | 实际观察 | 下一步验证 | | --- | --- | | 用户仍然达成了原定目标。 | 问多出来的那一步解决了什么顾虑。如果它只是帮人确认时机，就先试一项范围有限的调整，并保留原来的路径。 | | 用户用同一个功能完成了另一件事。 | 找几位有类似经历的人，了解他们原先用什么办法解决，并观察下一次是否还会这样做。这个新用途有了重复出现的证据，才值得为它重新安排产品方向与预算。 | | 只知道用户点过什么。 | 先补上后续行为。请用户复述最近一次经历，尤其是离开应用后做了什么。愿意尝试某项功能，与实际回来使用或愿意付费，是不同的问题。 | 在双边产品里，发起动作和承受这个动作的还可能是两个人。只向发信方了解写消息的原因，很容易漏掉收信方希望自己决定的事。这是我们做 [产品需求探索](/zh/software-development-guide/what-is-a-discovery-phase/) 时会分别访谈双方的理由。关于如何取舍接连不断的功能要求，我们也写过 [产品团队如何走出功能堆砌的困境](/zh/blog/product-factory-kills/) 。 ## 怎样判断流程调整是否值得保留？ 如果今天再评估这项改动，我会从所有已发出提醒的附近匹配开始，请双方分别、自愿反馈两个问题：你们当面说上话了吗？对方走过来时，你觉得自在吗？只从第一条消息开始统计，会把选择直接打招呼的人全部漏掉。没有回复的人应单列为结果未知。 两种模式是用户自己选的。即使之后算出两组的见面率不同，也要考虑各自原有的偏好。关于 Offlinery，我们能确认的是有人在简短交流后见了面，以及团队据此改了产品。我们没有可公布的前后对照数据，用来估计这项改动多促成了多少次见面。 如果你正在决定下一轮 MVP 预算该投给新方向还是现有流程，可以带上最近几次使用记录， [和 Wavect 讨论一次具体的产品取舍](/zh/contact/?intent=software-dev) 。有用的起点是一段完整的使用经过，包括用户离开屏幕后做了什么。 评估下一笔开发投入时，可以把最近一次完整的使用经过带进 [产品需求探索讨论](/zh/services/software-discovery/) 。 ## 关于 MVP 方向与流程调整的常见问题 ### 哪些信号值得让团队重新考虑 MVP 的方向？ 用户一再借产品解决另一类问题，并且会主动回来继续这样使用，就值得把新用途单独拿出来验证。先弄清他们现在为这个问题付出什么，再决定是否调整产品定位与开发预算。 ### 为什么 Offlinery 只开放了见面前的一两条消息？ 一些人想在走过去之前确认对方是否方便，随后仍然当面见了。我们和客户先满足了这一步，并让偏好直接见面的人关闭事前消息。 ### 上线之后，可以把消息数量当作用户需求得到验证的依据吗？ 消息量说明有人用了这项功能。要判断它是否解决了最初的问题，还要了解双方后来是否当面交谈、是否欢迎这次接触，并把没有反馈的情况单独记录。 ### 一个操作涉及两个人，该让谁来决定？ 先弄清谁会承担对方贸然行动带来的后果。在 Offlinery，决定是否先接收消息的是被搭话的人。 ### 产品负责人在讨论下一轮预算之前要准备什么？ 带来一次最近的真实使用经过，写明用户想完成什么、怎样绕开预设步骤、随后做了什么，以及还有什么无法确认。这样团队可以围绕一个具体的投入决定展开讨论。 产品战略 ## 接下来读什么 范围、产品市场匹配、可信版本与打造有用产品的关键决策。 [从这里开始**一条可衡量的产品市场契合之路**](/zh/blog/road-to-product-market-fit/) - [AI 编程需求要写多详细？瀑布开发会回来吗？](/zh/blog/ai-waterfall-upfront-planning/) - [ChatGPT 搜索控制台：Business Hub 能测什么，企业现在该做什么？](/zh/blog/chatgpt-search-console-business-hub/) - [企业软件：让 AI 写代码前，先解决业务规则冲突](/zh/blog/enterprise-business-rule-conflicts/) - [Scope 与 Armature：衡量智能体 API 采用，而不只是品牌提及](/zh/blog/scope-vs-armature-agent-api-adoption/) - [AI MVP 范围：验收标准、评测集与 SoW](/zh/blog/ai-mvp-scope-template/) [下一篇文章**AI 编程需求要写多详细？瀑布开发会回来吗？**](/zh/blog/ai-waterfall-upfront-planning/) [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 5 分钟 阅读 · 2026年11月11日 最近审核 2026年11月11日 [**下一篇**](/zh/blog/product-factory-kills/)