痛点分析的三大挑战与应对之策

一、什么是痛点

人人都在谈论痛点：

最近做某商业银行研发改进项目的售前，无论调研哪个部门的中基层骨干，“您有什么痛点和期望”一定是调研必问的经典问题；

上一个学术出版业的产品战略项目，我们围绕着 200+ 产品痛点没日没夜的整理；

再往前的制造业业务流程再造项目，流程痛点的收集、讨论、分析、设计更是贯穿了整个项目……

然而，什么是痛点呢？

Gartner 如此定义：

Pain points are specific problems faced by current or prospective customers in the marketplace. Pain points include any problems the customer may experience along their journey.

这里有三个关键点：

1、痛点源于客户

这意味着痛点来源于目标市场的明确对象，可能是现有客户，也可能是潜在客户。

比如微信读书，一款基于微信关系链的阅读产品，当我们要调研用户痛点，且调研目标是现有产品改进，切入点应当是微信读书的直接用户，而不会从财新这样的新闻资讯平台，或者是其他产品用户入手；当然，除非从产品规划角度来说，微信读书要打新的市场，则另当别论。

2、痛点是客户遇到的特定问题

痛点是客户在旅程中遇到的各种问题，问题本身是多样化的。痛点会因为服务的客户、目标市场、业务差异等迥然不同，取决于提供的产品和服务。比如最常见的生产力痛点，不一定是所有企业的关注的痛点。对于Beeart，提高协作效率可能是首要关注点；如果这样说抖音，则过于牵强。为了深入了解客户痛点，我们往往需要设身处地思考客户遇到的特定问题，切忌一以概之。

3、痛点源于客户实际的工作体验

痛点不是坐在办公室里凭空想象、逻辑推理就能得到的。比如产品设计类项目，我们确定用户痛点的主要来源有目标用户本身，产品负责人，以及相关的销售和支持团队；咨询类项目则往往通过和高层管理者和中层骨干访谈和实地观察调研获取痛点。

二、痛点分析常见场景

从项目视角来看，以下场景往往需要痛点分析：

1、项目启动阶段（概念探索期）。如果我们一个项目的全生命周期分成问题域和解决方案域，项目启动期作为是问题域的开始，如何通过调研，挖掘隐形存在的上下文，识别痛点，定义、验证项目真正要解决的现实问题是决定项目走向，甚至成败的关键，都直接影响着我们是否在“做正确的事”。我们往往通过大量调研，对相关领域建立基本认知，与客户达成共识，为项目推进和后续的方案产出提供依据。

2、项目规划阶段（方案设计期）。当我们定义了关键问题和痛点后，往往需要通过优先级排序，从海量痛点和现状洞察中挖掘亟待解决的高价值问题，从而为价值最大化的投资决策提供依据；规划方案时，也需要从痛点出发，设计方案，综合考虑方案可行性、预期成效、能否真正缓解痛点、相关风险如何应对等等。

3、 项目交付阶段（持续运营期）。解决方案实施完成后，我们回顾方案成效，往往需要回顾痛点，审视方案落地对痛点的缓解效果是否符合预期，实现闭环。条件允许的情况下，通过对痛点的持续运营实现不断优化。

看到这里，你可能也意识到：痛点分析确为贯穿项目始终的核心之一。

三、痛点分析常见挑战

就我为数不多的项目经验而言，痛点分析总会遇到各种各样的挑战，以下三点尤为印象深刻。

挑战一： 信息量太大，如何分析痛点之间的联系？

遇到这一挑战的典型场景是，某学术出版业的产品战略项目上，我们通过两个月的访谈和调研，收集到200多条覆盖多个业务领域多个产品的痛点。当我们面对这样一块信息量爆炸的痛点画板，如何快速梳理痛点之间联系成为痛点分析的第一道关卡。

挑战二： 这么多痛点，如何进行优先级排序？

第一道关卡过后，我们往往会面临如何对痛点进行收敛的问题。经过整合，200多条痛点或许能重新组合成了50类痛点，但有限资源的情况下，如何确定高价值问题，比如优先级最高的5类问题，确保我们始终在缓解客户最剧烈的疼痛，从而对症下药，成为了当时项目的第二道瓶颈。

挑战三： 如何量化痛点？

这也是项目上客户反复提出的诉求。当时我们的观点是，痛点无法量化；因此没有在这一方向上继续深入。但从传统行业、战略规划的角度出发，无论是我们自己思考投资决策时，还是单纯为了申请预算，合理的数据推演总是强有力的论据。因此，量化痛点往往能成为胶着状态下的关键突破点和有力论据。当然，面对高度不确定性，这也是令人头秃的重难点。

以上就是我在项目上遇到的有关痛点分析的主要挑战。接下来，我想针对以上三点分享一些后知后觉的思考：如果未来遇到类似的挑战，可以如何应对。

四、通过演绎和归纳推理，分析痛点之间的联系

如果要梳理企业提供的服务现状，我们可以用服务蓝图结构化地展示用户在流程中的痛点，帮助快速建立整体认知。然而，当我们面对海量的痛点信息和复杂度较高的场景，如何进行深层联系的挖掘往往是个考验。

通常来说，分析痛点之间的深层联系有两种思路。

一种是通过演绎（Deductive）分析，带着理论假设进行分析验证（Theory/Hypothesis Driven）。

当我们带有预设的逻辑框架，可以采用这种 Top-down 的思维模式。我们根据逻辑框架进行拆解、细化，系统地收集数据，再进行分析和验证。这要求我们在对应领域有一定经验或者理论基础，对其相关的底层逻辑有一定认知，能够形成相应的假设，并且相信这种假设能作为共性规律运用在当前项目的特定场景下。

这种方法在流程再造项目上就有运用。

入场前我们准备业务流程管理现状调研框架时，有相关流程管理经验的同事能凭借自己的领域知识，很快理清流程管理问题的整体框架，抽象成五类问题。当我们带着这五类问题框架设计访谈提纲，开展调研。调研收集到的包罗万象的现状信息的确能一一纳入这五类问题中；以此为依据，也帮助我们形成了对应的调研报告。

这种模式的好处在于，如果逻辑框架足够科学，能很好地牵引我们从全局视角思考问题，帮助我们理清思路，操作起来清晰而流畅。

另一种是通过归纳（Inductive）分析，从收集的数据出发，逐渐形成假设、理论 （Observation Driven）。

当我们对相关领域不够熟悉或者缺乏整体框架认知时，往往根据项目中的有效输入，从数据本身出发，Bottom-up 地解释、验证其间的联系。亲和图就是一种典型场景，我们把收集到的零零散散的数据按照资料间的相互关系归类整理，逐渐完整，形成知识体系。

除了亲和图，编码也是一种常见的处理方式。面对来自不同业务方，涉及多个业务领域多款产品的200多条痛点，我们通过编码把访谈、文件、图片等来源的信息转换成结构化、简洁明了的信息结构，从信息本身入手，进行后续分析。

编码听起来可能有些抽象。具体来看，是一个需要不断重新定义分类的过程：

把数据标准化处理、形成书面语后，首先把数据（比如一句文本）拆分成有实际意义的单元，进而用类别名称进行标记（即编码）。这里说“不断重新定义”，是因为如果要做得精细、避免偏倚，我们需要持续审视编码的信效度。比如现有的编码体系是否有效地支持我们客观评价所有数据；又或者我们重新审视同一文本，根据同样的编码策略，是否能得到同样的编码结果……

编码完成之后，我们可以统计不同条目的出现频次，对分类编码进行分层和分析，确定数据之间的主题等，进一步分析深层联系，直至最终形成结构化框架或洞察。当然，这个过程中我们始终需要从研究问题相关内容出发，结合访谈、文件、图片来源的多种数据综合考量。

对于用户反馈的分析就可以采用这种方法。

当我们收集到大量的用户反馈数据，可以根据反馈，把相关产品、反馈类型、反馈主题、反馈代码、客户类型、客户价值、反馈来源等属性提取出来，进行结构化数据，以便后续分析处理。帮助我们进一步了解数据之间的联系，比如哪些反馈是用户最痛的，哪些对业务来说是最有价值的，从而更好地为产品演进指引方向。

五、两个关键做好优先级排序

优先级排序也是工作中遇到最多的场景之一。

面对海量痛点，如何进行排序，以确保我们聚焦在最剧烈疼痛的点上，有两个关键：

第一， 了解客户疼痛程度，和客户达成共识

我们往往通过调研收集客户痛点。比如上一个产品战略项目，我们通过服务蓝图，和客户梳理得到了 N 多痛点；也在有关会议上针对客户认为最重要的关键问题、流程中的关键阶段进行了口头确认。但是这样收集的最痛的点相对零散，难免存在主观偏倚。特别是对痛点的认知会受到当事者的个人经历、信仰立场、社会文化等多方因素影响，各人的理解也存在差异。

那么，如何对痛点尽可能理性、客观地评估呢？

医学上如果要评估疼痛，往往采用自评量表（即调查问卷）、行为测试，或者通过生理测量等进行评估。在咨询项目的上下文里，我们不妨也采用一些量表工具评估利益相关者的痛点，对痛点进行综合考虑，既使得痛点排序结果有据可循，操作起来也相对便捷。同时，“痛点诊断结果”也可以用以贯穿“痛点疗效”的始终，无论是在方案设计阶段，还是后续的方案执行、持续运营阶段，都能用来评价举措缓解疼痛的实际效果。

第二， 根据上下文，采用合适的优先级排序方法

面对资源有限的约束，我们往往需要借助通用的优先级排序规则，以确保高效、快速的价值交付。MoSCo、RICE、Kano、ICE 等优先级排序方法大家一定不陌生，但要想在优先级排序上和客户产生共鸣，让客户快速接受，还需要根据客户思维模式和习惯，选择合适的方法和评价维度。

具有产品制思维的客户，我们根据当前阶段的战略重点和产品目标，用户价值和影响，技术实现成本综合评价等排序，进行产品规划，客户比较容易接受。但是，对于传统行业的客户，比如我经历的学术出版业客户，他们往往更关注痛点的业务价值、投资回报等。此时，如何在大量的痛点和方案中，理清w选择是否是当下实现价值最大化的最优决策成为关键。

在这种情况下，延迟成本除以持续时间（Cost of Delay Divided by Duration, 简称 CD3）不失为一种合适的决策模型：通过计算相对延迟成本和持续时间来确定优先级，综合考虑价值和速度，以在最大程度地提高一定时间内的经济效益。

其中，

Cost of Delay = Value x Urgency = (User or Business Value + Risk Reduction and/or Opportunity Enablement) x (Time Criticality)

Duration = Job Size

借用 SAFe 对其中要素的解释：

“User or Business Value, 用户-业务价值——对客户或业务的相对价值是什么？我们的用户更喜欢这个吗？收入对我们的业务有何影响？如果我们延迟，会不会有潜在的惩罚或其他负面影响？

Risk Reduction and/or Opportunity Enablement，风险降低-机会启动价值——这对我们的业务还有什么作用？它是否降低了这种或未来交付的风险？我们将收到的信息有价值吗？此功能会带来新的商机吗？

Time Criticality，时间紧迫性——用户/业务价值如何随时间？有固定期限？他们会等待我们还是转向其他解决方案？受此影响的关键路径上是否有里程碑？目前对客户满意度有何影响？”

我们结合示例来看延迟成本决策可以如何应用在痛点优先级处理中。

比如，当我们从客户反馈中了解到诸如以下的大量痛点：

A：我们的服务支持做得不够好。用户通过邮件联系获取不到有效的专业支持，响应也很慢；客服电话也经常无人接听。

B：机构用户抱怨产品体验和个人用户没有不同，依旧需要经历绑定身份、邮件验证、填写个人信息等多个流程才能完成注册和登陆。

C：上传文件和材料时，用户抱怨说不知道需要在提交表格中完成哪些信息，提交的数据是否符合要求，也不知道是否成功上传。这让他们很沮丧。

……

鉴于客户关心每个痛点的价值和所需投入，我们不妨用熟悉的斐波那契数列评估延迟成本决策，从用户-业务价值、风险降低和机会启用价值、时间紧迫性、持续时间维度引导客户对上述痛点进行评估；再将用户-业务价值和风险降低和机会启用价值的和与时间紧迫性的乘积除以该价值所需的时间估算延误成本。延误成本高的，优先处理，正如示例中的 A。

六、基于假设估算“治疗”痛点的投资回报

痛点量化本身是很难的，因为疼痛本身是一种主观评价，很难标准、精确评价。我们可以考虑按照前文提到的，通过量表定量分析痛点疼痛程度；但这往往要求比较大的样本量，一般项目难以满足。

此时，如果客户仍坚持对痛点的价值进行量化，我们可以基于延迟成本决策评估得到的高优先级痛点，结合痛点的解决方案进行量化，辅助决策。

比如，在没有足够开发能力的企业 X ，目前 A 产品页面加载时间 40s ，远远落后于直接竞品的响应速度，极大地伤害了用户体验，客户相信它对现有业务造成了直接负面影响。

当我们计划针对A产品开展性能优化，实现页面加载时间 avg 40s 到 20s 的提升，可以基于适当假设，对投资回报率（ ROI ）进行定量评估。具体如何计算呢？

第一步：确定实行该项目需要哪些步骤，估计投资成本

计算 ROI 前，我们需要基于项目对方案进行拆解，确定需要完成哪些任务。

比如：

该组织内部是否有足够的人力、流程、能力支持该举措实施，是否需要进行部门重组、是否需要引入外包、进行流程改进、人才引入、培训等必要措施；

需要建立哪些基础核心资产，或者是否需要使用核心资产构建产品，如共性和可变性分析、通用软件架构、领域模型、可复用软件组件、基础设施建设、相关文档等；

对于具体产品的开发，还需要哪些活动，比如定制化设计，方案验证、适配核心资产、特定的产品管理和运营追踪……

这些都是在传统企业内思考数字化产品开发相关举措，需要考虑的引起投资成本的活动。具体到案例中，我们不妨结合客户现状，从这组织成本、核心资产成本、产品成本三个维度思考页面加载时间从 avg 40s 提升到 20s 的成本变化。

第二步：计算项目成效

数字时代的高度不确定性使预测成效尤为困难。但数字化产品研发项目作为一种投资行为，我们仍然需要根据经验和市场情况进行合理的估计，合理投资。

通常来说，窃以为我们可以从效果、效益、效用等维度对举措的经济效果评价。

比如，从效果分析的维度，我们可以选择首字节时间（用于衡量网络链路和服务器响应性能）、白屏时间（First Paint）、可交互时间（Interactive）、完全加载时间（Load）等。

从效用指标的角度，我们可以度量消费者使用产品的满意度等等。

当我们面对追求确定性利润的传统企业、业务部门，从效益的角度分析，往往更容易成为争取预算、分析报告的权威论据。实际项目中，我们不妨结合业务上下文定义，对效果、效用维度的指标进行定义和拆解，结合转化率分析效益。

在案例中，我们可以从产品使用规模（有多少用户使用 A 产品），转化率（相比 20s 的页面加载时间，页面加载时间 40s 造成了多少用户流失）等思路着手估算项目前后带来的收益变化。

需要强调的是，没有完全标准化的方法可以计算各行各业、各种产品的投资回报。实际应用中，仍需要结合业务上下文进行拆解和修正。

以上就是我对痛点分析的一些思考。如果你正在被类似的问题困扰或者有过类似经历，欢迎留言分享，我们可以一起交流，看看有没有更好的处理办法。