产品经理入门先学什么？需求文档和用户故事先练产品基本功

产品经理入门，指的是从接需求到把需求讲明白的那套基本功训练，最先要练的不是工具，关键在把需求文档和用户故事写到人人看得懂。小团队里兼做产品的人，最先卡住的不是原型图画得多好，是文档写完没人看得懂，评审会开成辩论赛。

新人问我产品经理怎么入门，我的答案年年一样：先学把话说清楚，再学画图。工具三个星期就能上手，把一件事讲透这件事，练一年都未必够。

产品经理怎么入门？先别急着学画原型图

为什么要先练写？你观察公司里最厉害的那个产品人，开会翻来覆去讲的都不是图，是"谁在什么情况下遇到什么问题、我们怎么解"。这个结构就是用户故事加需求文档的底子，原型图只是最后给人看的壳。

图源：《王慧文清华产品课（三）-产品篇》（第8页 · 原文）

入门顺序我建议倒着排：先用文字把一件事讲透，再画原型图。画图有模板可抄，判断没有模板。文字写不明白的人，图画得再漂亮，开发看完还是得来问你一遍。

讲句实在的，三个人的小团队连正式原型都未必需要，一份清楚的需求文档加两句话的用户故事就能开工。工具越少，扯皮越少。

原型图的坑我见过太多：图改到第8版，开发问一句"这个按钮点了之后发生什么"，答不上来。图只是壳，壳背后那套谁、在什么时候、要什么的逻辑没写清，图画得越好看，误解就藏得越深。

还有个顺序问题：先写文档还是先聊需求？我的做法是聊完当天就落文字，哪怕只有5行。当天不写，一周后你记得的只剩结论，中间那些"为什么不做"的关键理由全丢了，下次还得重吵一遍。

用户故事怎么写：先找到那1000个真喜欢你产品的人

用户故事怎么写？先破一个误区：它不是文学创作，是一句格式话——"作为一个谁，我在什么情况下，想要什么，为了什么"。四个空填实了，这个需求就立住了；填不实，多半是伪需求。

有句判断我一直记着。依据《王慧文清华产品课（三）-产品篇》，王慧文讲产品早期"宁可让1000人love你的产品，也不要让10000人like你的产品"。写用户故事也一样：别写给所有人，写给一个具体的人——楼下奶茶店老板、总加班的运营、刚带娃的宝妈。

那份课稿里还给了找早期用户的法子：做搜狗输入法的马占凯，跑去翻输入法的用户论坛，愿意去论坛留言的用户，大概率就是早期的尝鲜者。你动笔之前先去用户群里潜水1个星期，把他们说的原话抄进故事里，比你编出来的准得多。

这个翻论坛的法子现在照样能用：评价区、问答区、社群聊天记录，都是免费的早期用户研究库。花一个晚上看100条真实留言，比闭门写一星期的用户画像都值。

检验标准也给你：一条用户故事里必须有具体的人、具体的场景、具体的动作，3样凑不齐就回炉。"用户想要更快的加载"，这不叫用户故事，叫愿望。顺带说一句，iPhone也是做到第4代才大红大紫，早期产品糙一点不丢人，写给对的人就行。

故事里最容易写虚的是"为了什么"这一段。"为了提升体验"是虚的，"为了让她排队时不用问店员也能下单"才是实的。动机落到具体的人和具体的麻烦上，方案自然会跟着变对。

条数上也有讲究：小团队1个版本写3到5条足够，每条都要能对应到一个页面或者一个动作。故事是挑出来的，不是堆出来的，全都进本期就是灾难。

再给一个有效的练法：把你手头的需求，用"作为一个谁"开头，写5个不同人的版本。写不出来，说明你只了解一种用户，这正是要补的功课。写完摆在一起看，先做谁的故事，一目了然。

图源：《王慧文清华产品课（三）-产品篇》（第3页 · 原文）

需求文档怎么写：把现状一条条摆出来，比画图有用

需求文档怎么写？新人最常见的毛病是一上来写方案。我教你先写3栏：现状是什么、问题在哪、改成什么样。前两栏写实了，第三栏往往自己就冒出来了。

现状要写到什么粒度？看个例子。王慧文讲美团外卖早期糙到什么程度：接单靠客服手抄客户信息，再打电话去商家下单，没有线上支付，货到付款，平台也不提供配送。就这么糙也能跑，因为早期用户是校园里的学生，对时效要求不高。你把现状摆到这个程度，团队自然分得清哪些是历史包袱、哪些是本期必改。

粒度的上限可以看一份现成的样例：某美妆商城项目的三期需求文档，一个小样裂变活动被拆到页面级——团长怎么创建活动、授权手机号之后查会员身份、成团人数和成团距离怎么设、不成团怎么提示失败、后台要能导出哪些名单字段，一条条列清，连失败状态都没放过。写到这一步，开发拿到手不用来回猜。

图源：《王慧文清华产品课（三）-产品篇》（第2页 · 原文）

需求篇里还有个区分借来很好用：中文的"需求"其实混着三个词——Needs是用户原始的动机，Requirement是对产品的设计要求，Demand是产品上市后的需求量。写文档时分清自己在写哪一层，就不会把"用户想要便宜运费"直接翻译成"运费改0元"。动机、设计要求、市场销量，三层的差别就是新手和老手的差别。

现状写到多细才算够？给你一个自检问法：把现状那段拿给新来的开发看，他提的问题超过3个，就是不够细；1个都不提，多半是没细看。细到这个平衡点，文档就到位了。现状写得越实，方案越不用吵——因为答案往往就藏在现状里。

验收标准跟着每个功能走，写到"怎么算做完"为止。比如活动规则弹窗，验收就是3句话：新用户进入先弹规则、关闭后不再弹、后台可以配置文案。测试同学拿着就能写用例，这就是合格的粒度。

验收标准之外，最好再写一句风险提示：这个功能最坏会坏在哪。比如成团活动，最坏是人凑不齐、奖品被羊毛党刷走，对策写在旁边。开发看到风险提示，会主动把防刷的逻辑补上，这就是文档的杠杆。

文档里再备一栏"这次不做什么"。这栏比做什么还重要：不做的东西写明了，开发不会顺手多做，老板不好临时加塞，范围一收，工期才守得住。

小团队还有个好处别浪费：文档不用套大公司那套模板。一页纸，现状、问题、改法、验收4块，加3到5条用户故事，就是一份完整的需求包。模板是给协作规模服务的，不是给仪式感服务的。

改法那栏怎么写才不挨骂？只写行为，不写实现。"用户可以把自己选的小样分享给好友"是行为，"用微信卡片分享"是实现——实现方式留给开发选，你替他选了，他只能阳奉阴违。

评审会开不动？多半是优先级排序没做在前面

评审会吵成一团，十有八九不是会上吵出来的，是会前没排序。优先级排序的原则说穿了就一句：本期只做能验证核心判断的那几件事，其余全部写进不做清单，白纸黑字。

王慧文讲过一个真事：美团的CRM最开始做了3版，问题就出在没做减法，最后列了一份功能清单让负责人从中选3个，做完才算收敛。这个做法你可以直接搬：功能全列出来，逼自己和团队勾出本期的3个，勾不出来的进下一期。

排序拿不准的时候，回到那1000人的问题：这期做完，最早喜欢你的那批人会不会更喜欢？会，就排前；不会，往后放。判断标准越简单，会前拉齐越快。

减法做不下去的时候，看时间盒：这个版本就2周，2周装得下3件事还是5件事，日历说了算，愿望说了不算。时间盒一画，优先级自动浮出来，这是最不伤感情的一刀。

还差落地材料的话，运营动脉能省不少事：方案能直接下、课件能照着讲、报告能拿去引用，比一篇篇搜要集中。

会前再教一个动作：把最可能反对的人提前聊一遍。他会上要提的每一条，你要么提前吸收进方案，要么提前想好理由。会上没有意外，就是这个会开得快的全部秘密。

图源：《王慧文清华产品课（三）-产品篇》（第5页 · 原文）

会上只做确认，不做决策。排序做在会前，一对一拉齐关键的人，评审会20分钟过完。会议越短，说明前期功课越足，这是正向循环。评审会不是用来做决定的，是用来确认决定早就做对了的。

如果评审会上还是出现了分歧怎么办？记住先记下再散会：所有反对意见原样记进文档，标注哪条本期处理、哪条下期验证，当天发给全场。分歧没有被记录，就会在下一次会上原样复活，一遍一遍地耗团队。

验收标准和版本节奏：新人最常漏交的两样东西

验收标准漏写的后果，是验收那天三方吵架：你说做完了，开发说做完了，老板说这不是我要的。标准在开工前写清楚，所有人对的是同一份文字，不是各自的记忆。

版本节奏是新人产品经理最容易忽略的一件事。小团队建议2周一个版本：本周排定、下周一发版，固定的节奏比偶尔的大更新有用。需求永远做不完，节奏定住了，团队才不慌。

上线之后干什么？看数据。数据埋点要在需求文档里一起写，别等上线了才想看什么。一个活动页至少埋3处：入口点击、参与成功、分享出去。数据没埋，等于白做一期。

埋点别忘了跟开发确认上报时机和口径：同一个"点击"，按曝光算还是按去重算，数字能差出一倍。口径不写进文档，看数据那天必打架。

沟通对齐这件事，我自己的土办法是"写完必读一遍给人听"：文档发给开发之前，先念给一个不懂这个项目的人听。他哪里皱眉，哪里就是下一场扯皮的起点，回去改完再发。

别嫌这套动作啰嗦。需求讲不清的团队，返工从来不是一次一天的事：一个功能返两回，两周的版本节奏就垮了。前面多花的半小时，都是从后面省回来的。

竞品分析也顺手提一句：别抄功能清单，看它为什么这么排。把竞品同一流程的每一步截图排开，问它省略了什么、强调了什么，答案往往就是它的取舍。你的取舍不必跟它一样，但你得知道自己取舍了什么。

版本复盘也别省：每个版本发完，花半小时写3行——这期最对的一个决定、最后悔的一个决定、下期要改的一个动作。3行不多，半年下来就是你的产品笔记，比任何课程都贴身。

发版之后除了看数据，还要回收用户反馈：群里、客服记录里、评论区，每周扫一遍，把原话记下来。下一期的用户故事，素材就该从这里来，而不是从老板的灵机一动里来。

有人担心自己没做过大项目，这些方法用不上。恰恰相反，团队越小越靠这些基本功，因为没有专门的测试替你兜底，没有现成的流程给你撑腰。你写下的每一个字，就是团队的流程。

也别说等忙完这阵再练。基本功这个东西，忙的时候才最显灵：需求挤在一起的时候，谁的故事清楚、谁的文档能直接开工，谁的版本就能先上车。空闲时练的笔，都是忙时的命。

最后收个口。产品经理入门的头三个月，你就盯三样：用户故事写给具体的人，需求文档把现状摆到页面级，每个功能配3句话的验收标准。这三样练熟了，原型图、评审会、版本节奏都是顺手的事；这三样没练熟，学再多工具都是在给扯皮加速。

你不妨今天就拿手头那个悬着的需求试一遍：先写出那个具体的人，再摆现状，再定3句话的验收标准，最后发出去之前念给同事听一遍。文档写明白的那天起，你的团队才开始做产品，而不是做猜谜。哪一步卡住了，就回到对应的段落照着例子重写，这个循环跑顺了，入门就算完成了。

图源：《王慧文清华产品课（五）-需求篇》（第10页 · 原文）