作为产品小卒，我虽然不敢班门弄斧，但是在这里也跟大家分享一下我五年产品工作经历中踩过的一些坑，希望能为大家提供一些共鸣或者帮助。
第一个上面写的是混迹与酒桌，我，我不是酒鬼。还记得大家那个平常工作中的时候吧，每次碰杯的时候，大家常常会说这么一句话，来来来来，干杯随意随意啊。
因为我的名字有随意两个字，所以伙伴们就理所当然的帮我翻译成了酒桌上的这个随意，然后就开始流传的这个称号了。我不是纯种的产品经理，是半路出家的，从产品从测试转的产品，相信很多朋友也是跟我一样的。在迅雷期间呢，我负责过这些产品，大多数男同胞使用的下片神器迅雷七，聚合全网影视、小说、游戏资源的网站和客户端迅雷大全，嗯到现在的安卓合作产品。经历了客户端、网站、移动端三界产品。
也负责过跟小米，腾讯，360 OPPO，优酷等互联网厂商的一些合作项目，如果大家的公司跟迅雷有合作意向的话，迅雷的移动开放平台欢迎你。
接下来我们将开始课程的主要内容，从产品需求是怎么来的开始。因为大多数初学者都是从做产品需求开始的，PPT上展示了五种需求来源，相信这些大家在各大产品经理的网站和书籍上都有看到。
产品的需求主要来源于用户、数据、业务、竞品、PM自己或老板。在PPT中，圆圈的大小表示此类别需求来源的靠谱度，是根据自己实际工作经历感受到的，可能每个公司的产品会有不同的倾斜。
产品的需求来源主要包括用户、数据、业务、竞品、PM自己或老板。用户需求是产品的基础，线下商品或服务要尊顾客为上帝，线上产品也不例外，用户就是上帝，让用户满意才会有活跃和留存，才有后面的商业模式。获取用户需求的方法通常包括请教行业资深专家、做定性的用户访谈和定量的调查问卷等。
第二个来源是数据，包括自身产品的线上数据或同行业的产品数据，通过这些数据来识别用户需求。迭代产品需要依据线上的数据来进行规划。第三个来源是业务，根据业务需要提出的运营推广需求和运营收入需求等。
第四个来源是竞品，所谓同类产品之间互相借鉴，在基本功能上，别人有的我也不能少。或者通过竞品披露的一些运营数据来了解用户需求。
第五个来源是产品经理自己，把自己当成用户或观察用户，或根据自己的产品感觉或经验来找到用户需求，最后一个是来自老板的需求，通常老板的需求可能有拍脑袋的成分，大多根据自身的经验给出来的需求，合适与否取决于老大自身见解的高低。
产品经理要想获得更多的产品灵感，需要走进用户，了解用户的使用情况和需求。使用小马哥的十一百一千法则可以帮助产品经理了解用户，这个方法据说腾讯要求每个产品经理每个月必须做十个用户调查，关注100个用户博客，收集反馈1000个用户体验。如果找不到那么多博客，可以去问度娘。除了自家的产品QQ群、论坛、微信圈，也可以关注竞争对手的产品。
“挖掘用户论坛,优化产品需求”
产品经理在研究用户需求时，也需要关注其他平台上用户对你的产品评价。最有效的方法就是去挖掘用户在你的产品上留下的论坛圈子。我们曾经根据用户的论坛反馈对产品进行了优化，最好的记录是将某个产品的某个功能的点击率从5%提高到了30%。收集好需求后，首先要做的就是基础基本型的需求，这是用户必须要有的。然后再做期望型的需求，这是用户希望得到但自己又表达不清楚的便利和高效。最后一个就是兴奋型的需求，就是要超。
突出用户的预期，能给用户带来惊喜的，比如微信，其基本需求是通信和通讯，期望型需求是除了发图片分享外，还能在朋友圈通过长按发文字消息。兴奋型需求包括微信红包、发送语音或视频等，要沿着这条线，先做安全的，再做方便的，再提高效率，然后是情感的，最后是做有趣的。
大家都看到这张图，这是我们一个产品的友盟用户使用路径统计图，可以很清晰地看出用户的使用流向是否和产品预期的相同，这是非常明显的。我们需要优化哪条路径才能让用户朝着我们预期的路径去走，这些就是我们需要优化的点，这些地方的需求可以优先来做。
再来看这个图，这是我们在做APP的新功能时收集的需求，因为收集的需求很多，为了保证快速迭代，我们不可能在一个版本中做很多的功能，所以无法决定到底哪个先做，哪个后做。于是，我们将这些需求放在用户的论坛中，让用户自己来选择，得票最高的需求我们就把它放到最近的版本中实现。无论是收集用户数据还是现在用户投票，其实都是让用户参与这个需求的决策过程。
“明确需求，串联用户场景，详列实现步骤”
但是，在拿到需求后，还是会出现无从下手的情况，这实际就是不知道如何将需求转换成体现到产品方案中的功能体现。尤其是核心功能，它是核心需求的体现。拿到需求后，我们主要需要思考用户在什么场景需要。
为了完成对应的需求，我们需要明确功能走哪些流程才能完成。这就需要将用户场景和需求串联起来，并详细列出用户要实现需求的每一个场景和步骤。我们可以采用脑图和流程图的形式来呈现这些信息。
对于某些功能，虽然已经列出来了，但由于对业务或技术的不够了解，例如迅雷期一样，许多人可能只知道其表面，而不知道实现这个功能需要走哪些流程。在这种情况下，我们需要了解更多关于业务的了解，以确保能够正确地实现这些功能。
“了解BT下载流程，优化产品功能与流程”
对于那些不常下载的人来说，可能不知道在BT下载时需要先下载一个torrent种子，再用种子文件去下载对应的内容。
有时候，我们会因为自动跳过需求转功能流程的环节，而忽略了影响功能流程的细节问题。这可能导致功能流程在交叉时变得混乱，难以将这些流程和功能整合成一个完整的圆形。
因此，我们建议在拿到需求后，先做加法。使用思维导图和流程图列出所有功能和流程，然后进行减法，去除多余或可以省去的环节，用最少的流程完成功能，从而确定产品最终的路径图。
当然，有了功能和流程图，我们仍需要进一步优化。
许多人都会在憋出原型后才发现，原型不仅仅是一张图，它还承载着产品的架构设计和交互设计，需要考虑用户体验和扩展性。因此，在制作原型前，需要明确选择哪种布局，如导航布局、标签布局还是网页布局。网上有许多这方面的教程可以学习。
在这里，我想和大家分享的是，有时候即使有了功能，但产品没有原形，通常是因为产品使用得不够多，见识不够广。
在下图上，展示了全球iOS Top10的应用，大家熟悉的应用都有哪些呢？能对应出产品名称吗？能说出这些产品的大致产品框架吗？
也许你熟悉这些APP，也使用过它们，但你可能不了解或没有完全理解它们的架构，也没有形成自己的方法论，只是停留在界面层面，缺乏深层次的思考。
在产品原型设计时，我们可能会犹豫不决，徘徊不尽，因为同一个功能，不同产品的实现方式可能有很大差异。这会导致我们在借鉴他人产品设计时，不知道该模仿还是借鉴哪个版本。
为了解决这个问题，最好的方法就是亲自实践。我们可以尝试使用这些高频产品的所有功能，并尝试自己绘制原形，看看是否能将所有功能串联起来。如果不能，我们可以反复练习，直到熟练掌握为止。
在绘制原型时，我们需要注意文字和交互逻辑。这不仅仅是简单的图形，还需要考虑到产品的实际需求和用户体验。
当原型设计完成并确定后，我们需要形成需求文档，并将其传递给项目组成员进行后续实施。然而，我们可能会遇到需求文档PRD不顺利，不知道如何写才能让别人看得懂，不知道怎样才算合格的PRD。因此，我们需要注意需求的展现形式，并在实践中不断提高自己的能力。
掌握需求文档展现形式，提高表达能力
当然，展现形式可以多样化。我们可以根据需要使用Word、PPT、Sketch或其他工具。对于简单的需求，一个图表或一个页面就能清晰地表达实际需求，但如果需要配合其他工具一起使用，PPT是一个很好的选择。总的来说，能用简单的方式表达需求，就不必使用复杂的文档形式。
实际上，不同的工具对于需求文档的呈现效果都有所不同。Sketch做出的原型确实精致，但可能不够高效，而且大文件容易卡顿。因此，选择自己最合适的工具来呈现需求是至关重要的。
需求文档的重点在于表达方式，不一定需要过于关注某一种特定的需求文档形式。有时候，一个像流水账一样的需求表达方式可能更易于理解，而有时候，一个像处女座一样有条理结构性的输出则更能让需要查阅的同学快速找到自己需要的信息，便于检索。一般来说，我们可以使用这几种框架来分解功能，这些框架都是结构性的。
编写需求文档:功能说明覆盖完整结构
搭建需求文档后，需将所有功能说明覆盖完整。常用的结构包括：
-
按照系统中所处的位置来分解功能，如前台页面与用户管理后台的页面；
-
按照功能的主次来分解，先说核心功能，再说次要功能；
-
按照页面的布局来分解，从上往下，从左到右逐个描述；
-
按照场景来分解，如初次使用、后续使用等不同场景。
接下来，我们可以根据用户的不同情况进行功能分解，包括非登录用户和已登录用户。还可以按照用户操作的步骤进行分解，如下载、下载前、下载中、下载后。只要文档阅读者能够理解，就算合格了。不过，需求分解有时可能不够全面，还需要在后续的需求调研和分析中加以完善。
考虑上下文环境与健身时长数据
在需求文档中，我们还需要考虑需求的上下文环境。有时候，应用是在与旧的或不同的设备同时安装时使用的。我们需要关注这些边界情况，以确保用户能够正确地使用应用。
例如，在第一张图中，当用户创建下载任务时，如果出现空间不足的情况，我们应该在任务下载前提前提示用户暂停下载并保留已下载的部分。当用户清理磁盘后，应继续下载并支持用户重新下载已完成的部分。
在第二张图中，如果没有用户健身相关数据或新用户没有相关数据，应用应该显示用户的步数。这些数据可以帮助用户了解自己的运动情况，并激励他们继续坚持锻炼。
总之，在需求文档中，我们需要考虑各种可能的情况，并确保应用能够正常地运行。这样，我们才能为用户提供优质的服务。
在健身时长数据的位置上，我们需要留有占位字符，以避免数据突兀地出现。在第三张图中，我们需要考虑应用的UI，以及不同系统、语言环境下的显示是否正常。
针对不同设备和平台的规范需要进行适配处理。
首先，我们需要确定应用的入口和流程。这包括桌面启动、从通知栏启动，以及被第三方应用拉起来。确定好入口后，我们就可以开始执行便利入口的每个流程，实现功能的分解动作。
在第一块中，我们需要考虑场景和扩展。这包括用户使用功能的场景，例如横着拿手机或竖着拿手机时是否需要支持横屏，
以及是否需要对字符串或功能模块进行调整。
此外，当用户暂时退出时，我们需要持久化当前的内容，以便用户在再次登录时能够继续使用。例如，小米的一个应用，就是那个检测真机的应用，它要求电量达到10%或20%时才能够使用。
在第二块中，我们需要考虑网络。用户当前所处的网络环境，例如WiFi还是数据网络，以及流量消耗行为。我们需要在用户提示的同时暂停当前的流量消耗行为。
在第三块中，我们需要考虑设备与平台设备。不同系列的设备，例如pcpad、Android、苹果盒子、路由电视等，需要进行相应的配置和控制。
综上所述，我们需要考虑多个方面来确保应用的正常运行和用户体验。只有在这些方面都得到充分的考虑和准备，我们才能为用户提供优质的服务。
针对不同设备的设计规范和同系列不同设备的规范，我们需要进行适配处理。要支持多种设备，就需要考虑平台的特性，如PC平台、移动平台、安卓系统、iOS系统、英文系统还是中文系统。
全面功能实现需关注实现环节、平台特性及客户端/服务功能
在实现全面的功能时，我们需要清楚各个功能大致的实现环节，了解每个平台的特性。例如，安卓系统需要考虑物理键，如网站的运营功能需要后台服务，PC上的应用图标需要准备状态栏图标、桌面图标、加速启动栏图标等等。同时，我们还需要了解客户端和服务的功能，如迅雷的移动版下载功能。
在每次需求完成前，我们需要检查上述三个板块是否都得到了考虑。需求不是一次性就能考虑全面的，一回生二回熟，我们不需要过于苛刻，对于非常边缘或边界的功能，可以暂时忽略，例如我们在做迅雷移动版下载时。
在考虑手机下载用户的使用习惯时，我们发现下载文件量相对较小，因此可以忽略下载大于2GB的文件这种边界情况。
“沟通协作的重要性：及时发现问题与解决问题”
在产品开发过程中，我们可能会遇到一些技术问题或难以解决的问题。这时，向他人请教是一种明智的选择。如果你有向他人请教过，可以分享请教资深产品经理的经验，这门学问很有价值。
另外，在发现问题的时候，我们应该及时与团队成员分享，比如：“嘿，你看这个数据一看就不对，谁给看看是不是代码写错了？”通过及时沟通和交流，有助于团队协作和解决问题。
在与前端开发沟通时，我们遇到了一些问题。第一个问题是关于X的使用方法，第二个问题是关于数据问题的沟通，而第三个问题是关于生成访问链接的请求。
在第一个问题中，我们的提问方式有些问题。我们应该先询问自己是否有相关知识，确保自己不会犯错。同时，我们也应该把问题说得更清楚，让对方更容易理解。
在第二个问题中，我们的提问方式有些冒犯。我们应该先了解问题的根源，而不是直接指责开发同学。这样才能更好地解决问题。
在第三个问题中，我们的提问方式有些不合适。我们应该先了解服务器端的情况，而不是前端开发人员。这样才能更好地解决问题。
学会沟通和有效工作:PRD撰写指南
在与别人沟通时，我们应该学会先问自己问题，确保自己不会犯错。同时，我们也应该把问题说得更清楚，让对方更容易理解。这样才能更好地解决问题。
第二个问题是关于有效沟通的问题。要定位问题，我们需要先学会分析问题，确保我们得出的结论是准确的。同时，我们在沟通中要避免使用过于严谨或不严谨的措辞，尤其是不要轻易给人定罪。我们需要学会更好地理解人性，提高自己的情商，懂得察言观色。有没有同感？自从做了产品经理，我们的工作变得异常忙碌。在日常生活中，我们也容易烦躁，因为我们需要与各种岗位的同事打交道。在这种情况下，如果没有很好地安排工作事项，就会产生连锁反应，导致烦躁情绪的出现。
要确保工作有序进行，就需要保持冷静，不受那些不重要且不紧急的事情干扰。学会理性地拒绝他人。比如说，当别人在讨论一个方案或者事情时，你手头正在进行自己的工作，你可以礼貌地回答说：“好的，不过麻烦你先把你的需求或者想法先发给我一下，我先看看。”这样可以为自己争取一些时间，把手上的事情处理完，然后再安排其他的事情，尽量不累积事情。
作为产品经理，有时候会因为希望自己的产品一出来就高大上美呆了，而浪费大量时间和精力在各种产品视觉方面，比如按钮是往左边摆还是往右边摆，或者加阴影还是不加阴影等等。然而，美并不是关键，丑也不是问题。关键的是满足用户需求。当产品基本需求满足后，不要把时间浪费在产品UI改得更漂亮这件事情上。当自己的审美或者设计能力没有达到一定水平时，也不要勉强自己。
当工作达到要求时，我们不应该把时间浪费在UI上。这并不是我们擅长的，而是我们应该优先把擅长的功能和体验做好。另外，让工作不处于忙乱状态的方法是尽量让自己往前一步走。这不仅包括产品规划往前一步走，还包括往前一步想好各种产品工作中的意外情况。
比如说，在做版本迭代的时候，我们应该往前想一下，如果用户不喜欢某个功能，我们能否换掉或者下线它？如果是由于法务问题或者是功能出现故障需要下线某个功能时，我们能否做到在合作需求的时候进行处理？
另外，我们也应该往前想一下，如果对方不喜欢我们的方案，我们是否有替代方案或者修改方案？同时，我们需要思考如何说服别人适应我们的方案。当我们看到产品需要处理这么多的事情时，确实会感到烦躁。
此外，我们还需要时刻保持积极乐观的精神，即使面对开发同事的鄙视、同行的笑话或者领导的批评。带着米歪的那句话，我们永远相信美好的事情即将发生。如果情绪管理不好，那么最容易出现烦躁，所以我们希望自己能够在快乐的环境中进行产品工作。
在繁忙和烦躁的时候，关注当下的时事和热点可以帮助我们放松心情，增加知识储备，让我们更加充实。如果我们几天不关注外面的八卦、新闻和时事，我们可能会感到更加烦躁。
我们回顾一下产品需求推荐的小马哥法则。其核心思想是将用户需求拆分为十一百上千个小需求，再通过优先级和重要性进行排序，确保推荐的热点都有实际应用场景。其次，我们需要了解哪些需求应该优先处理。在用户参与决策的过程中，确保用户可以真正参与到产品需求的决定中。接着，一旦我们拿到需求，应该从哪里入手呢？首先，我们要做的是加法，即明确需求的本质和核心，然后才能进行减法，即去掉无关紧要的细节。在理清功能和流程之后，如果遇到无法实现的圆形需求，我们可以在平时多练习，提升自己的画瓢能力。最后，什么样的PRD才算合格呢？我们需要根据具体项目来评估，但通常来说，文档阅读者需要具备良好的文档理解和阅读能力。
能理解这些内容的，就是合格的TRD。如果第六个需求想不全，不要苛刻，要一回生二回熟。下面是寻求帮助，怎么样让自己更好地得到帮助呢？先问自己，再问别人。最重要的是要提高自己的情商，不要去问一些无关紧要的问题。最后，我们要学会缓解忙碌和烦躁的情绪，比如使用八卦缓解法。希望这些内容能对大家有所帮助。
最后，预祝大家在这条产品经营的道路上越走越远，保持学习的热情。谢谢大家。
