今すぐログイン 我们在上一篇文章里聊过一套结合 SCQA 模型的期望管理七步法，当时主要是放在职场沟通的场景里讲。但说实话，这套方法能用的地方远不止写邮件、汇报、谈协作，放到产品设计这种需要平衡多方诉求的场合，同样好使。
为了把这件事说清楚，我打算用一个真实的产品案例，把整条拆解过程摊开来看。同时，为了确保后面验证原型的有效性，我会借用 IDEO 设计思维里关于“试验”的几个核心原则，来帮我们控制目标。IDEO 这套方法特别强调尽早做出一个可体验的版本，刻意控制变量，用最小的成本去拿真实的反馈。这样一来，在 SCQA 的框架下，我们就能为那些看起来很难推进的需求，设计出一套低成本、轻量又容易衍生迭代的验证方案。
一个让人头疼的机票搜索需求
这个案例来自机票垂直搜索业务。在往下展开之前，有必要先简单交代一下机票搜索和预订的业务特点，不然有些关键难点很难理解。
机票业务本质上是个数据驱动型的生意：用户搜索量巨大，但真正下单的转化率其实很低。而且机票是全球分销，价格数据瞬息万变，实时查询的成本非常高。分销平台必须在“实时查询”和“用缓存数据暂替，再二次验价”之间找到一个平衡点。更关键的是，上游机票数据供应商给出的合作条件通常很苛刻，比如验订比要求达到 500:1——也就是说，每查询 500 次，就必须产生 1 次真实的交易。如果长期达不到这个比例，上游可能直接关掉数据接口，查询成本会瞬间飙升，甚至面临巨额罚款。这些硬约束，是后面所有讨论的底色。
业务推广初期，我们收到了一些种子用户非常明确的反馈。他们希望能在首页搜索时就直接选择出行人数，因为很多人确实需要多人同行，订票时往往不是一个人。而当时市面上大多数机票 App，首页都只能搜单人，等到选定航班、进入填写信息页面之后，才能去修改出行人数。问题就出在这里：一旦修改人数，经常会出现余票不足或者价格突然变了的情况，之前花时间挑好的航班全白费了，体验很糟糕。
这里需要特别补充一点：一次买 N 张票和一次买一张票，在真实的业务逻辑和价格关系上，绝不是简单的 N 倍线性放大。多张票涉及库存占位、运价规则、舱位组合等复杂因素，背后的成本结构完全不同。
既然种子用户多次反馈，这个需求自然就被提到了产品评估会上。但初步讨论下来，大家发现事情没那么简单，主要有三个风险点。
第一，搜索负荷风险。如果在首页入口直接放人数选择，很难判断用户是不是真的需要多人同行，点击率很可能被拉高，但后台搜索量会直接翻倍，压力陡增。第二，数据成本风险。如果对这些搜索都用实时数据去匹配，验订比可能瞬间掉下来，触发供应商的惩罚机制，成本会变得不可控。第三，需求有效性风险。基于前两点，这个需求到底是不是真需求、规模有多大，我们根本没法验证，因为成本太高，根本不敢直接上线去试。事情似乎一下子就卡住了。
用七步法重新审视，找到破局点
种子用户的反馈不能轻易放弃，但硬上又不现实。这时候，期望管理七步法就派上了用场。我们试着一步步拆解，看能不能在体验和成本之间找到一个合理的平衡，或者至少先低成本验证一下这个需求到底值不值得做。
第一步，先理清利益相关者的角色和期望。种子用户这边，他们是机票产品的核心客户，诉求很可能代表着一类真实的痛点：希望首页就能选人数，并且保证后续看到的机票信息始终是实时有效的，不想白白浪费时间。机票团队这边，一方面要维护好种子用户关系，对反馈做出妥善回应；另一方面，必须识别需求的有效性，用合理的方式满足真实需求，同时把技术、业务成本控制在可接受范围内。
这样一来，双方的期望冲突就很明显了：用户要好体验，团队要低成本。直观上，这几乎是一个零和博弈——给用户方便的多人搜索，业务成本就会激增。
那么，真正需要解决的问题，其实就变成了：怎么在现有条件下，用尽可能低的成本，去满足用户的需求，或者至少部分满足、或先验证需求的有效性。没有哪个团队不想把体验做好，但前提是方式得可控。
第二步，重新审视各方的真实期望。我们让产品团队回到原点，扪心自问：如果用户真的需要预订多人同行机票，那我们必须提供便捷可靠的服务，这点毫无疑问。但成本的底线是，应该在筛选出高转化意愿的用户（或关键流程节点）时，再去提供实时验价数据，这样成本才可控。顺着这个思路，我们发现，当用户走到第四步——填写信息、准备提交订单时，团队的真实期望其实已经演变了一版：既要满足用户在首页能搜多人同行的直接心理需求，又要在用户进入提交订单环节时，给出实时的验价数据。好像有转机了，关键在于怎么不露声色地实现。
第三步，找出相对弱势的一方。在需求响应层面，产品团队显然是弱势方，因为用户需求摆在那里，我们不能不做。但换个角度看，种子用户其实是信息不对称层面的弱势方。他们根本不知道后台的业务逻辑有多复杂，不知道搜索一次背后要消耗多少成本。这种信息不对称，恰恰给了我们操作空间：只要在前端感知层面，让用户觉得需求被完整满足了，后端可以完全按照更稳妥的逻辑来走。
第四步，引导相对弱势一方的期望。对于产品团队，原来“主页不支持多人搜索”的预期，可以被引导为“在识别出高转化行为时，提供便捷可靠的多人查询功能”。对于种子用户，原来“首页和页面都要方便可靠地搜索和预订多人机票”的期望，可以被引导为“首页可以选人数，但列表页暂时按单人展示，到必要的页面再获得实时验价”。这并不违背用户的核心诉求，只是把资源用在了刀刃上。
低成本、可验证的解决方案
综合下来，我们给出的方案非常轻巧，改动范围极小，但足以撬动全局。
首页增加一个搜索人数的选择按钮，让用户能选，这在心理上已经极大满足了他们的预期。但后台记录这个人数后，并不带入搜索——机票列表的搜索和返回结果，仍然按 1 个成人处理。这样一来，搜索负荷和数据成本完全没有增加。当用户选定航班，进入填写信息并提交订单的页面时，再把之前选的人数条件带进去，进行实时验价。这时用户看到的价格和余票，就是对应多人出行的真实数据，之前那种“填完变价”的糟糕体验被彻底解决了。
同时，我们通过埋点，观察首页多人搜索按钮的点击率，以及最终有多少用户真正走到了下单成交，来验证这个需求到底是不是一个实实在在的、有规模的场景，为后续要不要做深度优化提供事实依据。
方案上线后，效果超过预期：成本完全可控，开发工作量很小，而且成功响应了种子用户的诉求。更重要的是，多人同行机票的预订转化漏斗得到了有效优化，我们拿到了关键的行为数据，为这类需求的有效性验证和后续迭代打下了坚实的基础。
写在最后
结合 SCQA 模型的期望管理七步法，给职场中的意见分歧和产品设计里的需求错位，提供了一种新的解题思路。它让我们不再浮在表面争吵“做不做”，而是结构化地去看清业务本质，深挖用户需求背后真正的妥协空间。很多时候，问题的解法不是硬碰硬，而是找到那个信息不对称的缝隙，用最小的成本把期望拉到一条双方都能接受的线上。
希望这个案例能给你带来一些启发，共勉。