6. 理解你的目标受众

我们不能只靠直接问客户“你需要什么、想要什么”。认知偏差会干扰客户稳定、可靠地回答这些问题。相反，我们要在具体故事语境里倾听他们的需求、痛点和渴望。

— Teresa Torres，Continuous Discovery Habits 作者

产品思维工程师最关键的视角切换是：为某个具体的人而构建。了解客户后，我们才能选择彼此互补的功能组合（我们会在第 8 章详细设计），并把精力优先投入到真正需要的要求上，例如延迟、可扩展性与安全性（第 9 章）。

这句话听起来很简单，但在实践中要做到，必须持续、主动地投入注意力，因为还有很多事情在争抢我们的精力。像海獭一样，我们要潜下去觅食，也要浮上来换气。

在这一章，你会认识你的目标受众。眼下我先聚焦于你与潜在客户的初次互动：访谈他们、了解他们，并判断谁属于你的目标受众。（对比而言，在第 5 章里，我们是在产品较后期版本上迭代，咨询的是现有用户。）

你会用这些信息构建人物画像（以及非人物画像），以指导整个团队的工作。这些技术能帮助你形成清晰愿景，并在重大决策上做对选择。

真实用户，而非稻草人

正如我在第 1 章提到的，真实的人类有一些普遍特征，例如健忘、只会分配有限的脑力给你的产品、而且很忙。这些经验法则通常有用，但它们和所有经验法则一样，不总是对的，也远远不够具体。如果你没有完整的人物画像来支撑决策，就很容易不小心为自己而构建，或为你上一个产品服务过的人物画像而构建。

就像你能在模拟中找剧情漏洞一样，你也能识别不可信的角色。问问自己：“在这个阶段，会是哪种人使用我们的产品？”有时，如果你足够诚实，你脑中的角色会像这样：

• 非理性行动者（The Irrational Actor）：行动与其动机相矛盾。手头拮据的省钱党却买 8 美元拿铁；或某个网红明明每月靠已有规模的平台赚几千美元，却因为你送 10 美元亚马逊礼品卡就去用你那个空荡荡的社交网络。
• 梦幻啦啦队用户（The Manic Pixie Dream User）：无缘无故就爱上你的产品。她愿意在社交媒体上告诉所有朋友，而且她的感染力会让朋友也来尝试。你每发一个功能她都会秒用，并发布截图和使用视频。
• 苦修僧用户（The Stoic Monk）：整天在修道院里用你的产品。无论你扔给他多难的东西都愿意学；即便功能耗时也照用不误；就算产品频繁变动、稳定性很差，他也会以禅定般的平静继续重试。
• 你的克隆体（Your Clone）：和你一样了解系统，因此不需要任何发现机制。由于熟悉内部实现，他对反直觉行为的容忍度异常高。这个“克隆体”正体现了第 2 章提到的“知识诅咒”陷阱。
• 你爸妈（Mom or Dad）：是真实的人，但很可惜，你最多也就这一个或两个样本。

我把这些叫作“稻草人用户”，和我们在第 1 章批评动机薄弱场景时讨论的是一类问题。

人们之所以会脑补稻草人用户，常常是因为其他连自己都未意识到的偏差。

偏差很危险

我最近给一位社交卡牌游戏创业公司的老板做咨询。他的公司宣讲是：现有头部产品自满又榨取用户。但当我问“什么会驱使用户切换到你的产品”时，他的核心论点其实是：“大家会来我们网站，因为我们有视频聊天。”可这意味着用户还得说服朋友离开熟悉的既有平台界面。

他们会吗？这论点倒也不荒谬。

事实上，我这位朋友是从前任老板那里接手了视频聊天功能。他已经为这家公司投入资金，工程团队资源有限，因此他需要视频聊天成为杀手功能，因为这是他手里现成的牌。可它真的是这类卡牌玩家最想要的前两三个功能之一吗？重要到足以让大家从旧站点迁移出来吗？没人真正知道。

我另一位朋友也在同一赛道，和同一家头部公司竞争。他设计了创新且有吸引力的锦标赛形式，并邀请几位知名高手参赛，在 YouTube 上直播带品牌的视频。这些视频吸引了想挑战高手的新用户。关键在于，这是游戏的单人模式，意味着它可以在“用户朋友尚未都上站”之前先获得牵引力。这个单人产品随后实现了自我维持，并把用户导入多人模式，而他希望多人模式能随时间增长。

第一家公司在大量辛劳和资本浪费后倒闭了。第二家到目前为止还活着、还能打。至少他的策略建立在一组连贯的用户动机上。我认为他有一战之力。

我们必须持续避开那些遮蔽判断的偏差。把用户是谁写得清楚、诚实，并文档化后在团队内共享，就像船长手里的 GPS。它会持续把我们导向目标，即使偏差、权宜、政治、异想天开、逻辑谬误和自我 ego 这些“侧风”不断把我们吹离航线。

这一章里，我会先介绍用于评估产品是否可行的科学化心态。

接着，我会通过用户访谈（如客户发现访谈和销售通话）帮助你构建“用户真正想要什么”的图景。

然后，我会讲如何构建人物画像并将其写下来，与团队共享、达成一致。

接下来，我会带你在多个可能的人物画像中做优先级，形成产品的目标受众。

最后，我会触及一个出现频率高得出人意料的话题：多边市场，也就是由多个相互作用的人物画像组成的社区，例如网约车司机与乘客。

为了展开讨论，我先给出一个贯穿本章的案例研究。

案例研究导入

在 2010 年代初期，我在 Facebook 参与 App Center 的设计和发布。它是一个供用户发现社交应用（主要是游戏）的入口。概念上，它类似现代应用商店：有精选应用和排行榜。那段经历是我成长为产品思维工程师的关键起点。

我选择这个项目作为展示，是因为它凸显了“用户侧人物画像 + 开发者侧人物画像”的有趣组合，而这正是我们战略决策的驱动力。这个产品之所以产生影响，是因为团队里的工程师、PM 和设计师都理解了目标受众，既推动了 Facebook 上的游戏业务，也提升了开发者的收益。这个成功持续了几年，直到移动游戏这台巨型战车席卷一切。

后退一步，拿起科学这把武器

产品论题定义了你要解决的用户问题、你要帮助谁，以及你打算如何解决的有说服力思路。

我们对 App Center 的起始高层产品论题大致是：

App Center 将帮助社交游戏玩家发现朋友正在玩的优质游戏，并通过激励应用开发者构建高质量应用来争夺 App Center 的展示位。这将反过来壮大 Facebook 游戏生态。

我喜欢用“论题（thesis）”这个词，因为它有科学味道。你也许正斗志满满、迫不及待想开工，但你应该先把自己的“心头好点子”放一边，换成好奇、科学的心态。临床药物试验是个很贴切的类比，因为和药物试验一样，大多数产品都会失败。

我们会采纳实验科学方法中的两个方面：零假设，以及避免混杂因素。

“零假设”主张“干预不会产生效果”。实验结果可以“证伪”零假设。

在产品语境里，我们把它称作产品反命题：客户不需要、不想要、不会从中受益，或根本无法使用你的产品/功能。

你可以进一步补全这个反命题，写出其可能成立的原因。例如：“社交玩家早就通过通知和信息流等更病毒式机制接收朋友的游戏邀请。App Center 带不来足够流量，影响可忽略。”

随着我们进入更具体的场景，会持续细化这个反命题。

思考反命题会让你保持怀疑。如果你把所有脑力都用来证明产品论题成立，你总能继续找到它会成功的理由。有了反命题，你就会在客户说出那些你不想听的话时，听得更认真。

接下来，我们会把这种科学心态带进客户访谈和问卷中。

客户发现

在你构建产品或功能之前，先弄清什么会驱动用户使用它，或让用户远离它。当足够多用户共享相似的激励与能力条件时，就会汇聚成一个人物画像。人物画像在早期对于判断“该和谁聊”至关重要，在后期则用于测试大量不同的产品与功能想法。

客户发现的目标是发展并迭代你的产品论题。为此，你要弄清：人们遇到了什么问题、谁在遇到这些问题、为什么会遇到。

你可以从一个具体产品想法起步，但别过度执着，因为你可能必须调整计划。

你探索的是问题空间，多于解法空间。你要进入被访者的思维世界，尽可能多地学习。

客户发现可以通过多种方式进行：访谈、销售通话、问卷都很常见。

我会逐一覆盖这些方式，然后总结它们如何在产品周期推进过程中，帮助我们建立可持续借力的高价值关系网络。

但在这之前，最先的问题是：你到底怎么拿到访谈机会？

如何拿到访谈

访谈对工程师来说是最易接触的机会之一，在产品周期各阶段都有帮助，尤其在发现阶段。但对很多工程师来说，最难的一步恰恰是“约到一位潜在客户访谈”。

下面是一些可能有用的方法：

• 借助更面向客户的角色，例如用户体验研究员或产品经理。或者从销售组织里找客户经理、客户成功代表、市场人员或解决方案架构师。问问能否旁听他们现有会议，并在末尾留几分钟让你提问。
• 多和面向客户的同事建立关系，你就更容易要到专门访谈时段，他们甚至可能主动把机会带给你。你也可以提出提供技术支持，或介绍你的近期路线图。客户通常会觉得“工程师愿意花时间和我聊”很被重视。
• 在我于第 5 章讲过的支持场景中，直接问用户是否愿意接受访谈。若你此前帮到过他们，他们通常很可能答应。
• 借助那些“知道很多人想要什么”的人。对 App Center 访谈而言，我们可以去找游戏工作室的人，他们通常知道他们用户想要什么，或能把我们引荐给该聊的个人。
• 发放问卷，并用它筛选哪些人愿意接受后续访谈。我们会在介绍完访谈后讲这类问卷。

客户发现访谈

客户发现访谈（CDI）是与现有或潜在客户进行的结构化对话。

一次完整 CDI 有三个基本目标：

1. 理解用户的根本动机与处境。这会解锁你的创造力，让你在最初想法不对时，仍能提出其他解法。了解用户完整的问题集合，才能设计整体化方案。
2. 探出动机强度。许多产品失败，不是因为用户完全不想要，而是因为他们只“有点想要”。
3. 若你已有具体产品想法，邀请被访者发挥创造力，对你的产品想法、mock 或原型给反馈。这样你能发现那些自己尚未意识到该问的问题答案。

即便有 60 分钟，这也是很大范围的内容，而且很容易跑偏。我最核心的建议有两条：(a) 采用好奇、科学的心态；(b) 让访谈从“聊被访者”慢慢过渡到“聊你的产品”。

这两点都需要展开说明，我们先放到显微镜下看清楚，然后再把这些洞见应用到 App Center 的例子里。

客户访谈漏斗

把 CDI 想象成一个漏斗。开头你在用户世界里，聊他们的故事、问题和愿望，你在锚定他们的人物画像。随着访谈推进，你逐步把他们带到你的产品世界里，对产品提出越来越聚焦的问题，如图 6-1所示。

图 6-1. 客户发现访谈漏斗

是的，我喜欢把自己的产品想法想象成克苏鲁这类不可名状的存在：如果我不小心，就会让用户看见“看过就回不去”的东西，永久污染他们的判断。我未必会让他们发疯，但我确实可能让他们的反馈带偏。所以，在我正式抛出产品/功能想法前的那几分钟非常宝贵。

这一节里，我把这个漏斗分成前期、中期和末期，来说明访谈如何推进。

访谈开始时，先让被访者感到舒适、愿意分享，因为你要大量追问他们的经历。

尤其在前期，尽量避免把他们引向特定答案的问题。

如果被访者一进来就主动提出你要做的功能，这是远强于“你先展示功能想法、他再说喜欢”的信号。

会影响用户的人不止你自己，他们也可能缺乏自我觉察，或难以预测自己的行为。你当然可以直接问需求，但更好的做法是让他们讲与产品论题相关的近期故事。

让用户讲故事有很多优势：

• 用户会停留在具体情境中，告诉你他们实际做了什么，而不是无意中拼出一套偏斜叙事，去描述“他们以为自己想要什么”或“他们希望自己会做什么”。
• 走一遍具体故事能帮你构建场景，指导后续设计工作，我会在第 7 章进一步讨论。
• 故事会唤起用户记忆，带出他们体验中的关键细节。

在访谈前期，用户可能会提出你没考虑过、但他们很在意的问题。要愿意跟进，因为这可能意味着你当前还没在解决正确的问题，应该调整产品论题。

对 Facebook 游戏而言，你可以这样开场：“你最近在 Facebook 上玩游戏或发现游戏时，有没有什么反馈？”

当用户把最先想到的内容都说出来后，你可以再问一些用于识别人物画像的问题，比如：“你喜欢哪些游戏？”这能帮助你判断他偏好解谜、社交等哪类游戏。

在中期，仍然留在用户语境里，但要收束到你预设的话题，询问你原本要解决的具体问题。对方可能根本没有这些问题，这也是有价值的信号，会喂给产品反命题。也许他不属于你的目标受众；也可能他属于，但你并没在解决对的问题。

像“聊聊你典型的一次游戏过程”或“你通常怎么决定要不要试一个游戏？”这种更具体的提示，能帮助我们理解用户面临的问题和驱动他们的动机。这会加深我们的人物画像，也会为用例模拟补充细节。

中期里，很多人天然会倾向配合、友善。你要确保问题表述中立，不让对方感觉你期待正面或负面的某种回应。

到这个阶段，你已具备基于对方回答构建客户人物画像所需的原料。

然后是可选的末期：如果被访者看起来确实能从你的产品想法中受益，就描述该想法并请他反馈。视觉化能让内容更具体，所以若你有草图或 mockup，就拿出来。

这个环节帮助用户判断你的产品想法是否适合他。你可以先描述一个使用场景来表达意图，再问这是否听起来能解决他的需求。

最重要的是，营造一个欢迎其表达观点和困惑的空间。

这一部分本身也有一个漏斗。

我们要弄清：每个游戏条目该展示哪些信息；以及分享游戏行为信息是否有隐私担忧。

第一步可以给他们看一份功能列表（比如：游戏类型、星级评分、正在游玩的好友、描述、热度），让他们选最重要的项。

然后再更具体一些：“这是我们在打磨的一个粗略概念，你怎么看？”

假设我们担心玩家不希望朋友看到自己的游戏行为，如图 6-2所示。

图 6-2. App Center 原型

我们不会直接问“你在意隐私吗？”这种问题过于引导。但如果用户自己说“呃，这是不是意味着我朋友会看到我在玩什么？”这就是强信号。若足够多人提出，我们就能形成“隐私敏感型”人物画像。

如果没出现这种自发表达，我们可以让他们打开 Facebook，调出最近玩过的游戏列表，问：“这里哪些游戏你愿意推荐给朋友，或拉朋友一起玩？”

他们的回答会如何转化为产品改动？

• 也许用户不想让别人看到自己只玩了 5 分钟就弃坑的游戏，那我们可以要求达到一定游玩时长后才允许分享。
• 也许某些游戏是他们的“罪恶快感”，那我们可以允许按游戏粒度关闭分享。
• 也有人完全不想被别人知道自己“在浪费时间玩游戏”。我们可以让其默认不分享任何游戏活动。

开放问题通常比较耗时，而漏斗各阶段又必须精心编排，所以时间管理非常关键。下面说说如何为高效访谈做准备。

为问题写脚本

一点结构化设计能大幅提升你的时间管理效率。准备一份访谈提纲，在访谈推进时随时参考。

你可能会自然地想带着“按顺序要问的十几个问题”进场。但那会让你在用户说出有价值信息时没有时间深挖，还会让你听起来很机械。如果你发现自己想覆盖很大范围、又想让每个受访者都回答一致的问题，那其实你需要的是问卷。

当客户说到有意思的信息时要深入追问；而当某话题对该用户不相关时，不要浪费时间。也不要掉进这个陷阱：“那如果你想要 ，你希望它怎么做？”

你的访谈提纲可以包含：用户分段的一两个开场问题；用户-产品中段的一两个问题；以及产品段要展示的一项内容。或者，如果你偏好充分准备，可以按不同对话走向准备一组候选问题。很多问题会是条件触发，不必计划全部问到。

即使有几场访谈让你“失控”了，也不用焦虑。做多了你会逐渐形成节奏感，知道何时该把对话往前推。况且，访谈开头的内容通常信号最强。

响应分析

访谈之后，我们要总结每场的收获。应判断用户回答给出的信号强度，以评估不同因素的重要性。

以 App Center 为例：如果我们想判断星级评分是否有价值，用户可能以不同方式表达，而这些表达有不同信号强度，如表 6-1所示：

表 6-1. 星级评分反馈

由于每一步提示都会降低信号强度，我们会把后面的提问延后，先争取高信号。

漏斗前段得到的动机信息也会给这些建议提供语境。如果某用户本来就不太热衷尝试新游戏，我们就没必要像对“新游戏重度探索者”那样重视他对星级评分的看法。

现在把视线转向另一个客户机会：销售通话。

销售通话

工程师有时会被邀请参与销售通话，提供技术解答、建立专业形象、介绍路线图，或评估满足客户特殊需求的可行性。你完全可以把销售通话用于客户发现，因为销售人员想了解的很多人物画像信息，和你想了解的是重叠的。

不过，销售人员的目标和你不同。你的目标是找准目标受众和产品路线图，他们的目标是卖出具体产品。你可能规划的是一年后的发布，而他们往往希望在未来一两个季度拿下订单。

务必在会前对齐访谈目标，并请销售同事明确告诉你“哪些该说、哪些别说”。提前对齐会让他们更放心地把你带进这些高价值对话。对你来说，也要明确你在路线图上愿意承诺什么、不愿承诺什么。

进入会议后，销售代表希望你帮助建立客户信任，而你做到这一点的方式是：共情客户并为其需求发声。客户通常能察觉自己是否在被操控、是否只是在听一套“销售话术”。

简而言之，在销售代表设定的边界内，仍然使用你那套科学方法。要愿意接受产品反命题可能成立：也许你的产品解决不了这个客户的问题；也许它还需要继续打磨才能适配该客户。现在说清楚，总比经历痛苦的集成和拉扯谈判后才发现问题要好。

在 Facebook，我们希望吸引成熟且高质量的游戏工作室入驻平台，我们觉得 App Center 会是展示其游戏的好位置。但如果开发者真正渴望的是稳定 API 和更好的内购支持呢？按漏斗思路，我们应该先听，再揭示自己的产品想法。

我们也要坦诚说明“不适配条件”。例如，我们不希望那些做图形密集型游戏、且其游戏无法在多数机器浏览器里运行的开发者加入。把边界提前说清，能确保双方都不浪费时间。

客户发现问卷

客户发现问卷能比访谈覆盖更广的用户需求，但它不如访谈灵活，也不够深入。关键是，它可以用来筛选“可访谈对象”。

这类问卷本质上是访谈的压缩版，因此很多建议相同：先从开放问题开始，尝试识别人像；关注具体行为和场景，而不是抽象意见；并尝试判断优先级。

一份好的问卷还应让客户有兴趣填写。视受众而定，你可以给激励，或者直接告诉他们：你们在认真倾听，而且他们有机会影响产品方向。

最后，问卷要能筛出愿意进一步交流的人。正如我前面所说，这是生成访谈线索的好办法。

App Center 的问卷可以长这样：

Facebook Games 团队想听到你的声音！我们正努力让你更容易发现优质游戏。为了指导我们的功能路线图，我们希望了解你喜欢什么、不喜欢什么。

• 你是否尝试过在 Facebook 上玩游戏？
• 你最近在 Facebook 上发现/游玩游戏的体验，有什么反馈？
• 这对你的体验满意度有多重要？
• 请列出几个你非常喜欢或玩得很多的游戏。
• 想想你最近注意到的一些游戏。你通常如何决定是否尝试？
• 想想你最近尝试过的游戏。你是怎么发现它们的？你觉得怎么样？

你是否愿意和团队成员聊聊，分享更多？

这种结尾的 call-to-action 不是我们拓展关系网络的唯一时机。在 CDI 和销售通话结束时，我们也可以做同样的事。

与被访者建立关系网络

客户访谈是非常重要的关系网络建设机会。

在第 5 章中我们讲过，如何在用户引导下持续迭代产品。用户互动心态的一项关键支撑，就是你有一组可信任、可快速联系来获取反馈的人。

留意那些反馈深刻、典型体现某人物画像，或在你产品做出来后可能成为早期采用者的受访者。看看他们是否愿意保持联系。

他们甚至可能成为参考客户（reference customer）：一个代表更广泛人物画像的真实个人或公司。他们可以作为设计伙伴，持续给你需求和反馈。后续营销也可以引用他们，向其他人证明“和你类似的客户已经在用我们的产品”。

接下来我会用一些经验法则总结这一节，帮助你设计提问提示语。

客户访谈经验法则

无论你是在准备客户发现访谈提纲，还是在制作客户发现问卷，都要记住几件事：

• 让被访者感到自己可以放心表达观点、反馈和困惑。
• 你引导越少，回答越可信。把这点作为访谈早期的最高优先级。
• 问中立问题，剥离你自己的预期和偏好。
• 多问具体情境，少问抽象意见和猜测。“给我讲一次……的经历”通常是很好的开场。

访谈或问卷结束后，及时写下收获。并根据你拿到的信号强度标记轻重缓急，这样你会记得问题的紧迫程度。

最后，充分利用部分受访者提供的人脉引荐，推进后续交流。

下一节，我们将基于访谈和其他研究结果，构建目标受众。

构建并传达目标受众

做过一些访谈之后，再结合市场研究等数据，我们就可以头脑风暴不同产品概念，并将其与目标受众进行匹配。必要时，再围绕这些人物画像迭代产品论题。

第一步，我们要对“瞄准谁”做出有吸引力且可落地的选择。

第二步，我们要把这些选择有效传达给团队，让所有人买账。

选择目标受众

在第 1 章中，我给出过场景角色的组成元素：

• 人物画像：人口属性 + 一组能力/资源条件（means）的组合。
• 使用你产品的动机。

目标受众是人物画像的泛化版本。这些潜在用户应当：

• 基于真实世界的人群特征。
• 拥有显著的使用动机，尤其是相对竞品而言。
• 具备购买和使用产品的能力条件。
• 不存在强烈的“不使用”动机。

如果你的产品是全新产品，短期目标受众通常需要保持较小。这是因为你很难同时激励“所有地方的所有人”。一般你需要找到一个未被现有产品充分服务的核心人群并聚焦。后续可扩张，我参与过的很多产品都走过这条路：

• Facebook 最初服务美国大学生，随后扩展到高中生，再到所有英语用户，之后才全球化。
• Stripe 先用“7 行代码”吸引创业开发者和技术型创始人，之后再扩展到企业级使用，并为非开发者与 vibe coder 提供无代码方案。
• Temporal 先聚焦在大型科技公司的 Go 语言基础设施工程师，再扩展到使用其他语言的金融和产品工程师，后来又加入企业与 AI 功能。

幸运的是，人们的需求并非随机分布，它们常常以互相增强的群组形式出现。要收敛到更小人群，就在访谈里寻找动机的相关性组合。

在 Facebook，经过大量访谈和受众分析，我们看到玩家大致分成两组：休闲社交玩家，以及所谓“中核（mid-core）玩家”。中核玩家会被硬核玩家常玩的复杂战术或策略游戏吸引，但不愿投入同等的时间与金钱。

社交玩家往往更在意社交语境、可炫耀性，以及“很多朋友也在玩”。

中核玩家则更偏隐私敏感、享受竞争，并追求评价良好的高质量内容。

在本章后面，我们会利用这些分组来选择功能组合。现在先把这些受众转化成可沟通的形式。

用人物画像达成一致

如果团队每个人都在想着同一类用户、同一组需求，那么每个人都能做出好决策，至少能做出方向一致的决策。产品越复杂，全员用人物画像保持同频就越关键。

当你把目标受众写出来，你就把他们的需求集中到一个地方。然后可用它来对齐“什么算成功”。如果你只满足了受众三项基本需求中的两项，那就还没完成，还不到发布的时候。

另外，也要明确你不瞄准谁。这些叫作非人物画像（nonpersonas）。

非人物画像能帮助你避免加入那些无助于当前目标、却会拖慢开发的额外工作，也就是常说的范围蔓延（scope creep）。

为了传达人物画像和非人物画像，你可以在共享文档（例如幻灯片）里写出易记的人物画像，再配上角色小传来补足其使用动机。并附上访谈记录链接，以便别人质疑“这些画像怎么得来、是否真实”时可追溯。

让人物画像更易记的一种方式，是给他们起醒目、富画面感的名字。

Mort、Elvis 与 Einstein 之争

我第一次接触人物画像是在 2005 年，当时我在微软开发者事业部（DevDiv）工作。这套画像后来泄露到公开网络，成了颇有争议的梗，但它们其实非常有效。直到今天我仍把它当作人物画像实践的优秀案例，因为它在一个大型工程师与产品经理组织里实现了高效沟通和对齐。DevDiv 负责 Visual Studio，尤其是 Visual Basic、C#、C++ 的编译器、运行时和 IDE。他们的人物画像大致是：

• Mort：机会导向型开发者，喜欢快速拼出可用方案来解决眼前问题，强调生产力，边做边学。编程可能只是他主业（如会计）之外的补充技能。
• Elvis：务实且忙碌的应用程序员，围绕问题域构建具体且可长期使用的方案。在解决方案的过程中学习，以便尽快转向下一个问题。
• Einstein：偏谨慎的系统程序员，需要构建通用且高效的方案，通常会在动手前先做较充分学习。

各团队被要求在构建其库和体验时瞄准不同画像。Visual Basic 的目标受众是 Mort，C# 是 Elvis，C++ 是 Einstein。

当这些画像被公众知晓后，引发了反弹。开发者觉得自己不该、也无法被塞进这种简单分类。没人想被叫作 Mort，因为在英文文学里，这个名字常用于笨拙角色。

如果从“人物画像及其在产品开发中的目的”来看，这件事就更说得通了：

• 虽然大家拿 Mort 开玩笑式贬低确实刺耳，但“起醒目名字”这个方法本身是对的，并且确实帮助 DevDiv 达成了对齐。
• Mort 这个名字并非贬义，而是为了反复提醒 Visual Basic 团队：持续简化抽象。
• 一个人在不同情境下可能对应一个或多个人物画像。有人写小型效率脚本时像 Mort，给固件代码库提交代码时又像 Einstein。
• 人物画像不是刻板印象。它用具体、可记忆的语言去激发并指导设计。真实用户远比画像多样，产品设计者必须始终意识到这一点。Einstein 画像不应成为把 C++ 做得不必要地困难的借口。
• 让不同语言聚焦不同画像，使这些产品既完整又有差异化。

现在把这些方法整合起来，为 App Center 写一些角色小传。

App Center 的受众画像

前面提到的社交玩家和中核玩家都在下面体现了。我还加了第三种画像“鲸鱼玩家（whale）”，这是免费游戏行业对“付费金额很高玩家”的称呼。这个行业的大部分收入来自少数玩家，因此我们必须覆盖这类画像，因为我们支持的游戏其商业模式依赖他们。

• Penny Pincher：看重与朋友保持连接的社交网络用户。她把游戏当作消磨时间、和朋友一起玩的方式，但并不特别好胜，也不把自己当“玩家”。因此她偏好轻量游戏：要么映射现实生活的某些侧面，要么呈现更轻松生活的现实感幻想。她只玩免费游戏，偶尔看广告可以接受，但不会为游戏内附加项付费。
• Moby（鲸鱼玩家）：重度社交游戏玩家，做什么都深度投入。他喜欢和朋友一起玩，并追求高成就感，不管是通过对抗还是合作。他愿意为能向朋友展示的游戏内升级，或能加快进度的“省时项”付费。
• Patton（名字取自二战时期美国将军）：投入度高、已在 PC 平台玩游戏，但又抗拒高昂价格。他想玩有厚度、有策略性的游戏，但不想先花 1000 美元配游戏主机，再买一款可能并不喜欢的 AAA 硬核游戏。他重视更便宜的“中核”游戏，更看重游戏质量与沉浸感，既喜欢和游戏搭子一起玩，也能接受单人游玩。只要能先试后买，他愿意付费；口碑好的游戏他也愿意尝试。

这些角色代表了常见人群类型。它们也展示了玩家从游戏中获取的价值，以及他们愿意为此交换什么，这能帮助我们评估“投入这些画像是否有商业价值”，下一节我会继续讲。

我用了具体、带立场的语言，包括明确性别和金额，以激发更强画面感。传达受众时，具体化很重要，这和“虚构角色比干巴巴属性列表更容易被记住”是同一原理。

如果我们不承认现实中的用户更为多样，就会把人物画像滑向刻板印象。这些角色描述的目的是激发有价值讨论，而不是形成狭窄、教条的属性清单。

这些受众会如何影响我们的策略？

Patton 是最具不确定性的画像，也是我们最希望引入 App Center 的画像。我们知道 Patton 数量少于 Penny，但幸运的是我们有参考客户：平台上的 War Commander 就服务 Patton，并且单用户收入表现很好。它成功到让我们相信，可以通过吸引并重点展示更多强势游戏来复制这种成功。

当然，既然是市场平台，硬币还有另一面：我们也需要“游戏开发者”的人物画像。War Commander 的开发商 Kixeye 代表了中核游戏开发者画像，而他们的需求会和 Zynga 这类休闲工作室（开发了 Farmville 和 Cityville）明显不同。

Kixeye 是一个参考客户。通过和他们交流、理解其需求，我们能更好理解类似工作室。再借其成功案例背书，我们就能吸引更多游戏工作室来和我们合作开发。

人物画像还能提供对用户需求的整体视角。把 Patton 从 Moby 和 Penny 中分离出来，也提醒我们还有很多工作要做。Patton 在沉浸感、质量和游戏类型偏好上都不同于 Penny。若想构建完整方案，我们在设计 App Center 时必须从整体上思考。

反过来，如果我们只是收集中核玩家或工作室的零散功能请求，却不把他们当作独立画像来处理，就会做出“半套方案”，永远达不到临界规模。

有了参考客户和一系列凸显 Patton 画像的客户发现结果后，我们现在可以把产品论题写得更有立场、更具体：

App Center 将帮助社交玩家，尤其是 Patton 这类玩家，发现朋友正在玩的优质游戏；并激励游戏工作室通过构建高质量应用，在更多元的类型里竞争 App Center 的展示位。这将进一步把 Facebook 游戏生态拓展到新的用户群体。

稍后我们会基于这个新论题为 App Center 选择一组连贯功能。在此之前，我想先说明：明确“我们不服务谁”为什么同样重要。

非人物画像

App Center 团队需要明确一个非目标受众：硬核玩家。他们对休闲游戏兴趣较低，因为他们愿意投入更多时间和金钱去追求高端体验，而这类体验当时在浏览器里也无法提供。这并不是说“硬核玩家绝不会玩 Facebook 游戏”，而是说团队不会为吸引他们投入特别精力。当有人提出看起来是为硬核开发者设计的功能时，我们会降低优先级，并能清楚说明原因。

如果当年我所在的 Games 团队也明确了非人物画像，会对我很有帮助。我是竞技桥牌玩家，经常和陌生人打线下与线上锦标赛。我也是《Words with Friends》的高水平玩家，当时一直难以找到有竞争力、且在线的对手好友。

我在 App Center 之后的“心头项目”是做一个基于水平匹配的对战服务，让玩家能和实力接近的陌生人打竞技对局。我围绕这个提案花了不少时间，但始终没说服管理层；而他们也说不太清原因，除了“优先级不够高”。

如果当时有“硬核玩家是非人物画像”这个定义，我会更清楚，也能省下很多时间。这类人热爱游戏到愿意和陌生人对战，而 Patton 更想和朋友玩。匹配对战对 Patton 吸引力不大，所以继续投入匹配并不划算。

现在把视线转向功能选择。随着我们想象并评估各种功能，也可能需要回头调整受众选择，因为我们会逐步知道这些功能究竟有多可行。

基于目标受众选择功能

我会给一个功能选择示例，说明它如何与产品论题、目标受众相互作用。

假设 App Center 的应用列表具备以下能力：

• 推荐新游戏，例如编辑认为优质的作品。
• 基于质量、好友活跃度、以及与其既有游戏偏好的相似性，为每位用户生成个性化排序。

粗略来看，我们这三类人物画像可能都会喜欢这些属性。大家都在和朋友玩，也都在某种程度上偏好好游戏。

围绕这个功能组合的产品论题可能是：“为 Facebook 用户提供一个发现与其相关优质游戏的场所。开发者会被激励去做更棒的游戏，从而提升参与度，并通过游戏内购买和广告给 Facebook 带来收入。”

我们可以为每个画像写一个反命题来测试它：

• Penny（低意图休闲玩家）可能不够主动，不会特意来 App Center；她更可能响应朋友的直接邀请。
• Moby 比 Penny 更可能来，但他不算探索型玩家；他可能只会留在已投入很多的老游戏里。
• Patton 可能一开始找不到足够吸引他的游戏，在 App Center 起势前就给出负面评价。

在我看来，Penny 和 Moby 的反命题更有说服力。我觉得她/他们中会有一部分使用 App Center，但听起来不像大爆款。Patton 的反命题则看起来可修复。

回看 Patton 的需求：沉浸感、可负担性、好友关系、质量；以及其能力条件：愿意为喜欢的东西付费。

或许我们可以增加一些范围来帮助 Patton 发现游戏：

• 允许按类型筛选游戏。例如 Patton 可以筛掉 Farmville，聚焦策略类。
• 为 App Center 定制并首发几款新游戏，让 Patton 一上来就有可玩内容。

保持聚焦

如果你想赢得某类客户，就要为他解决完整问题。对两个不同画像各服务一半，就像做一件 2XL 上衣却配 S 码袖子，技术上小个子画像也能穿，但他不会愿意穿。

举个 Facebook 游戏的“非互补”案例：一边做“允许游戏预付费”的商店，一边做“好友游戏邀请”（例如邀请朋友来帮你的模拟农场）。这两个功能单看都没问题，但给有付费墙的游戏做邀请，转化率通常不会高。它们也分别对应不同画像。长期看可以都做，但作为首发版本，这样的聚焦度不够。

构建互补功能听起来像直白的战略建议，但实践里保持聚焦很难：

• 这三项功能未必是最容易摘的低垂果实，其他选项会更诱人。
• 做休闲游戏的工作室很可能一直在催新功能；如果我们暂停这块去聚焦中核市场，他们可能会不耐烦。
• 用户也可能在持续提出其他需求。

因此，广泛沟通并让所有人围绕目标受众达成一致非常关键。关于优先级，我会在第 7 章再展开。

多画像产品

大多数成功产品最终都会服务多种人物画像。

一个常见二分是重度用户与普通用户。我在第 8 章会讲如何同时满足这两类。Moby 是重度用户，和 Penny 对照明显，但二者都属于社交玩家这一大类。

还有一种情况是，画像代表的是不同类别。Patton 和 Moby 都是高投入玩家，但细节差异明显。服务多样画像是产品做大规模的主要路径之一，就像电子表格如今服务营销、会计、科研等很多群体。它既具可扩展性，让不同职业能把它优化成解决完整问题的工具；又保留通用性。

每个人物画像都需要在产品周期的每一环获得专门关注：从访谈、优先级、测试，到营销、样例与文档。

这一节我会讲：

• 当不同画像的动机彼此冲突时会发生什么。
• 如何评估不同群体给生态带来的价值。
• 因而如何决定把更多精力投向哪些画像。

当人物画像相互冲突

有时，不同画像存在潜在冲突需求，而产品要成功，必须把这些需求重新拉回一致。

• 网约车司机与乘客：司机想多赚钱，乘客想要安全、便宜、准时的行程。
• 博客平台作者与读者：作者想要更大受众和触达渠道，读者想要高质量内容和无垃圾邮件的收件箱。
• Facebook 游戏开发者与玩家：开发者希望访问更多用户数据（例如好友列表）以实现病毒传播；用户希望保护隐私。

在对立画像间平衡不同激励，是最难、也最有价值的产品问题之一。

多开接单（Multiapping）

下面是个让人沮丧的激励错位案例。在美国，Lyft 和 Uber 是最主流的网约车应用。

有次我在 Lyft 上叫车。令我惊讶的是，我盯着地图上的点看司机何时到达，结果发现那个点在远离我，司机居然开走了！这种情况持续了几分钟，我最终取消订单。应用弹出对话框问我为什么放弃，里面居然有个选项叫“司机正在开离我”。

这激起了我的兴趣。司机为什么会这么做？而且这种怪行为为什么常见到值得专门做一个选项？

当天晚些时候我又叫了一辆 Lyft。车到了，我上车后发现司机仪表盘上固定着两部手机。后来在到达前几分钟，他打开了另一款网约车应用。我看到 Uber 在他把我送达前就给他匹配了下一位乘客。

一切突然说通了：司机在“多开接单（multiapping）”。我甚至能想象另一位乘客正盯着手机，一脸困惑地看着司机朝反方向开去，先来送我。

这是典型的激励不匹配：司机想同时跑 Uber 和 Lyft 以提高收入，而我只想要稳定、准时的行程。

Uber 和 Lyft 该如何解决这个棘手问题？我猜 Lyft 问我“司机是否在开离你”就是其整治尝试的一部分。按我的调研，Lyft 与 Uber 会在检测到违规时发警告、暂停接单，甚至停用账号，从而把激励重新拉齐。

再看一个我挺自豪的 Facebook Games 例子。我们给 App Center 引入星级评分时，不希望开发者“刷系统”。开发者应该把激励放在做出好游戏，让更多用户愿意玩；星级评分正是约束工作室朝该目标努力的机制。

但工作室也要赚钱，所以他们可能采用各种灰色手段抬高评分。我们如何应对？

我们不希望开发者控制“何时评分、谁来评分”，否则系统会被操控。因此我们控制了展示时机与抽样方式：在 Facebook.com 的信息流和侧边栏向用户展示评分入口。这个无偏、随机抽样机制让喜欢和不喜欢游戏的用户都被覆盖，最终游戏评分分布广泛，通常在 3 到 4.5 星之间。这个评分看起来有意义。

Apple 在类似设计挑战上就做错了。开发者可以主动弹窗引导用户给应用评分。我猜你一定见过这样的提示：“你喜欢这个 App 吗？”通常就在你完成最爽操作后弹出。并且只有你先点了“是”，才会被引导去评分。

以前 App Store 里知名应用出现低分并不稀奇；而现在除非有政治争议或重大事故，几乎清一色是 4.5 星以上。评分几乎失去参考价值。

任何软件生态不仅要有对齐的激励，也需要健康的画像组合。要判断“健康”是什么样，就得细致理解每类画像给社区带来的价值。下面继续。

理解客户价值

每位客户都会为生态带来价值。也许他在写内容、提 bug、提供商品或服务，或向公司付费，而这些钱可反哺产品改进。你要理解这些价值，再有意识地培育那些你希望其贡献更多的用户群体。

维基百科编辑人数相对读者很少，但影响巨大，因为没有他们，网站就会崩塌。

一个不那么直观的例子：在 Facebook Games，Penny 不带来收入，但这不代表她没有价值。她帮助游戏达到临界规模，从而吸引像 Moby 这类愿意付费的画像。这套逻辑在今天看似显然，但当免费游戏开始赚大钱时，外界其实很意外。很可能是某个产品思维很强的人先想透了这件事，并把这个商业模式讲通了。

价值还会随市场因素动态变化。在网约车场景里，当司机稀缺时，单个司机价值更高。提高司机收入会让更多司机上路，进而创造更多收益。

在竞争画像间做优先级

如果你的产品是多边市场，你就必须在不同“边”之间分配功能优先级。这是前文“选择目标受众”的一个特殊情形。

如果平台同时有内容创作者和读者，你需要持续拉动两边增长，但总会有某些时期，其中一边需要被优先关注。

在这件事上做错的产品会陷入麻烦。举个当下例子：stackoverflow.com，一个软件问答网站。历史上他们非常重视“回答者”画像，通过反馈机制、声望系统、专门讨论板和成就体系去激励。获得赞同票会让人感到自己有帮助。

然而，随着 AI 助手兴起，读者流量减少，回答者得到的“正反馈”也变少。他们的贡献依然同样重要，甚至更重要，因为 AI 正在读取并使用这些答案。但你怎么知道某个 AI 用了你的答案？如果贡献逐渐枯竭，AI 的回答质量也会因未回答问题积压而受损。

软件工程社区需要想办法重新平衡这些激励，多给问答贡献者一些正向反馈，同时把他们的答案更有效地送达用户真正提问的地方。

本章总结

软件团队应维护一份自己瞄准的人物画像列表。这些画像应包含用户背景和动机细节，并能说明他们为社区带来的价值。

如果你用这份画像列表来对齐团队，战略决策会容易很多。

• 设计讨论会更顺畅，因为大家共享了对目标用户的理解。
• 你会更容易为人们解决完整问题，因为画像细节会提醒你发现缺口。
• 你可以从候选画像中选出目标受众，也就是对不同画像做优先级，从而更容易对功能做优先级。

要识别这些画像，你通常需要和用户交流，弄清他们想要什么。客户发现访谈是个好方法，但要记住：很多用户难以准确预测并表达自己真正想要、真正会用的东西。为了获得更高质量信号，要在提问里消除偏差，并努力探出用户信念的强弱。

练习

在这些练习里，你将围绕一个类似 Google Maps、Apple Maps 或 Bing Maps 的地图应用工作，名字叫 Applebingoo Maps。

你要做混合模式出行路线，也就是“自行车 + 公交”或“汽车 + 公交”的组合行程。你有两个产品论题：

• 第一，你有使用数据表明多模态行程并不少见。你认为已有混合出行习惯的人，会因为可获得一体化路线的便利而转向 Applebingoo Maps。
• 第二，如果多模态行程更方便、也更易被发现，人们会更多使用公共交通。你设想最好的提升方式是：提供先到公交/地铁站、再到最终目的地的完整路线。

你将访谈几十位居住在有高质量公共交通的城市地区的人。

做这些练习时，每完成一题就先看答案，再进入下一题。

1. 首先，你要选择访谈对象。先设计一个筛选问卷的问题集，确保你能以合理样本量覆盖几个不同人群。你会问什么？会选哪些人？
2. 在访谈第一阶段，理解被访者的动机与认知。请设计几个讨论问题。
3. 你正在访谈一位偶尔或很少乘坐公共交通的人，想验证你的第二个产品论题（能否提升公共交通使用率）是否成立。你会问什么？哪些类型的回答能说明这个想法好或不好？
4. 写一段人物画像，代表“你自己作为 Applebingoo Maps 用户”以及你对本地交通方式的总体态度。假设你被访谈过，且还有几个人给了和你相似的回答。记得给画像起个有趣名字。
5. 最后，在访谈末段，你会如何获取对你这个具体产品想法的反馈？

答案

1. 起步时先确认“公共交通是否可用于他们会进行的行程”。汽车和自行车也问类似问题。对这三种方式都问使用频率。样本应限定在“具备公共交通可达性，且有自行车和/或汽车”的人群。针对第一个产品论题，选择经常或偶尔使用公共交通的人；针对第二个论题，选择很少或从不使用公共交通（但理论上可用）的人。
2. 我会先深入了解他们的出行模式。问题可分成“通勤”和“办事/私人行程”两类，因为这两类动力机制可能不同。下面以通勤为例，私人行程可类推：

• “请你从高层次讲讲最近一次典型通勤。”这是中性提问，不是“你为什么不多坐公交？”；同时它是在做通勤模拟，可能暴露意外洞见，也可能解释其后续回答。
• “你对通勤满意吗？为什么？”也许他们之前已经吐槽过，但如果没有，我要给他们表达机会。我想听他们是否会提到停车、拥堵、气候影响焦虑、行程时长等因素。也可能出现我没预料到的答案，比如公寓的汽车升降机经常坏，或在公司很难找到可充电车位。

3. 我会这样提示：“聊聊你使用公共交通（用于通勤/办事）的可能性。”我不想太早用混合模式路线去“引导证词”，也不想让他们因为不坐公交而有负担感。预期会听到“太慢”“班次少或不可靠”等答案。对我的产品论题更有意思的是：他们是否对可用公交选项缺乏认知，而这恰好是地图能补足的。我也关注类似“我离车站太远”的回答，这时汽车或自行车可补齐“最后一段”。我还可能发现“支付公交费用很麻烦”或“流程不熟，迟迟没配置”。如果这类反馈频繁出现，也许团队该优先做与公交运营方的支付集成，而不是最初设想。
4. 这是我给一位城郊铁路爱好者写的人物画像“城郊铁道 Stan（Suburban Rail Stan）”：“Rail Stan 是住在城郊、附近有几条铁路线路的有车用户。他偶尔乘坐公共交通，因为列车并不适配他的大多数行程。但当他进城时，会开车到换乘停车场，再坐火车进城。他喜欢这样做，因为能避免城市开车和停车压力，也因为这能降低碳足迹。他会在车上阅读或工作，因此即使总时长略长也不觉得是损失时间。地图应用不支持这个使用场景会让他很烦。”如果我写成“他把挫败感都发泄在软件工程书里的练习题上”，那就有点过于具体了。
5. 我的目标是尽量让他们在接近真实世界的条件下进行模拟，以最大化反馈保真度。如果我有原型（可能是 AI 生成的），我会让他们拿平时通勤地点直接试用。最终我既要拿到对产品概念的反馈，也要判断它是否会改变他们的通勤模式。因此我会把混合模式路线与他们传统会选的路线并排展示，请他们比较。