从大学毕业到现在一年有余，从事产品的岗位也是一年有余。为了让自己更胜任产品的岗位，让自己成为一名能够独当一面的产品经理，这一年以来不断地去学习产品知识。但在这个过程中，各处得来的知识零零碎碎，太多人的想法充斥在各个角落，欣喜地探宝之后，留下的是身前宝物堆积的垃圾山。
而我，仍旧不断迷茫，直到拨开迷雾，回首之前的迷茫，尽是唏嘘。为此，我将所学、所思、所想整理成一个结构化的知识体系，帮助那些不了解、不清晰的人一窥产品世界的轮廓。
同时，写这篇文章的过程也是我这一年多来所学知识的沉淀、自我的认可、体系的建立。我自身还有太多不足，有些思想可能还很幼稚，但如果这篇文章能帮助到你，确实是一件值得欣喜的事情。
本文分享的是以商业为目的的互联网产品经理的工作内容。
本篇文章会从根源上一步步展开每个模块之间的关系，即为什么要做这个，由于篇幅所限，有的内容不会详述具体做法只会大致描述每个模块的内容。
首先，我们需要知道什么是产品经理。
有很多前辈从不同方向对产品经理进行了解读，我从他们的解读中也有所体悟，在此妄言一二，望各位海涵。产品经理，在我的理解中，他通过一个一个功能，在解决用户需求的同时，进行赋能。产品经理就是通过在产品中赋能，来提升产品的价值，实现盈利。
先上图：
一个公司的产品，首要目的是解决用户的需求，然后以这个目的为出发点，通过一系列手段将这个产品产生的价值转化为利润来实现盈利。
上面这段话转化为实际工作可以大致认为：由产品开发等组成的团队开发出来能满足用户需求的产品，然后由运营人员为主、产品开发等为辅的团队运作这个产品，在不断增加产品内在价值的同时将价值转化为现实的利润。在公司中，所有的工作围绕的核心即是盈利。
因此为了让公司实现盈利，一切的根源——即满足用户需求的产品——要能便于运作来得到利润，为此这个产品在设计之初，一定要考虑好它怎么创造利润，即盈利模式。考虑它的盈利模式，才能让后面的运作手段有处下手。
上面所讲的盈利是整条线的最后一步，考虑产品是第一步，为了能让产品一步一步走向盈利，你要进行的第一件事就是产品规划。
产品规划（核心）
产品规划的实质是动态调控产品，分解当前和未来一段时间内产品所面临的问题，然后通过各种方式去解决问题，最终得到想要的结果。
产品不同，盈利模式会有所区别，所以产品规划一定有所不同。做产品规划的时候首先要考虑盈利模式，即假设产品达到一个你认为的状态后，通过哪些方式来得到利润。
互联网常见的盈利模式如下图：
考虑清楚盈利模式，进而就能考虑清楚产品未来大体会是什么样子。为了让产品达到这个样子，进而实现它的盈利模式，你在考虑这一切时一定会发现其中有很多障碍。按照先后顺序，闯过这些障碍，你就能通关达成目的。
为了“闯关”，你会对每一个“关卡”进行研究，将这些“关卡”分解为几个较为具体的目标，然后按SMART原则，将这些较为具体的目标分解为一个个具体的可执行的工作内容。这就是产品规划。大家每天就是通过执行这些具体工作内容来解决一个个较为具体的目标，实现“破关”然后走向盈利。那些具体工作内容则在后面阐述。
确定产品的盈利模式，只是产品规划的一部分内容。为了做好产品的规划，需要根据产品、环境、商业等因素，来确定规划方向。通常，我们可以用产品生命周期来反映产品在不同时间的状况。就像人一样，产品的发展会经历新生（启动）、成长、成熟、衰老的过程，不同时期，产品主要发力点是不同的。比如启动期尽量不考虑盈利，为的是快速成长，通过拉新等手段获得更多的用户；成长阶段开始一步一步考虑盈利模式，进行一些探索和试验，同时继续拉新；成熟期完善盈利模式，并进行保持，即保持日活和保持留存。……产品生命周期可以为我们的规划提供产品方面的依据。下图是我从百度图库找的一张图，可以很好的反映一个产品在每个阶段的状态。
在你进行规划的道路上，会有各种或大或小的障碍，比如产品盈利能力的问题、投资人的要求、产品优化、用户需求等等，但最终的产品规划会落脚在诸如：拉新、留存、转化、日活、用户粘性等方面。
为什么这么说呢？可以简单的认为，我们是做出来满足用户需求的产品，然后想办法让越来越多的人使用，进而努力通过这个产品去获得盈利。从中我们可以看出，产品、制作、运营、反馈、优化、转化等等工作，是可以通过拉新、留存、转化等作为指标，最终解决一个一个问题。而为了达成一定的留存率等指标，需要进行一系列手段，通过这些手段增加用户粘性、提高日活。所以这些手段一般都会在产品中进行体现，而在产品中体现，也就意味着，需求来了！
最开始的时候说到，产品的首要目的是解决用户的需求，也说过公司的目的是盈利。但是不管是满足用户需求还是满足公司的盈利目的，所有的一切归根结底都要在产品中体现。
产品规划的每一步都要去权衡用户和公司的利益（毕竟，公司和用户是两个主体，两个目的，所以两者意见一定会产生分歧），最终实现盈利。权衡的过程就是在分析用户和公司的需求，从中找到最佳的结合点，产出功能。这里就引出了我们产品最常做的工作——需求分析。而这两类需求就是需求分析中最主要的两类需求，即用户需求和业务需求。
这两类需求，用户需求，解决了用户遇到的问题并且让用户用的舒服，这类需求解决的是用户留存率、流失率、用户活性等指标；第二类是业务需求，这类需求站在公司的立场，可能提升用户的体验，也可能会降低用户体验，也有可能是增加新的产品线，主要是解决了公司规划路上的一个个目标与障碍。
上面这两类需求是站在不同立场的双方对产品的需要。他们有时候会一致（产品前中期公司目标就是提高用户体验，让用户用的舒服），有时候会分歧（为了实现盈利，我们在播放视频前加上广告吧！）。需求分析就是要从这两者中进行权衡，根据产品的规划、产品生命周期等去寻找怎样才最适合双方的产品。
怎么进行产品规划？
产品规划门槛较高，需要对行业、产品有足够的认识。由于个人能力所限，并没有具体掌握产品规划的方法，所以在此不详细描述怎么规划，而是分享几点经验认知。
商业模式尽量越简洁越好。一两步能实现的转化尽量不要三四步，因为每多一步，就多一个不确定性，现实实现起来会遇到越多的困难。
进行规划时切忌思考具体实现，因为你会纠结在几个点中，从而浪费时间。现在就是需要做白日梦的时候，当然，要在自己认知的范围内做白日梦！
幻想不可怕、就怕不验证；验证发现你错了不可怕，要是你随便想一个都能实现，那别人都要失业了。
觉得可以的时候，就做一做产品规划，不一定真能发现更好的模式，可以多去锻炼自己，让自己积累力量；更多的是你能从规划中更明白公司现在在做什么，每个人手中正在做什么。
规划有长远规划和短期规划，短期的规划是将长期规划中的问题进行分解并找出解决方案的行为。长期规划是老板最关心的，短期规划才是你最应该时长锻炼的，这体现的是你解决问题的能力。
需求收集
在需求分析前需要插入一个工作环节——需求收集。进行需求分析首先要有需求来进行分析，获得需求的过程叫做需求收集。
我们做的产品，是要以解决用户的需求为基础的，若我们不深入用户，不了解用户，不听取用户的心声，不明白用户真正需要什么，而只是闭门造车，苦下功夫，结局只可能适得其反。
需求收集就是让我们听取用户和公司的心声，明白他们需要什么，想要什么，怎样让他们过得更好。同时，通过不断地收集这些信息，可以让我们的决策更加精准，也可修正我们的规划。
上面说到需求大体上有两类，用户需求和业务需求。业务需求通常是规划时确定好的内容，有时也是上级直接指派给你的要求，因此这类需求，要直接通过公司内部进行收集，收集上司的要求、收集运营和技术等队友对产品的看法和实现难度……这里着重分享用户需求的收集方式：
1.最常用的方式之一是用户反馈
一般，都会由运营兄弟通过各种方式维护与用户之间的关系，然后收集到用户在各种情况下提的建议与反馈。收集渠道通常有如下几种
产品自有反馈体系
微博
微信公众号
运营微信群
运营QQ群
贴吧
知乎等
客服、运营、销售
应用市场评价，如app store
上面大多需要与客户维系好关系，按照重度用户、轻度用户、游客等方式对提出的建议分类。有时候身为产品有时候要化身为心机boy，通过贴吧和知乎这样的地方，想办法勾引更多的人参与话题，获得比较高水平的评价。
2.竞品分析
想要更快的明白这个行业是什么情况，多看看竞品；想要增加一些新的灵感，多看看竞品；想要让产品不至于偏离主线，多看看竞品；不想掉队，看竞品；想要发展，看竞品。虽然说了这么多看竞品，但记住，过犹不及，你毕竟不是别人，你的产品毕竟不是别人的产品，主流也并不一定会成为下一个独角兽。竞品，只是参考。
3.头脑风暴
这是非常简单却也是非常难的方式，很多人都会用，但用好，绝不是那么容易的。以拍脑门奠定基调的头脑风暴，最终必将拍碎了脑门。
头脑风暴是几个人坐一起自由联想思考事情，看似简单而没有成本，但是需要一定的操作才能做好。
头脑风暴人数不能太多，越多的人会导致难以思维过于散乱，并且影响到每个人的表达，难以组织。人数大致在6、7人以内为宜。
头脑风暴需要组织。没有组织，会导致思维过于散乱，而难以解决问题。头脑风暴，终究是为了寻找解决问题的办法。首先，收束方向，有方向的使劲，就像脑图一样，一层一层的寻找；同时，每一个点时间都不宜过长，否则你会浪费大量时间，每一点以3到5分钟为宜，当然还是要视情况而定。
提示几句，不要对脑暴抱有太大期望；也不要抱有多给点时间万一能脑暴出来一个点子呢？脑暴时间不一定能产出好的点子，但有时脑暴会给人带来一些触动的灵感，有了脑暴的这么多想法，很有可能在日常生活和工作中就能有新点子产生。
4.数据分析
通过内在的产品产生的用户行为数据以及外在的各种行业行为数据，通过一定的手段将其提炼出来，来优化产品。现在社会通常是用数据说话。数据分析就是一门比较难掌握的学问。
5.定性定量分析
定量：调查问卷
定性：用户访谈、用户观察、竞品对比、圆桌会议
6.别忘了身边同事，以及老板
需求分析
需求收集到了，我们可以开始分析需求了。我们通过分析这些需求，来确定一个需求做不做，做多少，跟其他需求怎么结合，从而权衡用户需求和业务需求。
需求分析这个过程，就是多去思考，分析这个需求到底解决了什么人在什么情况下的什么问题、我们应不应该做能不能做这个需求、为什么应该做这个需求、不做有什么影响、有什么好处与坏处？
需求是产品工作中，最常接触的最核心的一部分。我们日常工作，就是在处理一个一个的需求，进行思考、设计、开发、验证。需求源源不断，有真需求、有伪需求，有共性的需求、有个性的需求，有用户需求、老板需求……需求多、工作多，因此会慢慢的迷失在需求中，无法自拔，这个产品也就迷失在了你的迷失中……（是不是吹的有点过了？汗！）
当然，这有解决办法，办法就在上面提到的规划中。我们实际上是通过解决一个个需求来达到规划中的各个指标，进而推动产品达成最初规划的这些目的。这就是不忘初心，砥砺前行！咳！
为什么进行需求分析？
通过需求收集，我们会收集到很多的需求，但是这些需求并不能直接使用。需求有真有假，需求也分三六九等，有些需求可能我们做不到……。出于这些原因，我们必须要进行分析，分析需求产生的根源；分析具体用户、场景；分析需求真伪；分析可行性；分析产品需求和公司需求……
在这个阶段，谋定而后动。否则，会出现开发出来的东西用户不买账，所有人都会对你有意见，需求改来改去，产品失去威信，一切无法再发展。
怎么进行需求分析？
1.方向
我们做任何事情都不是无意义无目标的，不要迷失在为了需求而分析需求，为了好看的指标数据而进行分析需求，我们要以产品规划为指导方向进行需求分析。
2.确定具体用户
举个例子。
刚开始找工作那会，我加了很多产品经理的群，想看看产品经理到底是什么样子，每天都干什么。期间有个人问了个问题，说要做一个app，帮助盲人找工作。
我们刚开始讨论的侧重点是什么呢？有语音、甚至语音识别、屏幕按键要大，甚至就两个、要有震动。当时可是唾沫纷飞，狂灌白开水。中间补水的时候，突然感觉，我们都错了。我告诉对方，上面说的这些东西你全都不用做（可以想象这些人当时的精彩表情，浪费了这么多时间，一句话否认了。），正常人怎么使用这个软件，你就怎么做。为什么？在中国，残疾人大多是有监护人的，有照顾你生活的人。找工作这么大的事情，怎么可能不经过这些人呢？产品是解决盲人的找工作问题，但用户却是正常人。
从这个例子中，我们发现，搞不清楚真正的用户，你可能会面临失败的结局。只有明白到底谁会使用这款产品，你才能做出对的事情。
3.需求分析首先要进行用户分析
我们做出来的产品、做出来的所有功能都是让用户用的。不了解用户怎么可能设计出来合适的产品？了解用户才能知道，我们做的需求对用户是好是坏、有什么影响，进而确定是否开发或者改变方式或者进行优化。这就需要我们进行用户分析，建立用户画像。
用户画像实际上是通过几个字抽象的表示一个人，即打标签。使用多个标签来表示一个人，则这个“人”会鲜活的存在眼前，让别人很快的就能理解“这类人”，并且方便让机器识别。比如：女、90后、独生子女、爱摇滚、爱关注时尚信息、爱打扮、抽烟。这就是标签，通过标签你可能会认为她叛逆、可能爱表现自己……这些元素会对我们产品的优化、功能设计有很大的帮助。
虽然用户画像是抽象的人，但一定要贴近现实，越现实，你可能离成功就越近。因为这样你才知道用户真正要的是什么，不要的又是什么。
4.用户场景分析
一句话：什么人，在什么时间什么地点，做了什么事，产生了什么结果。
5.确定需求的真实根源
需求有真伪
举个常用的例子。
“我想学习”这就是伪需求，他们真的是想学习么？嘿嘿嘿！分析用户理解用户，明白他们真正想要的是什么，千万不要被伪需求坑到，否则血本无归。
伪需求的产生多种多样，有时候如图是不好意思、有的故意骗你。用户并不专业，并且每个人都会站在一定的立场上说话。多多留心，多体会用户心思。
伪需求也是需求，千万不要一刀切而不考虑伪需求。伪需求的背后，一定有一个需求进行支撑，就像上图一样，他们其实就是想找一个能够过二人世界的温馨港湾而已。
区分需求和解决方案
还是举个例子。
100多年前，福特公司的创始人亨利·福特先生到处跑去问客户：“您需要一个什么样的更好的交通工具？”几乎所有人的答案都是：“我要一匹更快的马”。很多人听到这个答案，于是立马跑到马场去选马配种，以满足客户的需求。但是福特先生却没有立马往马场跑，而是接着往下问。
福特：“你为什么需要一匹更快的马？”
客户：“因为可以跑得更快！”
福特：“你为什么需要跑得更快？”
客户：“因为这样我就可以更早的到达目的地。”
福特：“所以，你要一匹更快的马的真正用意是？”
客户：“用更短的时间、更快地到达目的地！”
然后，福特就发明了汽车。
解决这种需求，多问为什么，打破砂锅问到底，明白用户真正的心思是什么，真正需要的是什么。
6.确定是业务需求还是用户需求
上面提到了需求大体是用户需求和业务需求，一种是站在用户的立场上，一种是站在公司的立场上。用户需求是为了用户，这个不用说；业务需求有时会对用户有好的影响，有时会对用户有坏的影响。
比如公司为了达成投资要求的注册量和日活量，在产品功能以及优化上无法再突破时，会进行一系列运营手段，比如添加分享得红包、邀请新用户送iphone x等活动，这样的需求在一定意义上产生正面的影响，增加惊喜，对用户来讲是好事。这样的活动，设计好后，需要开发对应的页面、页面流转、数据统计等等，这就是比较正面的业务需求。
当用户到一定量的时候，公司要考虑盈利了。比如微信朋友圈有时就会在第四第五的位置放置广告。比如看个视频，开始广告时间特别长，中间竟然也要插进来一些广告。这些影响用户体验的例子实际上是业务需求造成的。公司知道这些玩意会造成影响，甚至导致用户不使用产品的情况，但是公司是需要达成自己的规划的。为此，我们要衡量双方，进行折中、或者进行权衡，舍弃一部分用户体验，达成业务要求，只要它在可接受的范围内……
7.若是用户需求，到底这个需求的重要性有多少？这部分内容放在后面“优先级的确定”板块讲述。
8.确定是共性需求还是个性需求、高频低频
有时候，有些真需求我们也不能做。一个产品，基本上能满足很多人的需求，但是每个人肯定会觉得，要是有这个功能就好了，但这个功能，可能只有他一个人会用，别人都不会用。除非这个人非要这个，并且给你发工资，否则，这是功能是不值得开发的。还有的需求可能很多人都会用，但是可能一辈子就用一次，频率太低，如果必要，可以放的深一点，不要占用常用位置。
9.分析能否实现。
所有的都分析完了，这一条你可千万别忘了。产品经理一定要是一个浪漫主义的诗人，但千万不要浪过了。我们也要考虑开发，到底能不能实现。你要一个瞬间转移，你信不信老板抽你都是小的？你也要考虑自己的团队能否开发出来，这个不解释。在这个地方，就需要产品经理多少懂一些技术原理，不用知道怎么写代码，我们至少要知道什么能做出来，什么不能做出来。
这里还要提一下中庸之道，不要走极端。有些需求，改变一下方式，也许能产生新的灵感，或许能出乎意料的好。打个比方，古时候信鸽飞的慢，要是能瞬间转移就好了，然后我们发明电磁波，咻咻咻~，信息就瞬间到了另一个地方。话糙理不糙，明白就好。
10.通过产品定位确定产品边界
并不是所有的需求都是能说得清楚到底对我们是好是坏，所以你会不停的添加功能，最终有可能四不像，还让所有人累的像条狗。这个时候可以尝试使用产品边界。通过产品定位从行业领域（细分）、公司所在上下游位置、平台还是工具等方面确定产品边界。把握产品最本质的需求，超过边界的我们不要做。
优先级确定
确定了需求做不做，做多少，就要开始分析需求的优先级。因为我们的精力有限，产品规划要求我们每个阶段要求不同，我们也是一件事情、一件事情来完成工作，所以进行需求的先后排序，来一件一件的完成重要的任务。
我们一般会在需求分析时同时进行优先级的判定，两者交叉影响。但由于优先级的确定跟具体工作息息相关，并且需求分析很复杂，我自己难以一下子解释清楚，所以我单独拿了出来。但记住，两者一体，同时进行。
怎么进行优先级确定？
1.结合产品生命周期，根据当前公司的业务规划目标进行判定优先级。
2.用户需求分析，这里会谈到马斯洛需求理论和KANO模型。
马斯洛需求理论将需求按层级从低到高依次为：生理需求、安全需求、社交需求、尊重需求和自我实现需求。这五种需求层级层层递进，只有满足了底层的需求，用户才会进而追求更上层的追求。具体分析时可以按照产品主要形态、普遍用户所处的层级和需求对应的层级进行分析考虑。
KANO模型，将影响满意度的需求划分为五类，分别是反向需求、无差异型需求、基本型需求、期望型需求、魅力型需求。一个需求，可以和模型进行对照。首要解决的一定是基本需求，虽增加该功能不一定能得到什么好处，但没有它一定会很糟糕。主做基本需求、争做期望型需求，碰运气魅力型需求，不做无差异型需求，杜绝反向需求。说者容易，做起来，真的太难了。
这里借用户需求分析来分享一些话。最最开始的时候说过，产品的首要目的是解决用户的需求，毕竟不解决用户的需求，根本不会有人用。忘了从哪看到过，有人说过，一个产品若能满足七宗罪“暴食”、“贪婪”、“懒惰”、“嫉妒”、“骄傲”、“淫欲”、“愤怒”中的任意一条，就能俘获大量的用户。这些最底层的生理需求才是一切的源动力，也是最靠谱的东西。比如，很多人会选择社交作为产品的一个方向，产品在做的时候不仅仅满足了马斯洛第三层的社交需求，更重要的会擦边“淫欲”这个最底层需求。这些产品虽然外在形式不同，但内在都是勾起用户最心底的痒痒，越痒越爽，越爽越多人用……大多成功的产品也是这样把握住了最基本、最底层的需求。
实施分析
确定了做什么需求后，我们接着就该确定具体怎么做了——实施分析。
很多时候我们会面临：技术开发时的各种怼，做出来的功能出现各种问题……这之间的酸爽，体会过的都明白，就是这个味！出现这样的问题，很多时候，就是考虑不清，没做好实施分析。这个阶段一定要谋定而后动，做好实施分析的谋，才能做好功能设计的动。实施分析考究的是细节能否考虑清楚，各种状态间的转换，各种异常状态的处理。
怎么分析？
其实就是怎么考虑的更全面，下面这些小经验分享一下，愿我们一起尽力做到考虑周全，少被怼，阿门！
很多文章介绍需求分析、具体实施的时候，都会说到要从主流程出发，考虑清楚主流程再考虑异常情况，然后逐渐将所有情况都分析彻底。这个非常对，但我一直都觉得这很难操作，我还是会出现考虑多了、考虑少了、纠结在某些地方浪费时间。在工作中有一些小经验分享给大家，或许能得到一些帮助。
实施分析第一步，根据个人知识储备，寻找所有能解决该需求的办法。这时可以通过头脑风暴一起找解决方式。思考解决方式的时候，尽量不要过多思考具体细节。
从这些解决方式中，按照寻找最可行的解决方案。
然后考虑这个功能最完美的样子应该是什么样。
为了达到这个完美的状态，需要进行哪些设置？需要进行哪些操作？最终展示效果是什么样？这里可以画一些简单的页面布局，帮助思考。
为了达成上面所述的完美状态，你需要进行哪些操作流程，可通过VISIO画出流程图。
可以进行头脑风暴这些流程牵涉哪些功能。可使用Xmind这类软件去画出大体的功能结构图，来理顺思路。
确定功能的所有入口和出口。
确定这个功能在流程中每个节点的规则。实际工作中，可能几个小规则的改动会导致你产出不同的功能。
使用VISIO等软件，梳理这个功能的功能流程图。
使用VISIO等软件，去梳理整个功能的业务流程图，即泳道图，来描绘每个身份的操作内容。
使用VISIO等软件，梳理每个身份的操作流程。
有了9就可以用AXURE或手绘简单的页面流程图，做好页面之间的流转关联。
以上都是主流程的思考，这一步就需要费尽心思，思考更全面的异常状态。确定每一个操作，每一个状态改变，会对哪些状态有影响，会因状态的改变而使得哪些数据跟随改变。每一步的数据从哪来，到哪去。这些内容可记录在Xmind的导图中。这一点其实蛮有用的，有些人设计的新功能总是会莫名其妙的缺少状态或者互相之间产生影响生成的BUG，有这部分内容，多少可以避免一部分的BUG存在。这里提一个小技巧，多用反义词。数据有进就有出、有添加就有删除、有来就有往、有这个就没有这个、有填写数据就有不填写数据，有填写多了也有填写少了。有网就有没网、弱网的时候，也就会有打不开的情况……
尽量多一步考虑，思考数据追踪，为了得到这个功能的第一手数据，分析这功能有没有用、好不好用、怎么改进。就是数据埋点。
多思多想，反复互相完善上面的内容信息。
在你觉得没问题的时候，出去走走，散散心，然后再回想一遍所有的状态改变以及异常状态。
从实施分析的时候就叫上UI一起讨论，你可能会更有收获。
功能设计
上一步，谋定后，现在则需要动—动——功能设计。
设计哪些内容？
页面布局。使用AXURE进行页面设计，按照上面提到的页面流程图以及功能结构，将每个页面具体有哪些模块、怎么展示进行表现。
一个一个进行页面设计时，可能会发现一些能够增加用户体验的周边小功能。因为页面设计针对的是用户操作的部分，所以这里非常注重用户体验，能够增加用户体验的小功能都可以放回需求分析中进行重新考虑。
围绕一个功能，为了提高用户体验，可能会有很多小功能，比如增加一个“回到顶部”的小按钮。这种小功能没有很大的流程，单独看起来很简单，但是零零碎碎的有时候很难说清楚。这里把握一点，不谈用户场景，只谈这个小功能使用时所处什么状态。达到这个状态时，会出现什么，怎么操作，然后出现什么状态。
动效。有些公司有专门的交互设计师，动效的实质是用户体验的提升。但是也要好好进行分析，有时候过犹不及；也有时候会对开发有影响。比如你是APP，要明白产品技术框架，很多app是原生+H5的模式，原生部分处理有些动效不需要很高的性能，但是使用H5时则会要求较高的性能。而性能会体现在使用的流畅度。可以在“人人都是产品经理”网站上搜“不想被开发一句话呛回？你得知道这3个最基础的APP技术框架”这里的解释非常全面。
与UI结合。公司不同，工作流程可能不同。有些公司在这时就需要UI设计页面，为产品上肤色。有些公司会在真正开发的时候才需要UI参与。如果你注重用户体验，注重页面美观度的话，越早让UI参与，你可能会得到更好的结果。
产品这一行，有一句常用语“少即是多”。在具体设计时，你可能会灵感爆发，有很多想法，不妨都写出来，回归上面需求分析再进行梳理。有些想法，可能暂时你找不出来优点和缺点，或者优缺点并不明显，又或者难以确定，这时，不做比做好，或者先放下、或者放在数据埋点进行数据分析、调查问卷、或者下方的测试验证中进行一些A/B测试。有些东西是平衡的，让用户感觉简单，可能就需要你考虑的更复杂；你做的东西越多，可能用户用起来就会复杂。
然后，将这一切写在产品需求文档中（PRD），将你的功能意义、流程图、脑图、大小规则、异常情况、产品原型等写在上面，将所有能考虑到的问题都写清楚，后面其他人的工作都会围绕PRD开展，切记不要出现模棱两可的歧义。写PRD要多写，详细到队友能明白，否则队友会认为你是猪；也要少写，一句话能明白的东西就别两句话，毕竟PRD中文字还是比较多的，谁都不想看，你再啰嗦，就更不想看了。总之，写清楚写明白。可以使用一些模板，网上随便搜一下，大体都差不多。
测试验证
上面做的说到底都是我们认为对的，我们的用户认为对么？为此，我们要进行验证。通过验证用数据来说话。
你设计的功能，不可避免的会站在你自己的立场上，会进入一些盲区，或者没有考虑那么全面，就算真的对，你总需要什么来支撑你的观点的。这时通过一些测试进行验证。
这部分，不同公司有不同要求。有些大公司，在需求评审时，就会拿出一些数据为佐证，来说服队友、上司。当然你也是有经历，有资金进行测试验证。有些公司会先进行需求评审，然后确定哪些地方需要进行验证，然后给你钱或者时间去验证。
验证方法有：A/B测试、用户调研等方法。
由于我没经历过测试验证这样的阶段，所以这方面我无法多说，以后用到学到了再补充。
需求评审
我们多少都是站在自己的立场上进行设计，可能由于知识面、能力、牛角尖、盲区等原因，这些设计存在这样或那样的问题，甚至于这些问题无法让团队的其他人认同，为此我们要进行需求评审，充分发挥公司里每个人的能力，来评审产品需求。然后改正问题。
各个身份的人，站在自己的立场和公司的立场上评论需求功能，进行可行性的讨论，尽各自所能挑问题，最终形成统一的意见。对，就是撕逼大会，而且要撕的淋漓尽致，还要撕到别人找不到撕下去的理由，真正的勇士的就是要敢于直面被撕的人生，并爱上这种酸爽。
为什么进行需求评审？
以各自的立场，去看待这件事，尽量找出所有问题，来解决它，否则留着问题到用户手里，你的产品会失去信用。
达成统一意见。这点非常重要。我们无法保证每一个人的意见都能被采纳，也无法保证所有的看法都能最终保持一致，实际上经常会遇到谁也无法说服谁的情况。如果保留分歧去执行，结果可想而知。
需要怎么做？
形成统一的意见很重要！
跟产品有关的所有人员都要参与。
最怕撕太淋漓尽致，更怕别人都不撕。
撕逼的时候，你抛出你的观点，若你有上一步测试验证的数据作为论据，只要你测试手段合理，试问还有谁能撕的动你？还有谁？
在需求评审大会之前，你一定要进行很多小范围内的需求评审和商议，每个环节的同事都要涉及到。和上司、和技术团队、设计、运营、销售等等进行很多接触。那些大的分歧一定要提前就解决，否则开大会时会浪费很多时间。也就是说开大会之前要让大多数人觉得这个功能有必要，并就功能的规则进行通气；至于具体的按钮啊、布局、流程可放在大会上进行探讨。
每个身份的人都要对产品经理评论，毕竟具体实施时，每个人都需要解决各自需要解决的问题。讲真，有些人真的不喜欢说话，不喜欢发言，尤其是人多的时候，技术人员尤其明显。这里也体现提前小会的重要性。
统一意见。统一意见。统一意见。当一些争论好像并不会影响特别重大的情况下，上司要进行最终的拍板（还是之前的小会，要达成尽量的一致）。有意见可以暂时保留，评审会上最终确定的内容要坚决执行，除非你在操作中真的发现影响过于巨大。
有时候需求评审会可能不止一次，有些问题还需再讨论，有些问题返工后需要再次评审。
协同开发
通过需求评审，我们确定了具体工作内容，即将PRD中要求的功能实现出来。为此，各个工种互相配合，将功能落地实现。
在开发过程中需要多人进行合作开发，这其中最重要的事情是相互之间能否将事情说清楚，让产品做出你想要的样子。为了达成这样的效果，要做好两件事：
第一是PRD写的明白无歧义，所有的开发以PRD为标准；
第二，无规矩不成方圆，规定好工作流程，每一个人按照流程做事。（其实，需求评审做好了，一般情况下协同开发时大家的目的都是清晰的，然后每个人按部就班做好自己的事情就能顺顺利利的将产品开发出来）
这里大致说一下一个产品流程，会牵涉到哪些人员。对于互联网产品，最基本的要有五个人员，按照流程：由产品人员进行功能设计，接着由UI设计人员进行界面视觉设计，然后交给前端工程师进行前端开发，以及后端工程师进行后台数据搭建，当产品开发完后，需要运营人员开始运营产品。
开发过程中，谁都无法保证产品没问题，所以有测试人员进行系统功能测试。一个产品为了增强用户体验，可能会需要UE设计师多去考虑用户体验效果，设计一些动态效果。产品、UI、UE、前端、后台、测试、运营，这些人构成了一个公司的开发部门。
不同公司会增加或减少这些人员，但无论怎么变，绝对不会缺少产品、UI、前端、后台、运营这五个职位。其中前端指的有Web前端工程师、Android工程师以及IOS工程师。
工作流程上面已经提到了一些。按照产品、UI、前端、后台的顺序进行功能产品的开发。每个环节交接时，上一级要给清楚下一级需要的所有东西，下一级要进行确认。要在限时时间内做好各自对应的工作。产品居中调控。
协同开发的时候，毕竟是多部门的合作，所以在这个过程中一定会出现很多问题。为了让合作更加顺畅，作为产品经理要做到团队管理的角色。但在职位上产品经理和其他人员平级，没有上下级的关系，所以要从哄、骗、信任感、责任感、打气、画饼、个人魅力等上面花些功夫，从而推动工作进行下去。
记住，工作中和同事之间工作的交接一定按规则办事，将所有的交接文档做好记录。不是为了出问题的时候撇干净自己，而是为了让整个工作更加清晰，不至于混乱。当然，真出问题，有些锅我们不能背，我们是有存档的。
功能上线
经历了这么多波折，产品/功能终于要上线了。别急，你还有一些事情需要做。
再进行一遍测试。
你要通知到所有相关部门的人员，所有人各就各位，做好相关准备工作。
你需要将产品需要的一些数据进行填充。
你需要写出功能说明和操作说明给相关人员。甚至于进行一些培训。
仔细检查一遍产品。
做好随时沟通运营、测试、开发、客服的准备。
接下来，上线吧！
效果评估
产品/功能上线后，通过市场反馈，我们来评估产品的效果，用以发现不足之处，便于纠正。评估效果需要数据来支持，数据就来源于实施分析中提到的数据埋点、用户反馈、第三方数据等，可以用来反馈用户使用的效果。
重复迭代
产品上线了并不意味着我们工作结束了，随着用户的反馈、市场动态，我们不断地收集到信息来优化我们的产品，也就又进入了需求收集、需求分析……这样的一个一个循环，产品的工作，就是在一次次的循环中，走向更好的未来。
关于需求管理
人多了需要管理，需求多了同样也需要管理。通过需求管理，我们可以把需求理顺，方便自己和别人使用。
按上面说的，需求管理应该和需求收集放在一起，为什么要单独放在最后说呢？实际上，需求管理更多情况下，是你工作的一个方式手段。通常我们会建立需求池的方式来进行需求管理。而需求池的建立，会同时涉及到需求收集、需求分析、优先级确定。
需求池是需求的汇总和状态记录，我们可以随时去查看需求池中各种需求以及需求的基本信息，进而可以进行需求分析。所以需求池中，最重要的是对原始需求的记录。
我个人使用Excel进行记录，表头为：序号、提出人、提出时间、需求来源（什么渠道）、需求类型（业务需求、用户需求、功能优化）、所属模块、需求描述、是否需求分析、优先级、价值描述、是否进行功能设计、备注、是否需求评审、备注、状态（对该数据，暂缓、未启动、拒绝、分析中、开发中、已发布）、对接人、对接时间、处理结果、备注、是否反馈（反馈给需求提出人）。
需求管理是为了让工作内容有记录、工作更加规范，同样的，工作中其他方方面都要做好记录，让自己的工作节奏更加整洁规范，越整洁规范，说明你越得心应手。
最后
本篇文章核心词汇是产品、互联网、商业，是以解决问题作为核心能力，以互联网的理念、知识、经验、设计作为工具，来解决互联网公司商业性的问题。我既然写这样一句话，也就说明产品经理并不意味着只能做这些。核心不变，改变工具，你将能跨领域解决其他问题；说到底，产品经理实际是为了解决问题而存在的，掌握解决问题的办法，加上你在这个领域的知识，人人都是产品经理。
文章是想告诉各位产品工作的全貌，文中所示的具体解决办法并不适用所有人所有项目，但都可以借鉴。
关于画原型。对原型我有几点考虑：第一种是为了让自己考虑细节，完善之前设计中没考虑到的问题，从而做到心中有数；第二种最主要的是为了协同合作，为了让别人明白你到底想做什么。根据自己公司的要求、工作内容、同事之间的合作程度来进行原型设计，合适才是最好的，死抠的话反而落入下乘。
我在学习知识的过程中，发现很多产品的技巧和理论其实都来源于心理学以及营销学中，尤其是产品规划这一块内容。在这些方面多下些功夫，可能对未来的提升会有帮助。
从来都没有简单的功能，也从来没有最好的功能。
本文由 @ 函先生 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自unsplash，基于CC0协议
原文链接：写给迷茫的产品新人：产品经理工作体系｜人人都是产品经理
从产品入门到精通全方位学习
BAT资深产品总监亲身参与课程研发及教授
理论学习+实战演练 ，修炼产品功力
了解详情，点击产品经理实战训练营
网友评论