用户故事，产品经理必备知识拼图

产品与开发之间，常常发生如下场景：

产品小白：老哥，有没有空聊一聊这个需求呀？

研发大佬：没空！一边去！

产品大咖：老王，这两天我听到有个用户的故事非常有意思的，要不要听听？

研发大佬：额……（迟疑了会，放下手上的工作）咋说呢？

同一个事情，产品大咖说出来的效果，差别真的不是一点点。

少提需求，多讲用户故事！从3年前那场为期5天的封闭式敏捷培训后，这个技（tao）巧（lu）深深印在我的潜意识里。

如果你是下面4类人群，请继续往下读：

1. 准备从事互联网，对产品概念了解甚少的小伙伴；
2. 不知道什么是用户故事的产品新人；
3. 仅了解概念，不知道具体怎么应用的产品同行；
4. 完全了解用户故事，看完想指导我的产品前辈。

一、用户故事是什么？

首先先来解答小朋友们的问号。产品大咖口中的用户故事是什么呢？我从两个方面，给出解释：

百度百科：用户故事，意思是来描述用户渴望得到的功能

我的理解：产品经理将目标用户真实的需求提炼后与研发同学沟通的一个载体

核心关键词：三个角色、一个载体

1）三个角色：产品、研发、目标用户。

用户是我们的爸爸，衣食父母，产品经理的使命就是将用户的需求清楚地告诉给负责具体实现的研发。

2）一个载体：用户故事。

连接这三个角色的一个载体。当然，这它并不是唯一的载体，但相对更加高效和容易接受。

既然是载体，它就有高低好坏之分。有的人造出来的载体是飞机火箭，有的人却是一辆爆胎了自行车，学问可大着呢！

二、不会讲用户故事的产品下场如何？

产品不会讲用户故事，会很惨么？会，很惨！

这个绝非我在这里危言耸听，相信开头的场景你已略有感触。

下面我逐条给你理一理：

1）需求评审被diss

没有用户故事的需求评审，就像一个鸡肋，开发同学听了面无表情，内心惊不起一点波澜。结果就是：被开发架起机关枪，疯狂扫射，被diss得体无完肤；

2）沟通无缘无故被中止

你跟开发讨论需求时，直接被打断：不好意思，我现在很忙，没时间跟你聊。

你可能还觉得这个开发同学不好沟通，实际上：很有可能你只是老板的复读机，又用老板压开发，让人反感。

3）需求排期频频受阻

一个需求能否顺利排期，核心两个点：价值高不高、影响面严不严重。而这两个点在没有严谨数据支持情况下，都是主观感受。

需求排期一般都是会后，研发测试开会逐条排。这时需求评审会上的记忆很关键，需求够不够鼓舞人心，让人印象深刻。

不以第三方真实、典型用户的视角讲出需求，不容易让人感同身受。

4）产品能力遭到挑战

综上几点，开发同学定然会颇有微词，长此以往，形成恶性循环，产品能力不行的刻板印象，将会逐步形成，这种状况就很危险了。

三、为什么说用户故事，产品要必备？

产品知识拼图中，我们最熟悉的几个有：市场调研能力、需求撰写能力、需求管理能力。而会讲用户故事能力，同样不可或缺！

别着急反驳，看完下面这四个点，你可能就能理解了：

1）沟通，不伤感情

以用户的角度，跟开发同学沟通，更能让别人接受和有兴趣继续听下去。

不是我要提需求，也不是老板的需求，是用户的体验反馈。

2）说服，一句话打动你的听众

讲用户故事，不是长篇大论，是有结构地把用户渴望用最凝练的语言表达出来。

听众在最短的时间内按照既定的结构获取到关键信息，从而判断需求的价值。

3）共情，听见远方的哭声

做产品，最最最重要的是：成为一个小白，去深度体验复杂的社会，从而发现问题。

少谈需求，多讲用户。不是我觉得，而是用户体验反馈。这个是从观察视角和意识形态的转变。

多讲用户故事，锻炼的是共情力。时刻倾听用户的声音，解决用户的真实需求，才是真的牛逼！

4）不将就，做一个有灵魂的产品

产品做久了，自然就会油腻了、有套路了。成为了老板的复读机、竞品的抄袭机，逐渐没了灵魂。

多讲点用户故事，不将就。我们不求改变世界，但求与众不同。有思考、有想法、有内味、有灵魂。

四、讲好故事，先了解原则

一个好的用户故事，一般都遵循INVEST原则。

• Idependent（独立的）：故事之间相互独立；
• Negotiable（可协商的）：故事内容是概要，方便对齐思路，详细内容是可以沟通时候明确的；
• Valuable（有价值的）：有价值的用户故事，才是合格；
• Estimatable（可评估）：能够根据用户故事大概评估出工作量；
• Small（小的）：用户故事拆解的颗粒度是比较细的，一般用10个开发/测试人日既可以完成；
• Testable（可测试的）：一个故事是一个正向的测试案例。

这些原则，我觉得主要的是独立性、可评估、可测试。

毕竟，不独立，写得东西就乱套了。无法评估测试，开发测试同学会视为无效故事。最终的结果都是得重新写！

五、一条公式掌握用户故事写法

用户故事，通过拆词，分为：用户、缘故、事项。用一条公式概括为：用户故事=人+故+事。

标准的写法包含三段式结构：我作为怎么样的用户，希望拥有什么样的功能，以便于达到什么样的结果。

上述说到，好的故事遵循INVEST原则。下面我举几个例子，帮助大家更好理解。

1）微信的语音回复功能

好故事：我作为一个不会打字、未受过教育的用户，我希望能在微信通过语音回复我的朋友，以便于我也能快速地和朋友聊天。

坏故事：我作为一个用户，我希望通过语音回复我的朋友。

批注：坏故事在于用户定位不清楚，表达结构不完整。

2）电商平台的购物车功能

好故事：我作为一个平时一次要买4 5件商品的用户，我希望能够将商品放在一起，以便于我能够一次性支付商品的费用而不是每一件都要单独支付。

坏故事：我作为一个平时一次要买4 5件商品的用户，我希望能够将商品放在一起后能够享受折扣，以便于我能快捷支付并享受满减优惠。

批注：坏故事在于，故事不具备独立性，一个故事中有多个需求：购物车功能、满减功能。

3）产品详情页的分享功能

好故事：我作为一个喜欢分享的用户，我希望在产品详情页面上增加分享功能，以便于我能够将产品的好处告诉给我的好朋友。

坏故事：我作为一个喜欢分享的用户，我希望在产品拥有分享功能，以便于我能够分享给我的好朋友。

批注：坏故事在于，功能点过泛、多大，开发测试无法评估工作人力。

六、用户故事，有哪些应用场景？

前面我们已经知道用户故事的表达方式了，那么它有哪些应用场景呢？

第一，肯定是需求流程的关键节点

• 向上司反馈需求意向：用最直接、结构化的方式，跟领导同步你的想法；
• 找开发评估需求可行性：用第三人称口吻，让开发更乐意评估你的需求；
• 需求评审会上：以用户视角，带着开发快速体会到你需求的价值。

第二，需求评估之外，职场处处是场景

每一个跟同事的触点，都可以是展示你讲述用户故事的能力，体现你专业性和洞察力，让人眼前一亮。

第三，生活日常，用户故事也同样适用

向老爸老妈表达孝心、向女朋友表达心意、向朋友表达情谊，都是可以的！结构化的沟通，让你的表达更加清晰、更有逻辑。

被表达，是每个故事的权利；被理解，是每个人的追求。用户故事，就是达成这个目的的好手段。

希望：

工作中，我们讲好用户故事，让用户得到倾听。

人生里，我们讲好自己故事，让自己得到理解！

好了，本次的分享就到这里！