标签: 产品哲学

  • 从最小可行到最小受欢迎产品的跃迁

    引言:产品构建者应以“可爱”为目标,而不仅仅是“可行”。

    Jiaona Zhang(曾任 Dropbox、Airbnb、WeWork 产品负责人,斯坦福大学讲师)分享了打造赢得用户芳心的 “MLP”(最小可爱产品)的策略。

    如果说爱藏在细节之中,那么张佳娜(JZ) 对使用户倾心的细节便有着敏锐的洞察力。

    从她在 Pocket Gems 担任首个产品经理岗位,设计出能让玩家持续登录的移动游戏功能,到在 Dropbox 任职期间,凭借专注解决用户问题的本能,推动打造出公司一些极具代表性的 UI 交互,张佳娜的职业生涯亮点十足,始终围绕着如何精准捕捉那些能够吸引并激励用户的细微之处。

    她还将自己的专长应用于数字界面与实体空间:无论是在 Airbnb(她曾担任 Plus 发布项目的产品负责人及房源平台团队的产品主管),还是如今在 WeWork 作为产品管理总监,她都将这些理念付诸实践。(此外,张佳娜还能挤出时间,在其他领域施展产品才能——她是天使投资人 ,也担任斯坦福大学讲师 ,教导那些刚刚踏上早期产品构建之旅的学生。)

    回顾所有这些经历,可以清晰地看到,“爱”正是张在产品设计理念中的核心——也是她持续推出深受用户喜爱的产品的秘诀。她认为,若企业希望保持竞争力,产品团队就需要更加细致地关注一款初生产品的 “可爱度”,而不仅仅是 “可行性”。“最小可行产品之所以有吸引力,是因为它成本低、能更快推向市场。但我们已经超越了‘产品是第一’的时代,”她说,“更激烈的竞争意味着 最小可行产品已不再足够。如果初创公司真的想脱颖而出,就需要努力打造一个 最小可爱产品。”

    张老师在与斯坦福大学的学生们讨论时用了这样一个比喻:“假设你想测试人们是否喜欢披萨。如果你给他们吃烤焦的披萨,你得到的反馈并不是他们是否喜欢披萨,而只是他们不喜欢烤焦的披萨。同样地, 当你仅仅依赖最小可行产品(MVP)——即最快、最便宜的功能原型时,你很可能并不是在真正测试你的产品,而是在 测试一个糟糕的、有缺陷的版本。”

    image.png

    最低可行喜爱产品(MLP)的概念听起来不难理解:如果你的学习过程基于一个更接近用户可能会喜爱的早期产品,就能获得更有价值的洞察。然而,尽管 MLP 是一种常见理念,常常在产品设计宣言中被提及,但为了打造真正令人喜爱的产品,创始人和产品设计师需要将这一概念从理论层面落实到具体实践中。

    “从宏观层面来看,构建人们喜爱的产品这一理念很难让人反对。 但真正投入心力去打造这些产品,并去理解那些用户,则完全是另一回事。这绝不是在测试版里随便加几个亮眼功能就能交差了事的 ,”张说道,“作为产品构建者,我们需要深入一层去探究。喜爱究竟意味着什么?你如何识别出什么能让产品变得令人喜爱?又该如何快速高效地做到这一点?”

    在此次独家访谈中,张深入剖析了深刻理解“最小可爱产品”(MLP)为何能为创始人及产品负责人带来益处。她阐述了四个原则,帮助创始人及产品经理精准锁定需要解决的恰当问题。随后,她讲解了如何将 MLP 付诸实践——只需细心关注用户需求,再加上一点神奇的魔力。

    在不该寻找可爱之处寻找可爱:一则警示故事

    推出 MLP 能为各种规模的公司带来巨大优势。“如果你身处早期创业公司,你需要有能力说服用户留下来,同时你通过‘构建-测量-学习’循环,在通往强劲产品/市场契合度的道路上不断前进,”她说道。“对于大公司而言,打造 MLP 表明你足够关心用户,愿意持续投入产品及新产品线,让用户再次想起当初爱上你们产品的原因。”

    打造一个“最小可爱产品”需要建立在扎实的理解基础之上。“如果你对如何实践 MLP 没有清晰的把握,很可能会浪费大量时间,最终打造出一个你自认为可爱、但实际上并非如此的产品,”张说道。

    她分享了在 Dropbox 时汲取的一个惨痛教训,用以说明团队若未能理解早期产品如何赢得用户喜爱,会带来怎样的后果。当时,张负责主导 Project Harmony,该项目的核心功能是当其他用户打开同一文档时向用户发出提示。

    “看到其他协作者”这一功能解决了一个明确的痛点:此前,如果两个用户在不知情的情况下同时编辑同一文档,就会产生两个冲突的文档副本。新功能背后的思路是,如果用户能看到彼此正在编辑同一文档,协作效率或许会更高。

    “在项目初期,我们满足了于实现‘看到文档中是否有其他协作者’这一能力,认为这已经足够上线了。”她说道。尽管 Project Harmony 发布后收获了不少好评,但张回顾时认为,这款产品离“让人喜爱”仍有距离。

    “事后看来,我们错失了最有价值的洞见,”张说。“能在文档中看到其他人确实很实用——你大概会因此退出文档,避免版本冲突。但这仅仅解决了一个非常基础的痛点,并没有真正提供用户会喜欢的功能。”

    讨人喜爱的产品不仅仅具备功能或实用性——它们还体现出对 用户认为有价值的东西的敏锐理解。

    “如果你深究是什么让 Google 文档用起来如此令人愉悦,那不仅仅是因为你能看到文档中还有其他协作者——更在于你能以绝对实时的方式看到每位用户的编辑,一个光标一个光标地追踪,”她说。“就 Harmony 项目而言,能在文档中看到另一个人虽然有用,但终究无法让人满意。事实上,它暴露了 Dropbox 产品的一个根本局限:当时它还未能支持基于云端的实时协作编辑。如果我们一开始就花时间去 理解用户最看重什么,就不会做出同样的投资了,”张说。

    你的爱有多深?聚焦问题的四个原则

    无论你是刚起步的初创公司,还是成熟企业的成员,实践 MLP 方法的第一步都别无二致:“从为用户解决高价值问题出发,然后对用户的需求与动机保持深度好奇。” 张如是说。

    张强调了她在引导创始人和产品经理聚焦问题时所使用的四项原则:

    1. 从用户的“为什么”出发,而非业务的“为什么”。

    2. 将问题空间与解决方案空间区分开来。

    3. 倾听用户的声音,但别把用户的话当作金科玉律。

    4. 进入解决方案空间,选择你的战场。

    下面,她将对每一条原则进行拆解,并结合自己在教学和产品管理中的丰富实例加以说明。

    1. 从用户的“为什么”出发,而不是业务的“为什么”。

    “ 如果说企业会陷入一个陷阱,那就是它们只关注‘业务层面的为什么’,而不是‘用户层面的为什么’,”张指出。“企业自然会从业务需求出发,这只是它们的运作方式。但作为产品负责人,如果你不将其与用户的‘为什么’结合起来,就无法为团队设定出有效的问题陈述。”

    如果产品经理将精力集中在解决“业务层面的为什么”,而非“客户层面的为什么”,那么他们所打造的产品将远远无法触及“可爱”这一层面。

    回到“和谐项目”的例子,张的团队忽略了用户的“为什么”。“用户的‘为什么’并不只是不喜欢冲突的副本。他们希望多个协作者能同时处理同一份文档,并实时进行修改。所以当我们试图在‘和谐项目’上持续迭代时,其实只是在优化一个 局部最优解,”张说道。“反之,如果我们更早地把那些资源投入到构建一个更具吸引力的产品上,比如后来成为 Dropbox Paper 或 Spaces 的技术,我们就能朝着 全局最优解 努力。”

    image.png

    为了进一步说明这两个“为什么”之间的差异,张分享了她在 Airbnb 工作时的一个例子。她当时领导了多个供给端团队。“Airbnb 的一个关键业务‘为什么’是增加房源的供给量。这显然是我们最关注的事情,因为房源供给增长是整体预订间夜量的先行指标,”她说道。

    但增加房源供给并没有解决以用户为中心的“为什么”。“当然,你可以说增加房源供给能给房客更多选择。但更多的房源真的是我们客户真正想要的吗?”张说道。

    对用户更深刻的理解,能带来更精准的“为什么”陈述,也更容易催生出令人喜爱的解决方案。“并非所有供给都是一样的。用户不想看到自己不想去的地方有更多住宿选择。他们希望滑雪场、海滩或重大活动举办地等热门地点能有更多房源,”她说。“爱彼迎需要在顶级市场增加供给,以便用户在理想的出行目的地有更多选择。这才是以用户为中心的‘为什么’。”

    “我们的优先事项从单纯的‘增加供给’转变为‘在某些市场优化高质量供给’,这是迈向‘令人喜爱’的第一步,”她说。这帮助她为爱彼迎的供给团队更清晰地定义了最小可行且令人喜爱的产品以及恰当的衡量指标。

    张有一项简便的检验方法,可以帮你判断自己的目标是否方向正确。

    “从这句话开始: 如果这个产品能够……,那岂不是太棒了?”她说道,“ 你的这句话应当以用户的价值作为结尾。 它应当构建出问题框架,优先考虑用户的需求和期望。”张分享了她在推出 Airbnb Plus(爱彼迎更高端的住宿层级)时,如何聚焦于“为什么”:

    不要问: 如果这个产品能帮助爱彼迎与豪华酒店竞争,那岂不是太棒了?

    而是问: 如果用户拥有多种高质量的选择,让他们宝贵的假期时光变得更加特别,那岂不是太棒了?

    2. 将问题空间与解决方案空间区分开

    斯坦福的学生们在学期初走进张的产品管理课堂时,已经对期末项目充满各种想法——他们要打造一个新产品,并经历完整的产品生命周期。学生们常常开始热烈讨论:构建某个领域的下一个 marketplace、为某类用户打造一个新平台、做某个细分领域的 Uber……

    张会立刻叫停他们。开课第一天,她就明确了课堂的第一条规则: 在学期的前三分之一时间里,不要去想自己的创意。

    “能够把自己‘认为’用户需要的和他们实际体验的区分开,通常是产品经理最难学会的一课——但这正是打造可爱产品的基石,” 张说。“这在早期初创公司中尤其困难,因为创始人往往对自己的想法充满热情。但如果你不愿意放下一开始设想的解决方案,就无法吸收关于问题本身的有价值反馈。”

    永远不要从解决方案开始。你更喜欢锤子或螺丝刀,并不代表它就是修理坏掉东西所需的那个工具。

    3. 倾听用户,但不要奉为圭臬。

    “为了深入理解用户的高价值问题和痛点, 你需要把握好平衡: 既要认真倾听用户,但又不能字字照搬 ,” 张说道。

    她在这里指出了团队在进行用户访谈时容易犯的常见错误:

    询问客户想要什么。 “当你问用户想要什么时,他们往往会谈论自己认为你可以为他们构建的解决方案。过分字面地理解客户会限制构思的广度。”

    将自己定位为权威的声音。“用户常把你——产品经理——视为问题的专家。其实不然, 他们才是专家。从一开始就要明确这一点,否则你将无法挖掘出用户真正在意的东西。”

    初创企业在进行用户访谈时需要格外讲究方法,因为初期用户规模小,可用于研究的资源也较少。

    “尤其是初创企业,首先要 明确目标用户画像。 要让多种不同类型的用户都喜欢你的产品很难,特别是在起步阶段。 应集中精力与足够多的目标用户类型进行访谈,并通过提出开放式问题,确保获取正确的数据 。”她说道。

    为了从用户中获得最有价值的洞见,张建议提出以下问题: 你觉得什么事情既繁琐、又让人压力大或痛苦?

    “从问题入手。如果用户说:‘这件事让我特别头疼。真不敢相信我每天要花这么多时间在这上面。’那你很可能就找到了一个很好的介入机会。”她说道。

    如果你无法倾听用户的声音,你甚至可能连一个可行的产品都做不出来,更不用说打造一个让人喜爱的产品了。

    4. 进入解决方案空间,选择你的战场

    最后,一旦收集到足够的数据,就带领团队从问题空间进入解决方案空间。以下是张老师在学生中采用的一个练习方法:

    画一条竖线。在左侧, 只写下可能存在的问题。“如果在头脑风暴中听到任何听起来像解决方案的内容,就把它记在右侧。先认可这个想法,但暂时不要讨论右侧的任何内容,”张老师说。 将问题与解决方案明确分开,有助于讨论始终聚焦于用户的“为什么”,而不是业务的“为什么”。

    image.png

    “一旦所有问题都摆上台面,就要聚焦于你认为自己能够解决的那个最有价值的问题,”她说道,“当我指导学生这样做时,我会让他们判断:这到底是不是他们本季度真正想要投入的游戏。”

    张教授也鼓励创业者“选好自己的游戏”。“问自己: 你是否有合适的人才来解决这个问题?你愿意花 5 到 10 年时间去解决它吗? 有意识地选择你的游戏,不仅能帮助你定义问题空间,也能为你的解决方案空间设定约束条件。”

    最后,一旦学生们聚焦于问题空间、确定了最有价值的问题并选好了自己的游戏,他们就可以展开张教授所称的“解决方案空间构思”。“从始至终,整个方法都与设计思维类似,”她说道,“ 首先发散,理解问题空间;收敛到最重要的问题;再次发散,提出解决方案;最后 收敛到既可用又令人喜爱的那个解决方案。”

    “一旦理解了问题所在,就可以开始思考可能的解决方案。然后把这些方案带回给用户,”张说,“接着问他们:‘在这些方案中,哪些是你们希望真实存在的?’”

    要区分一个可用的方案和一个令人喜爱的方案,就要留意用户的反应。“大多数情况下,人们看到原型会说:‘这很酷,我觉得自己会用得上。’这没问题,但那不是你的目标,”张说。“ 你要让用户说出: “天哪,我什么时候能用上它?” 这时候你才知道自己打动了他们 。如果他们没有这种反应,要么是你的产品还不够讨人喜欢,要么——更可能的是——你没有解决一个高价值的问题。”

    当用户试用你的原型时, 他们的脸上应该露出欣喜之色。如果用户没有被你的产品打动,那你很可能并没有解决一个高价值的问题——人们也就不会愿意为你的方案买单。

    心中多一点爱:交付可爱价值的核心要点

    一旦你对问题有了深刻理解,就该将你的“最小可爱产品”(MLP)付诸实践了。在本节中,张阐明了如何将 MLP 从提案落地为产品——从在速度与可爱度之间取得平衡,一直到用户测试的最终考验。

    在“最小”与“可爱”之间取得平衡

    创造最小可爱产品最难的挑战就藏在它的名字里:如何用最少的投入,打造出最受用户喜爱的产品?

    “这就是为什么在开始前先建立深刻理解如此重要:它能让你洞察用户的核心问题。 当你着手开发时, 只需聚焦于真正能为用户带来价值和愉悦的一两个功能。这正是 MLP 既能保持‘最小’,又能做到‘可爱’的关键所在。”

    如果你试图用产品解决所有问题,最终每件事都会做得一塌糊涂。我称之为 “花生酱原则”:涂得太薄,就不再美味了。

    当一个团队忽视了“最小化”,却过度追求“令人喜爱”,时间和资源就会出问题。张在推出 Airbnb Plus 时,她的团队需要确定哪些特征能让 Plus 房源明显优于 Airbnb 的经济型选项。她说:“我们问自己,‘哪些具体细节能让一个空间更像酒店?’”

    起初,她的团队在“令人喜爱”的方向上用力过猛。“我们列出了一份包含 200 项酒店级设施的清单,认为 Plus 房源必须配备这些:遮光窗帘、每张床四个枕头等等。但当我们真正审视这份庞大的清单时,心想: 如果要求全部满足,我们一个达标的房源都找不到 ,”张说。

    为了纠正方向,她将注意力集中在真正让爱彼迎脱颖而出的特质上。“人们喜欢爱彼迎,并不是因为它像酒店,而是因为他们可以和家人一起做饭,或者一窥房东独特的设计风格,”她说道。她的团队没有采用酒店级别的标准清单来定义 Plus 系列,而是加倍投入到那些让爱彼迎感觉像家的元素上。

    “为了实现这一目标,我们将重点转向提升线上预订体验,”张说道。“针对 Plus 系列的房源,我们推出了‘房屋导览’功能,让用户可以通过照片‘穿行’于每个房间。整个流程就像一场数字化的开放日活动——仿佛用户正推门走进某个人的家中,受到欢迎。 这才是一种令人喜爱、独具爱彼迎特色的体验。”

    不要过于纠结细枝末节,以至于忽略了 用户真正喜爱你产品的核心所在。

    此外,投资一项数字化功能最终被证明是一种更高效的资源配置方式。张表示:“投资一个精心策划的数字化功能,远比试图将实体物品塞进这些房屋要便宜得多。”她的团队在“最小”与“可爱”之间找到了完美的平衡。

    这种平衡之道不仅有助于思考“如何”解决问题,也有助于判断“哪些”问题应优先处理。张及其团队在优化 Airbnb 房东端的移动应用时便直面了这一挑战。项目初期,她和团队遵循了四个原则来深入剖析问题:通过细分用户画像以理解客户的“为什么”;借助调查问卷和用户小组收集反馈;在着手解决方案之前,先识别出最核心的问题。

    首先,他们让收件箱更易于访问。“在与用户交流并分析了上一版应用的数据后,我们意识到收件箱是最常用的功能,但它却被隐藏在侧边菜单中。于是我们把收件箱移到了首页,”她说。

    其次,他们更新了日历功能,使房东可以同时查看多个房源。“我们本可以对日历功能做很多改进,比如高级价格开关或数据屏蔽。但归根结底,对用户来说最重要的是能够一次性查看所有信息,从而更高效地规划自己的时间。”

    最后,他们引入了一个新功能,简化了房东繁琐重复的操作流程:允许用户保存常用的消息模板,例如入住指南等。“说实话,这个功能是我们用户研究中的一个意外产物;在此之前,我的团队一直热衷于解决诸如提升收件箱搜索的速度或精细度等问题,”张说,“但我们发现,房东搜索收件箱的一个重要原因,其实是为了复制粘贴消息。这是一项繁琐且重复的工作。因此,能够发送消息模板,最终成了房东最喜欢的功能之一。”

    由于团队精准聚焦于最棘手问题的最讨喜解决方案,整个重新设计在不到六个月内完成。”我们在 Airbnb Open 上发布了重新设计的应用,房东们真的起立鼓掌。他们对这些改变非常满意,”她说道。

    ” 你很清楚你的产品有无数可以改进的地方。但请专注于对用户最重要、且你能及时交付的部分。 这种优先级排序,正是打造一款讨喜应用的关键,”她表示。

    同样的优先级原则也适用于从零起步的初创公司。”如果你在问题领域做足了功课,就会知道什么对用户最有用、最有价值。从那个最关键的功能开始设计你的产品,”她说。”想想 Dropbox: 它最初是作为 U 盘和闪存盘的替代方案而诞生的。如今,它在消费级和企业级市场提供了一整套协作产品。”

    从一个能让你的产品不可或缺的功能开始。然后在此基础上逐步构建。

    最后,要结合具体场景理解你的用户。在决定如何打造一款 MLP 时,媒介至关重要。“你需要了解用户对某种媒介的期望是什么,”张说。“人们在桌面上需要什么?如果你在开发一款手机应用,那么在手机上、在当下,人们又需要什么?”

    张指出,这正是早期 Airbnb 房东应用程序的短板所在。“最初,桌面网站上的每个功能都被直接移植到了移动应用上。这款应用基本上就是桌面版的移动克隆体,”她说。“但当你真正观察用户如何使用不同平台时,就会发现这根本不合理。房东会用手机拍照和回复消息,但不会用它来完成更繁琐的工作,比如上架房源或研究当地法规,”她说。“正因为忽略了这一点,最初的应用想要面面俱到,结果却样样不精。”

    接受用户的“不规范”行为

    “有时候,观察用户做出与产品预期功能相悖的行为,反而能让你洞察到什么才是真正讨喜的功能。”张说。

    她分享了在手游公司 Pocket Gems 工作时的一个故事。当时是 2011 年,正值《Farmville》这类游戏风靡之际,她的团队正在开发一款名为《Tap Paradise Cove》的游戏。“《Paradise Cove》的核心设计是让玩家点击一块土地,进行‘耕作’以种植作物。”她说。

    但张注意到,用户的注意力却被其他地方吸引。游戏的开场画面是一个笼罩在雾气中的岛屿鸟瞰图,雾气很浓,玩家只能隐约看到从雾中露出的房屋顶部和一些物体轮廓,却无法看清它们具体是什么。起初,这纯粹是出于美学考虑。“但我们发现,玩家会不停地点击从雾中露出的那些物体,尽管它们在游戏中并没有实际用途。”她说。

    为了延续迷雾在玩家心中激起的好奇心,张及其团队围绕这些笼罩的物体设计了多个叙事任务,并巧妙地将用户的“错误”操作转化为产品的核心亮点。

    仔细观察用户与产品的互动方式。当用户的行为超出你的预期时,他们或许恰恰在引导你发现他们最钟爱的功能。

    注入魔法元素

    此外,打造“最小可爱产品”不仅关乎识别哪些细节至关重要,更在于能从中获得乐趣。“我喜欢称之为 ‘魔法元素’。那是用户旅程中的一个神奇时刻,用户会意识到这款产品与他们之前体验过的任何产品都截然不同。”

    她强调,为产品功能注入“精灵粉尘”并不需要花费太多精力。张在此提供了一些你可以自问的问题,以确保你的“精灵粉尘”产品能够成功起飞:

    当用户注册你的产品时,他们首先应该感受到的情绪是什么?

    什么能让用户会心一笑?

    什么能成为用户愿意为你的产品大声叫好的理由?

    “最后这一点至关重要。尤其是在初期,你的产品应该能激发用户想要告诉朋友的欲望。 口碑能形成一个强大的增长飞轮——而惊喜和愉悦感恰好是绝佳的谈资。”张说。

    张在 Airbnb 开发的一个功能表明,给用户留下难忘体验并不需要复杂的设计。“当旅行者接近目的地并打开 GPS 定位时,屏幕上会自动弹出入住指南。用户只需轻点一下,就能获取钥匙藏在哪里、密码锁的密码、WiFi 密码等所有关键的入住信息。”她说。

    这个小小的举动之所以效果显著,是因为它预判了一个关键痛点:当你身处一个陌生的地方时,慌忙查找入住信息的那种紧张感。“创造有效的‘魔法体验’不仅意味着知道该做什么 ,更要 清楚在什么时候做对用户最重要 。” 她说。

    张重点关注了一家善于借助“仙尘”助推产品腾飞的公司。作为天使投资人,她投资了移动餐饮订购公司 Snackpass。这款应用在耶鲁大学校园上线,目前已覆盖多所主要高校。“从我初次试用他们的产品起,整个体验中无处不在的‘仙尘’就令我惊艳,”她说,“从文案里精心挑选的表情符号,到‘爱你一拿铁’这样双关的赠礼功能,产品对校园用户群体的关注可谓无微不至。”

    Snackpass 体现了一个关于“仙尘”的关键洞见:它之所以强大,是因为 精准回应了特定用户的痛点。“没人想要千篇一律的仙尘。 要具体明确什么最能打动你的用户 ,”张说道。(事实上,在投资之前,她还通过朋友在读大学的弟妹们验证过 Snackpass 的“仙尘”——这些年轻人都在校园里使用这款应用。“小年轻们证实它确实对路,”她笑着补充。)

    这是 Snackpass 的一个优势。“那种随意、有趣的沟通方式很能引起他们受众的共鸣。但如果你把同样的做法照搬到另一个受众群体上,效果就不会那么好了,”她说道。

    可爱即战场:将“最小可爱产品”付诸检验

    最后,要采取审慎的测试方法,以判断你的产品是否真正讨人喜爱。“如果你一次性向所有人发布,你会收到混杂的反馈,很难从中有所作为,”张说。

    她建议采用一种渐进、结构化的测试框架来判断产品是否具备那种魔力:在全面发布之前,先从测试版中挖掘洞察。“ 人们没有充分利用他们的测试版 ,”她说。“改版后的 Gmail 在测试版阶段持续了很长时间,对吧?仅仅通过测试版,你就能收集到最有价值的反馈,更不用说还能实现不少用户增长了。”

    在测试你的“最小可行产品”时,不要过分看重内测用户的反馈。“内测用户群体是那些已经喜欢你的人,他们甚至会觉得你的最小可行产品也很棒。他们就像你的妈妈,无论你做什么她都会喜欢,”张说。

    与此相对,你的普通用户群体要怀疑得多。“以爱彼迎为例,普通用户群体中包括了那些根本不敢使用爱彼迎的人,因为住在别人家里这个想法对他们来说太不可思议了,”张说。“要取悦普通用户群体要难得多。赢得他们的信任很难,而一旦失去,想要重新获得更是难上加难。”

    推出不讨喜的功能就像那个喊“狼来了”的孩子。 你可以再推出一项新功能,但无法保证第二次还能赢得用户的信任。

    你的公测用户群体则是测试的理想对象。“和你的内测用户一样,公测用户群体会支持你。但同时,他们也愿意给出建设性的批评意见,”她说。“爱彼迎的公测用户是那些至少使用过10次爱彼迎并且感到满意的人。不过,他们也记得一些不太顺利的时刻,比如入住过程不够顺畅,或者被锁在门外——他们会把这些反馈告诉别人。”

    在测试版中检验你的“魔法亮点”至关重要,因为你已经与那些愿意提供宝贵、坦诚反馈的用户建立了信任关系。“这让你有余地去冒险,同时不会损害自己的信誉,”她说道。

    image.png

    一切皆需热爱:MLP 与创业公司的未来

    如果初创公司希望打造出用户钟爱且能在竞争中脱颖而出的产品,那么将标准从“可行”提升至“可爱”就显得尤为重要。构建最小可行产品(MVP)的起点,是聚焦于用户最痛苦的问题。选择一两个最能直击该问题的功能,然后在有限资源下,平衡“新奇”与“熟悉”的元素,创造出最令人喜爱的体验。最后,设法加入“魔法亮点”,并在那些准备好对你“严苛关爱”的用户群体中进行测试。

    回顾她在游戏虚拟世界中增添趣味、在 Dropbox 解决生产力挑战、在斯坦福教授学生、以及为 Snackpass 等公司提供咨询的经验,张对 MLP(最小可爱产品)的未来充满希望。而在 Airbnb 及现在的 WeWork 工作期间,她一直在尝试新的方法,在软件与物理空间交汇的混合世界中构建 MLP。

    “未来十年,在像素之外创造神奇体验的空间非常大。接下来十年的许多产品,都将是数字与物理领域某种程度的结合,”她说。“我们只会看到更多创造魔法的可能。”

  • 为什么传统的用户调研只是在浪费时间?

    人们根本不知道自己想要什么,产品经理与其花时间做用户调研,不如为工程师撰写任务单。以下是为什么用户那些过于自信的预测毫无价值。

    史蒂夫·乔布斯讨厌用户调研是有道理的,因为他热爱“首次使用体验”。图片来源:AB Unsplash

    我从其他专业软件工程师那里听到了一个行业趋势,想在这篇文章中讨论一下。有时候,产品经理会更倾向于“与用户交谈”(用户研究),而不是花精力去识别并记录产品的功能和缺陷修复。

    我想这是因为,如你所知,写下工作项(“工单”)——事实上——本身就是工作。它既枯燥又令人厌烦,但却能帮助工程团队取得成功。然而,通过长时间的视频通话与用户“闲聊”并不“像在工作”——因为——嗯——它根本就不是。

    (平心而论,对于全职的用户研究员来说,他们通常会做一些事情,比如记录用户完成特定任务所需的时间,或者使用热力图来量化光标的位置;从我听到的小道消息来看,大多数产品经理所做的“用户研究”似乎只是结构松散的对话而已。)

    通常,当团队中没有全职、专业的用户研究员时,产品经理和/或产品设计师就会介入填补这一角色。这看似合理,直到工程师们为了等待任务而无所事事,并且还得替那些产品经理和设计师去编写任务单。

    “用户研究”听起来确实像是一项重要且与工作相关的活动,对吧?

    但用户研究不仅会占用支持工程团队的时间——这些团队普遍缺乏足够的技术人员——而且它本身其实就没有实际用处。史蒂夫·乔布斯也认同这一观点:

    “人们并不知道自己真正想要什么,直到你把它摆在他们面前。这就是为什么我从不依赖市场调研。我们的任务,是去读出那些尚未落于纸上的东西。” —— 史蒂夫·乔布斯

    这就是为什么我希望产品经理能把他们做“用户研究”的时间,用来为工程团队撰写任务单。

    产品经理的薪酬用来支付什么?

    在一个资源有限的团队中,尤其是那些没有足够软件工程师来按计划推进产品路线图的团队,总得有人来补位,把那该死的任务单给写了。

    在我们团队,写任务单是谁的活?在大多数有幸拥有产品经理的团队里,这主要是产品经理的职责。

    但许多产品经理显然把相反的理念奉为圭臬,即“工程师应该写任务单”。等等,什么?

    据在以这种方式运作的团队中有经验的人士透露,产品经理的“职责只是界定问题或机会”,而不是将其写成任务单。从我读到的相关讨论来看,产品经理们显然忙于与用户沟通及与利益相关者开会,无暇撰写任务单。

    当然,如果你有足够的软件工程师——尤其是相对于产品路线图而言存在富余工程师的情况(我从未见过,但据称在某些公司确实存在,尤其但不限于欧盟地区)——那么工程师们写出的任务单往往比产品经理的更好。

    在这种情况下,当然可以解雇产品经理,让工程师来写任务单。工程师可能讨厌写任务单,但把预算花在雇佣更多程序员和减少中层管理者上,是一种更高效的资源利用方式。

    如果真是这样,既然工程师已经在写任务单了,为什么还要留着产品经理?他们整天到底还能干什么?

    用户研究!(当然!)

    嗯,好吧,那通常是怎么进行的呢?“用户研究”通常指持续 30 到 60 分钟的非正式对话,涵盖以下主题,这些主题选自一篇关于定性用户访谈的 Hotjar 文章 :

    1. 你对这个原型的第一反应是什么?

    2. 你喜欢这个原型的哪些方面,不喜欢哪些方面?

    3. 你会如何改进这个设计?

    4. 在类似的产品中,哪些功能对你来说最重要?你喜欢这款产品的哪些方面,又不喜欢哪些方面?

    5. 这款产品是否具备你需要的功能?你还需要其他额外的功能吗?

    6. 你觉得这款产品与市场上的同类产品相比如何?

    7. 在 1 到 10 的评分范围内,您购买该产品的可能性有多大?

    8. 在 1 到 10 的评分范围内,您完成这一特定任务的难易程度如何?

    9. 在 1 到 10 的评分范围内,您向朋友或同事推荐我们的可能性有多大?您给出该评分的原因是什么?

    10. 什么能改善你的体验?

      你是否注意到,用户(无论是潜在用户还是现有用户)在自信满满地回答这些问题时,会(并非有意地)说谎?

      好吧,如果你还没意识到这一点,让我带你了解一下关于“过度自信”的研究,看看为何这些定性的用户访谈大多是在浪费时间,尤其是与产品经理撰写需求票证相比。

    过度自信是用户访谈毫无用处的原因

    别误会,我绝对是你在软件工程师中能遇到的最大的客户体验拥护者,正因如此,我的整个职业生涯都专注于 UI/UX(用户界面/用户体验)产品工程。

    但在软件开发与用户偏好中,存在太多普遍适用的真理,而用户在非正式的用户研究对话中绝不会提及它们,即使这些才是真正重要的东西:

    网站和应用应当快速且高效。
    网站和应用程序应对用户输入做出响应。
    网站和应用应当清晰且易于使用。
    网站和应用不应存在漏洞。
    网站和应用应适配所有屏幕尺寸。

    我敢肯定,用户更在意以上这5项,而不是之前那10个问题的清单。然而,这些项目并未出现在之前关于定性用户访谈的资料中。难道修复漏洞不该永远是第一要务吗?

    前一部分中我引用的那些定性用户研究问题,其实没有特别大的用处,因为人们在预测自己的生活时,往往会过于自信。

    “与用户交流”会促使用户针对某个用户界面(UI)设计和用户体验(UX)给出看似确定、实则有误的回答。

    这并不是一个好主意。

    毕竟,用户通常不是软件工程师、产品经理或产品设计师,他们怎么可能对 UI / UX 一窍不通呢?

    你认为那些仅仅因为有机会参与一对一用户调研就“受宠若惊”的用户,会详细列出你在软件产品中发现的所有漏洞吗?

    你认为用户的建议——这些建议往往在未来12个多月内都无法纳入产品路线图——真的算是“好主意”吗?

    你认为用户能够准确预测自己在面对软件产品“出色的新设计”时的未来行为吗?

    无论是从研究还是个人经验来看,都极其清楚地表明:“传统的用户调研”是有缺陷的——用户并非技术人员。

    让我们来看看基于失败公司实验(新可乐)和科学研究的证据——为什么人们会自信地做出预测,尽管这些预测通常被证明是错误的。

    “传统的消费者研究挖掘出谬误的可能性与其挖掘出真相的可能性一样大。事实上,行为科学已经证明,人类在理解自身行为动机方面是多么不擅长,并且表明大多数时候消费者要么不知道自己想要什么。”—— 亚当·克利弗 (Adam Cleaver) 于 WRAC

    这并不是什么新信息,维基百科引用2002年和2008年的研究论文作为“过度自信效应”的关键来源:

    “ 过度自信效应 是一个被充分证实的 偏见 ,指一个人对其判断的主观信心 始终可靠地高于这些判断的客观准确性 ,尤其是在信心相对较高的情况下。[1][2]”—— 维基百科

    用户会自信满满地向你撒谎,说他们想要什么,却并未意识到这一点,这一现象与达克效应有关,即每个司机都自认为“驾驶技术高于平均水平”。

    你的用户就是不愿让自己难堪——或是“浪费你的时间”——承认自己不懂。所以他们会给出看似笃定的说法,但多数时候不过是毫无价值的瞎猜。

    这就推翻了询问用户想在你的软件中看到什么功能这一做法的合理性,这或许可以解释为什么 iPhone 拥有 14.6 亿活跃用户 。

    “误区21:人们能告诉你他们想要什么”

    许多组织仍然依赖询问用户希望网站或服务做出哪些改变,却忽视了诸如“新可乐”或“艾龙椅”等历史研究失败的教训。

    “在询问用户时,你必须意识到,人们会对自己未来的行为做出自信却错误的预测,尤其是在面对一个陌生且全新的设计时。”

    当一家公司向你发出私密邀请,向你展示他们软件产品“令人兴奋的新设计”时,你觉得大多数人会说:“是啊,这糟透了 。别无缘无故地乱改!” 怎么可能!

    但如果你是一款软件产品的日常用户,而他们无缘无故地改变了整个用户体验,大多数人恰恰会这么说!

    “对 NI(以及计算机行业的所有其他人)来说,以下几点已经足够说明问题——请别再无缘无故地更改东西了。别再使用那些根本不起作用的开源库了。别再添加会伤害到诚实用户的反盗版保护措施。”——bergstein,在 Native Instruments(NI)论坛上写道

    这就回到了本文开头引用的那句(臭名昭著的?)史蒂夫·乔布斯的名言,此处再列一次以供参考。完整引文如下:

    “有些人说:‘给顾客他们想要的东西。’但这不是我的做法。我们的职责是在他们知道自己想要什么之前,就弄清楚他们将来会想要什么。我记得亨利·福特曾说过:‘如果我当初问顾客他们想要什么,他们会告诉我:一匹更快的马!’人们在你展示给他们看之前,往往不知道自己真正想要什么。这就是我从不依赖市场调研的原因。我们的任务,是读懂那些尚未写在纸面上的东西。”—— 史蒂夫·乔布斯

    史蒂夫·乔布斯和亨利·福特都说得很对:消费者常常不知道自己想要什么——至少,在你的新产品凭借出色的用户体验在社交媒体上走红之前,他们是不清楚的。

    正因如此,产品经理们才需要回归到写工单的本职!软件开发的目标,应当是打造高性能、无故障的体验,而不是因为“与用户的快速交流”而每隔6到12个月就“转向”一个新的方向。

    把用户研究交给专业的用户研究人员,他们会帮助你的团队优化应用,通过缩短用户完成任务所需的时间,让用户获得更佳的体验。

    哦,还有,请优先修复漏洞。对于你的品牌来说,没有什么比发布带有漏洞的软件,然后在数月甚至数年内都不修复这些漏洞更糟糕的了。显然,修复漏洞永远是第一要务。

    总结:史蒂夫·乔布斯与亨利·福特是对的

    最后,我们以一个假设的例子来总结:一家视频游戏公司有一支人手不足、资金有限的软件工程团队,该团队目前只有一款 PC 应用,但希望同时在 Xbox、PlayStation 和 Switch 平台上发布产品。

    在这种情况下,用户属于玩家群体,因此可以合理推测他们家中至少有一台游戏主机,更不用说他们还拥有手机,并且不会介意游玩该游戏的手机版本。

    如果与用户交流,他们很可能会表示希望获得主机移植版,并声称自己使用主机版的频率将超过现有的 PC 版——尤其是在你提出诱导性问题时:“相比现有的 PC 游戏,您会更频繁地使用主机移植版吗?”

    但在这个假设案例中,即使你真正为他们提供了所期待的主机版本,最终可能只会观察到极少数用户从 PC 端迁移至主机端。

    为什么?

    你的用户已经在使用 PC 版游戏了!他们熟悉它、信任它,并且更希望你在 PC 端修复漏洞,而不是转向主机平台。这完全符合用户的实际行为模式,却恰恰与大多数人在自由式用户研究“快速问答”中的回答相反。毕竟,你的主机移植版本是需要花钱购买的,对吧?

    所以,没错,移植版听起来是个好主意, 但你的用户和其他人一样,非常不善于准确预测自己未来的行为!

    正如内特·希尔弗在其著作 《信号与噪声》 的概要中所解释的那样:“无论是专家还是普通人,都会把更自信的预测误认为是更准确的预测。但过度自信往往是失败的原因。”

    由于你的产品经理、产品设计师和高管团队也和其他人一样,他们会理所当然地认为,用户研究中的那些“自信的陈述”就是关于用户未来行为的“准确的陈述”。

    他们也会陷入自身的达克效应,认为自己在本职工作中“高于平均水平”,尽管没有任何证据必然支持这一结论。

    由于对自己的技能过于自信,那些非专业的用户研究员(如产品经理、产品设计师、高管等)几乎总是会表面化地接受用户的陈述,而不理解人们所说的和所做的之间存在差异。

    每个人都对自己的能力过度自信,无论是作为利益相关者评估用户研究,还是作为参与用户研究的用户预测自己未来的行为。

    如果仅以定性用户访谈作为唯一的用户研究方法,而不结合定量可用性测试(观察并计时用户在产品中完成任务的过程),那就是垃圾进,垃圾出 。

    但用户访谈“看起来像是在干活”,而且比产品经理真正应该做的事情有趣多了。产品经理的真正职责是与利益相关者和设计师协作确定产品需求,然后撰写需求文档。

    产品经理:滚回去干活,别去打扰用户了。(用户根本不知道自己说的东西有多不靠谱,你告诉他们也不会领情!)

    高管们:请另外招聘专业的用户研究人员,他们的唯一任务是缩短用户完成任务所需的时间。

    软件工程师:别去听用户访谈了,因为那些访谈内容根本一点用都没有。

    工程师不想把时间浪费在毫无价值的活动上;他们不想因为用户研究而对产品路线图进行无休止的、最后一刻(“敏捷”?)的调整;也不想撰写大部分的任务工单。

    这就是为什么我认同史蒂夫·乔布斯和亨利·福特!

    你不能相信定性的消费者研究(“你想要什么?”),唯一值得相信的是销售数据(收入)以及真实用户在完成真实任务时的量化耗时。

  • 《微信背后的产品观》笔记

    用户篇

    1. 人是环境的反应器

    2. 人是懒惰的

    3. 时尚是驱动力

    4. 人是没有耐心的

    5. 人是不爱学习的

    6. 群体是乌合之众

    7. 重视草根用户群

    8. 从日常体验中发现本质

    9. 人性化就是以己推人

    10. 需求是满足人们的贪嗔痴

    需求篇

    1. 对于新点子,99%的情况下否定是对的

    2. 不要用户说什么就做什么

    3. 从同类产品里找需求很省事,却不是好方法

    4. 不要听从产品经理的需求,需求只来自对用户的理解

    5. 找到需求背后的心理诉求

    6. 心理满足的驱动力,远胜工具甚至省钱

    7. “爽”胜过功能

    8. 为群体效应而做:附近的人(需求来自对群体效应的好奇)

    9. 为想法而做:朋友圈(自身和周边朋友的反馈)

    10. 需求来自对信息流的理解

    11. 对未来的理解比当前的需要更重要

    设计篇

    1. 产品是进化出来的,而非规划出来的

    2. 把用户分为高中低端是不道德的

    3. 先做产品结构,之后才是功能细节

    4. 功能模块之间是有机联系的关系

    5. 设计就是分类

    6. 抽象方能化繁为简

    7. 越简单的分类越易于被接受

    8. 找到需求背后的本质需求

    9. 面向场景,才能取舍

    10. 让功能存在无形之中

    11. 区别手机和pc

    12. 不过度设计

    13. 宁愿损失功能也不损失体验

    14. 倾向于做本质的东西,我们做“类型”,用户产生“实例”

    15. 让用户推动用户,自发行为,而非引导

    16. 面向未来的场景做设计

    17. 操作的响应速度永远是第一体验

    18. 如果一个特性不能让人兴奋,不如不做

    19. 保留变化

    20. 如果没有自然增长,就不必推广

    21. 保持粗放,保持笨拙

    22. 如果解决方案非常复杂,一定是问题错了

    23. 在每个细节中体现认知

    24. 给用户选择权

    25. 尊重用户

    26. 把用户体验做到极致就是创新

    27. 你的价值观(态度)决定产品的特性

    28. 抛弃不人性的创新

    29. 避免战略行为替代真实需求

    30. 从人出发,改变商业模式

    31. 没有设计,只有解决问题

    气质篇

    1. 改变旧世界的意愿

    2. 有自己的理念和愿景

    3. 微信是“一个生活方式”

    4. 即使做一个广告,我们也要做得非常人性化

    5. 我们要找最牛的合作方

    6. 文字反映气质,不讨好用户,不抬高自己,把用户当朋友来沟通

    7. 未来感设计:未来/科技/抽象/简约

    8. 你没有竞争对手,重要的是我们要做什么,而不是他们在做什么

    9. 是作品,而不是产品

    10. 工匠,而不是设计师

    11. 做有灵魂的产品,一个产品应该像一个人一样,有多面

    UI篇

    1. UI是围绕特性的,而不是特性围绕UI

    2. 对最常用的操作精益求精

    3. 需要文字解释的功能不是好体验

    4. 隐藏数字

    5. 于细微处用心

    6. 锻炼自己的审美能力