本文作者孙遂意，迅雷高级产品经理。

产品需求都有哪些来源？

产品需求的来源

大多初学者都是从做产品需求开始的，我总结了6种需求来源，相信这些大家在各大产品经理的网站、书籍上都有看到过。

产品的需求，主要来自用户、数据、业务、竞品、PM自身或者是老板。图中圆圈的大小表示此类别需求来源的靠谱度，这是我根据自己实际工作经历感受到的，可能每个公司的产品会有不同的倾斜。

但不管什么样的产品，最重要的一定是用户。线下商品或者是服务把顾客称为上帝，线上产品也一样。用户就是上帝，用户爽了，才有活跃和留存，才有后面的商业模式。

1.请教行业的资深人士

他们对相关领域比较熟悉，研究比较透彻，能够洞悉行业的发展趋势。

2.根据数据

包括自身产品的线上数据，或者是同行业的产品数据。通过这些数据，来识别用户的需求。

3.根据业务

比如根据业务需要提出的运营推广需求，运营收入等需求。

4.根据竞品

这个就是所谓的同类产品之间互相借鉴。在基本功能上，别人有的，我也不能少。或者是通过竞品披露的一些运营数据来获悉用户的需求。

5.产品经理自己

第五个是产品经理自己，把自己当成用户，或者是观察用户，或者是根据自己的产品感觉，或者是经验，来找到用户的需求。

6.来自老板的需求

最后一个是来自老板的需求，老板的需求通常有拍脑袋的成分，大多是根据自身的经验给出来的。需求合适于否，取决于老大自身见解的高低，所以我把它排在了最后一个。

PM自己，要想获得更多的产品灵感，需要走进用户。不是有句话说，要想当好侦探，就得像罪犯一样思考。做产品也是一样的，要想了解用户，就得像用户一样使用产品。

怎么样走进用户的思维，了解用户的使用情况呢？这里我推荐使用马化腾的10/100/1000法则。据说以前腾讯要求每个产品经理每个月必须要做十次用户调查，关注一百个用户博客，收集反馈一千个用户体验。    

除了自家产品的QQ群、论坛、微信群外，也需要关注一下其他平台上用户对你产品的评价。在研究用户需求上，是没有什么捷径可以走的。用这种笨办法是最有效的——到你的用户出现过的论坛圈子中去挖掘。我们曾经根据用户的论坛反馈，进行了产品的优化，最好的记录就是将某个产品的某个功能的点击率从5%能提升到30%。

收集好需求以后，如何对优先级进行排序？

这是让很多入门者苦恼的事。

3种需求模型

1.三种需求模型

先做基本型的需求，也就是必须要有的需求。

再做希望型的需求，这个是非必须的，但能给用户提供便利的，用户希望的但是他自己又表达不清楚的。

最后一个是兴奋型的需求，要超出用户的预期，能给用户带来惊喜的。比如说微信，它的基本需求通信、通讯是期望型需求。朋友圈里面除了发图片分享之外，也能够通过长按发文字消息。兴奋型需求，比如说通过微信也能发红包。

总之就是沿着这条路线，先做安全的，再做方便的，再做提高效率的，之后再做情感的，然后再做好玩有趣的，最后就是做让用户觉得有成就感的。

2.用数据来说话

除了上面这些，还是要靠用户数据来说话。也就是说，用的人多，用的次数多的，就先做。比如说微信前期做的优化都是围绕着通信聊天和朋友圈，而那些钱包功能都是放在后面才优化的。

路径统计图

大家看到PPT这张图，这是我们一个产品的友盟用户使用路径统计图.可以很清晰的看出，用户的使用流向是否和你的产品预期的相同，是一目了然的。你需要优化哪条路径才能让用户朝着你期待的路径去走，这些就是你需要优化的点，这些地方的需求可以优先来做。

3.根据用户反馈来选择

我们在做APP的新功能的时候。因为收集的需求很多，为了保证快速的迭代，我们不可能一个版本做很多的功能，所以没有办法决定到底哪个先做，哪个先不做。然后就把它放到用户的论坛里面，让用户自己来选择，投票高的，我们就把它放在最近的版本来实现。

拿到需求以后无从下手，怎么办？

无论是刚才提到的用户数据，还是现在的用户投票，都是让用户参与这个需求的决策过程。但是拿到需求还是会出现无从下手的情况，通俗来说，就是不知道如何将需求转换成功能。那要怎么做呢？

拿到需求以后，我们是需要思考用户在什么场景，需要什么功能，走那些流程，才能完成对应的需求。也就是把用户场景和需求串起来，尽量把用户要实现的这个需求的每一个场景，每一个步骤都详细的列出来，用脑图加流程图的形式，把所有功能列出来。

但是由于对业务不够了解，就像我刚做迅雷7的时候，对它知其表而不知其里，导致不知道实现这个功能要走哪些流程。

比如说以前在做BT下载的时候，因为我是女生，不常下载，所以根本不知道BT下载是要先下一个种子，再由种子文件去下载对应的内容。对于这些影响功能流程的环节，我们还是需要自己去找相关的专家来帮你解决，没有什么更好的办法。

很多时候我们会自动跳过需求转功能流程这个环节，认为需求反正已经很清楚了，或者是有其它的竞品可借鉴的，拿到需求之后，就直接就开始画原型了。结果就是好多功能流程在进行交叉的时候，会变得非常的混乱，不知道怎么把这些流程和功能往圆心里面塞。

我推荐大家要先做加法，用思维导图和流程图，先把你能想到的所有功能和流程图全部都列出来、画出来。然后再做减法，优化掉流程中多余的或者是可以省去的环节，用最少的流程完成功能，从而确定产品最终的路径图。

原型憋不出来怎么办？

有了功能和流程图，还是不能把原型编出来的情况也大有人在。因为原型并不仅仅是我们看到的一张图，它还承载着产品的架构设计、交互设计，需要考虑用户体验，产品的扩展。你的产品是用导航布局、标签布局还是网页布局，都需要在原型制作前就考虑清楚。

TOP10应用

在这里我要跟大家分享的是，有了功能还做不出原型来的，通常是产品用的太少，见识太窄。上图显示的是APP全球IOSTOP10的应用，大家看一下，你熟悉几个。

看到图标能对应出产品名称吗？能说出这些产品大体的产品框架吗？也许这些APP你都见过，也都用过，但是你不一定了解，或者没有完全理解，或者是没有思考过这些产品的架构，没有形成自己的方法论。只是停留在见面层面这种粗浅的APP体验认识上，会让我们在产品原型设计时，尤其是借鉴他人的产品设计时，犹豫不决，徘徊不进。

比如同一个功能，因为A产品是这样做的，B产品是那样做的，那么到底模仿或者借鉴哪一个，你心里就没有底了。

怎样才能让自己熟练地在原型中将功能和流程串联好呢？最好的方法就是动手练习，比葫芦画瓢，还是笨方法。

使用频率较高的APP

大家可以看到图片上的这些产品，都是使用频率挺高的一些常用产品，试着用一遍这些产品的所有功能，因为很多边角功能，或者是一些边界功能，大家平常可能都不会用，但是你在做产品设计的时候，其实是会用到的。然后自己绘制一次原型，看看能否全部连起来，如果不行的话，就再试一次，如此反复，经过多次的练习，我相信一定能掌握好做原型的基本能力。

这里需要提醒的是，原型不是只是图，还有文字和交互逻辑。这些产品上面的每一个文案，你能一字不差的画出来吗？

什么样的PRD文档才算是合格的

产品功能和原型方案有了，就要形成需求文档，传递给项目组成员进行后续的实施。但是我们总会遇到需求文档PRD理不顺的问题，不知道怎么写才能让别人看得懂，不知道怎样才算合格的PRD。有些同学比较纠结于需求的展现形式，到底是用word，用PPT，还是PS。

展现形式是可以多样化的。怎么简单怎么容易表达就怎么来。能用一张图的需求，没必要搞一个文档。我认为word虽然是最规范的文档形式，但也是效率和效果都最低的需求文档呈现方式，因为放图、放交互都不是很方便，查阅起来也不是很方便。

所以选择自己最合适的工具做需求的产品形式即可，不用太纠结于某一种。

需求文档最注重的是表达方式。比如上图，左边是一个像流水帐一样的需求表达方式。这种方式没有人可以耐心的看下去。右边是像处女座一样有条理结构性的输出的，让内容结构化，让需要查阅的同学一眼就能够找到自己想看到的信息，便于检索。

5个方面判断需求文档是否合格

一般我们用这几种框架的方式来分解功能，把所有的功能说明全部都覆盖到，才算是完成了整个需求文档。

第一个是按照在系统中所说的位置来分解功能。比如说先说前台的页面，再说用户管理后台的页面。

第二个是按照功能的主次来分解，先说核心功能，再说次要功能。

第三个是按照页面的布局来分解，从上往下，从左到右进行描述。

第四个是按照场景来分解，比如先说初次使用的，再说非登陆用户的，或者是已登陆用户的。

第五个是按照用户操作的步骤来分解，比如下载前、下载中、下载后。

最终只要能使文档阅读者读懂，就算是合格的PRD。

需求想不全怎么办？

不是PRD一完成就万事大吉了，还是经常会出现需求想不全的情况。这个需求想不全有两重意思。第一个就是只考虑到了需求的正常流程，忽略了需求的边界和异常部分。第二个就是只考虑需求的当前版本，或者是当前设备的使用正常，却忽略了需求的上下文环境。

经常被忽略的需求边界

我们来看几组容易被忽略的边界。第一张图中的，创建下载任务的时候，出现空间不足的情况。这个我们就要事前提示用户，暂停任务的下载，保留已经下载的部分，等用户清理磁盘之后，能够继续进行下载，下面的已完成文件被移出之后，就不再提供打开按钮，而是支持重新下载。

第二张图中在没有读取到用户健身相关数据，或者是一个全新的用户没有数据的情况下，这些显示着用户步数的，健身时长的数据位置就要留有占位字符，避免有数据的时候，这些数据会突兀的出现。

归纳下来，通常需要考虑这些方面。

1.入口和流程

首先，要考虑的是入口和流程。入口就是启动应用或功能的入口，从桌面启动还是从通知栏启动？从你自身的应用上启动还是从第三方应用的入口启动？

流程就是指按某个入口执行一系列步骤，实现某个功能的分解动作，包括成功的情况以及各种失败的情况。失败情况里面就包含了各种的边界，比如你在描述一个购买失败情况的时候，失败的边界可能是余额不足，也有可能是服务器下单失败，也有可能是程序本身就不允许重复购买。

2.场景与扩展

用户实用功能的场景，比如说你是横着拿手机，还是竖着拿手机。当你横着拿手机的时候，是否需要支持横屏？如果你支持横屏的话，需要对字符串或者是对功能模块需要进行哪些调整？

用户的场景，还有一个最重要的就是网络。他当前是wifi还是数据网络？如果是wifi的话，是需要验证的wifi还是不需要验证的wifi？通常在数据网络下，进行一些流量消费行为的时候，都是需要给用户提示的，但是在用户提示的同时，你需要暂停当前的流量消耗行为。

扩展，包括版本扩展，是否兼容新旧版本。比如我们最近就出现一个问题，在服务器端下线了一个免费赠送用户流量的功能。但是我们就没有考虑到有些旧的版本，仍然有获取赠送流量的入口。结果就导致非常多用户来请求这个赠送流量却失败的情况，这就是因为我们在下线的时候，需求没有考虑全面，没有顾及到之前的旧版本，仍然存在这样的功能入口。

3.设备与平台

设备是指不同系列的设备，比如PC、Ipad、安卓、苹果、电视等，不同的设备它的设计规范也会不相同。另外就是同系列的手机和不同系列的手机，它的规范也不尽相同。要支持多种设备，就需要进行适配处理。平台通常是PC平台还是移动平台？是安卓系统还是IOS系统？  

需求不是一次性就能考虑全面的，一回生二回熟，不用要求太苛刻。那种非常边缘或者是边界的一些功能，是可以暂时忽略的。比如我们在做迅雷的移动版下载的时候，就考虑到手机上面用户的下载意识不是很强，下载文件也不是很大，所以我们就先忽略下载大于2G的文件这种边界情况。

怎么合理地与技术或者运营童鞋寻求帮助？

做产品的时候，经常会遇到一些技术类，或者自己搞不定的问题，需要请教开发，或者其他岗位的同学。

寻求他人的帮助也是一门大学问。先来看看这3个问题。

第一个，“Axure怎么用，你教教我吧”。

第二个，发现问题的时候，跟大伙儿说，“这个数据一看就不对，谁给看看，是不是代码写错了”。

第三个，“跟一个前端开发说，帮我把这个HTML文件生成一个访问链接吧”。这三个问句本身是没有问题的，我们分别来肯看，在这三个提问方式和提问对象，提问场景下，它有什么问题？

第一个问题，Axure怎么用？你教教我吧，这个问题确实很大，Axure本身是一个很容易上手的工具，怎么可能一点也不会？你让教你的人怎么教？你是一点也不会呢？还是哪里不会？

第二个本来是想让大伙儿帮忙看一下，数据为什么不对？结果问题还没问清楚，反而没经过分析就给人开发定罪了，言语上还冒犯了写代码的开发同学。

第三个生成访问链接。本来是服务器开发干的活，现在你跑去问一个前端，性格不好的，肯定不会理你。像这样的提问，寻求帮助肯定是无果而回的。

请教别人问题要先考虑如下问题。

1.问别人前先问自己

这个问题你思考过了没有？确定你不会吗？你有没有问过度娘？要问的问题说清楚了吗？对方能听懂吗？

2.说对话

要想定位问题，就要先学会分析问题，确认清楚后再下结论，不要随口说错话，说不严谨的话。尤其是给人定罪的言语要慎用，不要做这种低情商的事情。

3.找对人

平时就要对各个岗位的分工、职责、人物性格了如指掌，才能找到给你帮助的最佳人选。总之在问问题前，先己后人，先问自己再问别人，提高自己的情商，学会做事做人，懂得察言观色。

产品经理很忙，很烦躁，怎么缓解？

有没有同感，自从做了产品经理之后，工作就非常的忙，人也特别容易烦躁。因为产品经理每天都要跟各种岗位的同事打交道，难免会忙乱，忙乱中如果没有很好的做好工作事项的安排，就会出现连锁反应，甚至烦躁。

1.理性拒绝

要确保工作有序的进行，就要不慌不乱，不要被那些不重要不紧急的事情干扰，要学会理性的拒绝。

比如说有人拉你去讨论一个方案，或者是讨论一个事情的时候，你手头又在做自己的事情，这时候你可以说：好的，不过麻烦你先把你的需求，或者你的想法先发我一下，我先看看。这样先为自己争取一些时间，把手上的事情处理完，然后再安排其它的事情，尽量不累积事情。

2.美不是关键

产品经理有的时候是瞎忙活，比如希望自己的产品一出来就高大上，美呆了，然后就把时间浪费和纠结在各种产品视觉上面。按钮是往左边摆还是往右边摆？是不是要做成蓝色呢？

其实美不是关键，丑也不是问题，因为美并非是解决用户需求的关键，当产品基本需求未满足的前提下，不要把时间浪费在产品UI改的更漂亮这件事情上。当自己的审美或者是设计能力没有满足要求的时候，也不要把时间浪费在UI上，因为这不是你擅长的。先把你擅长的功能和体验做好再说。

3.尽量往前一步

还有一种让工作不处于忙乱状态的方式，就是尽量让自己往前一步走。这里说的不只是产品规划往前一步走。除了常规的产品规划走在研发前面之外，更想说的是往前一步想好各种产品工作中的意外情况。

比如我们在做版本迭代的时候，往前想一想，如果用户不喜欢这个功能怎么办？能不能换掉？能不能下线？如果是由于法务问题，或者是功能出现故障，需要下线的功能的时候，能不能做到？

做合作需求的时候，往前想一想，如果对方不喜欢你的方案，你有没有替代方案，或者是你能不能修改你的方案？有没有更好的对策来说服别人适应你的方案。

4.积极乐观

看到产品要处理这么多的事情，确实是很烦躁。随时还有可能会被开发鄙视，被同行笑话，被用户蹂躏，被领导批评。但是我们还是要保持积极乐观的精神，扛着压力，带着小米的那句话，永远相信美好的事情即将发生！因为如果情绪管理不好，是最容易出现烦躁的，还是希望自己在一个快乐的环境中进行产品工作。

5.多多关注八卦啦

这里分享一个经验，当你很忙很烦躁的时候，来关注一下当下的时事和热点。

一方面来疏散一下心情，另外也增长一下课外知识，让你更充实，没空烦躁。最后还因为如果你几天不关注外面的八卦、新闻、时事，你就要跟互联网脱节了。到时候你会更烦躁。更何况这些热点的背后，都有我们可以学习和思考的东西，可以应用到产品领域的东西，记住这个八卦缓解法。