产品简单讲就是我们看到的app，网站，公众号等用户接触到的载体，互联网公司需要通过这些载体来完成赚钱的目的。
互联网也是生意，按照互联网通常的做法是，这个产品抓住了用户的某种需求，把他造出来，通过一些手段来曝光（极少数是自然的口碑传播），用户知道了，觉得这个产品满足了自己的某种需求，就会使用。
一、一个产品是怎么诞生的
产品的核心就是满足你的目标用户的需求，开展工作也是在围绕这一点。
其中涉及到几个关键点，
- 产品满足用户的需求
- 把产品造出来（程序猿）
- 通过手段曝光产品（运营）
如果还不知道什么是运营的，可以观看一篇文全面解析『互联网运营』是什么？有没有前途？
满足用户的需求从诞生到把它造出来的过程就是产品经理的核心工作
这个点呢，一般是老板会有个最初的想法，也可能是借鉴别人的产品，这里可能不需要产品经理，那么就会下面的场景：
老板找来程序猿小李，说：“我们要做满足哪些用户哪种需求的app，你去把我说的做出来。”
小李必然瞬间蒙圈，然后会问老板：“老板，这个产品我们是做ios版呢？还是安卓版呢？你说的用户那个需求怎么来满足呢？进来一个页面看到的是什么呢？要输手机号注册吗等几百个问题呢？”
老板哪有这么多时间和你一一确认啊，会说：“小李啊，你问题提得很好，但是我很忙，后面具体的问题，你就和小马沟通，他清楚我说的这个需求，最后把拿不准的问题列给我，我给你统一回复。”
二、产品经理扮演的角色以及有哪些工作
下面该小马出场了，小马的角色就是产品经理（上面如果老板有时间一一确认，并且会做下面小马做的事情，实际上老板就是产品经理的角色）。
- 小马接到这个任务首先找老板确认了老板所说的用户需求，并听取他说的商业逻辑，这是和需求提出方确认需求，并确认最终交付产品时间。
- 小马需要去问老板所说的用户，确认用户的本质需求，或者去了解老板借鉴的那个产品，那个产品做了什么，这是需求调研
- 小马根据需求，梳理出产品的核心逻辑，画出产品完整的流程图，确认产品结构，画出原型图，拿给老板确认，这是和需求方确认产品
- 小马细化这些逻辑，形成需求文档，使开发拿到这个文档能做出和自己想法一样的产品，这是从明确需求到形成需求文档的过程
小马会告诉小李，明天我们一起开个会，小刘（设计师）和小张，小陈（前端开发），小徐（测试）都叫上。开会时小马和大家详细的讲解了需求文档，叫小刘会后根据需求文档和原型图开始画效果图，要好看，要用起来舒服，小李，小张和小陈先看下需求文档有没有问题，思考下怎么实现这些功能，然后我们自己先用下，保证做出来的东西和我今天说的一样的。之后拿给小陈测试，确保逻辑都没有问题，现在安卓那么多手机，苹果都出了10多种手机，一定要把现在主流手机都测到，你们都把自己要做的事情列一下，然后评估个时间给我。这就是需求评审，确保产品经理把自己的想法明确的传达给参会的各位，并明确各人的分工和职责和时间节点。 - 小马拿到各位要做的事情和时间节点后，会排出计划表，细致程度根据产品开发周期而定，还需涉及到ui和前端的先后顺序，后台和前端的调试时间，最终的还是产品提交测试时间和最终上线时间，这个计划表，在传统的IT公司是由项目经理做的，设置项目经理岗位的互联网公司很少，所以这个活由产品经理来做（前提是没有项目经理）。
那么接下来，产品就按照计划表来执行了，接下来产品经理是不是就没事了，那就太轻松了，往下看。
小马已经很清楚设计师，开发和测试完成该项目的时间了，因为时间有限，第一版本制作了最核心的功能，还有一些不是很确定或者非核心功能并没有在第一版计划内，小马接下来会做第二版的需求调研
那么小马接下来会研究竞争产品，发现竟品又更新了新功能，小马这时候会有两个问题：
- 为什么这些功能竟品能想到，我却想不到
- 这功能真的好吗，判断依据是什么
接下来，小马会做几件事情，这些事情会不是一步到位的，需要持续地做：
- 研究更多的app，和同行交流，去发现其他的产品经理怎么实现它们的逻辑的；
- 接触更多的目标用户，了解一些用户的想法；
- 建立数据系统，使功能好坏能够量化，并且可以宏观的了解用户行为。
小马在产品第一版做完之前，来源于上面三件事情，一定做好了第二版的功能设计，接着重复上一个产品的过程
第一版投放市场后，通过一定的曝光量（或者自然的口碑传播），用户知道了，觉得这个产品满足了自己的某种需求，就会用下去，公司通过用户的数据（比如注册用户量，日活）来证明自己最初的想法是对的，用户都是有钱的，要么现在让用户掏钱， 要么去说服老板们投资。
如果用户不买账，就要去搞明白用户为什么不买帐，是需求问题，还是体验问题，找到了问题，继而找解决方案，好的产品永远是改出来的（当然，支付宝这样的除外）
当一款产品有了一定用户后，就像其他行业一样，一定会有其他公司眼红，就会出现竞争产品，来和你抢用户。这时候，像传统行业一样，自身需要升级产品（当然也会打击竞争对手，这个不属于我的讨论范畴），提供更好的服务来留住用户，互联网也一样，只是升级产品更便捷，升级产品是需要依据的，而不是一群人在闭门造车，竞争会使一些公司死掉或者卖掉，但是产品的体验会更好，团读的每个人会更强大，产品经理尤甚。
三、一款产品无到有，产品经理需要做些什么？
在一个产品从无到有的过程中，要做好产品经理这个角色实在是不容易，除了大家都知道的写需求、写需求、写需求，要做的事多着呢。产品经理不是你眼中的只会找你麻烦，提要求，下面跟着这张思维导图了解一下，产品经理在一款产品从无到有的过程中需要做什么吧！
1、市场调研--发现问题
如果是创业或作为项目的发起人，首先肯定是源于一个idea，发现了什么问题，有什么用户痛点，能提供什么样的解决方案，或者刚开始仅是作为一枚小PM，需求想法来之于老板、领导。
一个想法出现，自然会经过可行性分析和竞品分析，并结合自己的团队分析。
可行性分析：自然是要进行调研分析来判断是否可行，是否有市场，有多大用户规模，适用什么样的商用模式，最后会决定是否值得去做，经过后就要去寻找同类竞品了。
竞品分析：同类竞品有那些？他们的收益如何？竞争是否激烈等
团队分析：自身公司分析、团队的优劣势分析，开发难度分析，投入成本和收益等
是否有竞品，竞品发展如何，他们收益如何，竞争是否激烈等。
2、用户分析--明确需求、用户访谈
有了一个自己觉得还不错的想法，容易掉到自己的思想误区中，因为这个想法很有可能是伪需求，或者错误理解了市场环境。
所以要多去了解我们的未来目标用户，和他们沟通，进行用户访谈，形成用户报告。
比如这个问题是否他们也遇到过？
给他们造成了多大困恼？
他们是否想过去解决这个问题？他们的解决方案是什么？
他们愿意为了解决这个问题付出多大的成本？
你的解决方案他们是否感兴趣？
是否愿意付费等等……
通过多次访问过后，才能真正的确认用户的需求，并给出正确的解决方案。
在进行用户分析时，可能需要用到一些图表来对用户行为、数据进行整理，如：柱状图、线形图、雷达图、比较图等。
3、设计高保真可交互原型
经过了前两个步骤，都得到肯定的话，那么就可以开始设计产品原型图了。
原型图很多人喜欢做动效，逼真度很高，效果好是好，但是考虑到时间成本的问题，能让设计、技术看懂即可（特殊需求除外）。
推崇高保真原型，可以让你在设计过程中很快发现细节问题，避免遗漏，在项目初期，也更容易向项目其他人阐述想法，并且在完成原型后还可以拿着它再做次用户调研，进行二次论证。
4、需求梳理、团队沟通
设计原型图时往往不急着写PRD，这时候多和同事沟通，特别是技术类的同事，交流一下哪个需求实现比较困难，什么需求在Android好实现，但在iOS不好实现，将问题全面梳理，做好记录。
5、写PRD、制定版本迭代规划
沟通确定后，PM会修改原型，拿出一个更可行的方案，过程中还会不断地开会，明确需求，最后开始写PRD。可以用思维导图罗列好所有的需求点，想好优先升级，按功能模块、业务逻辑等将需求拆分来，制定好前几个版本的迭代规划。
6、交互设计、UI设计
在交互和UI的阶段，新产品可能进行的比较慢，文案输出、交互规范、视觉风格、颜色间距等，都是要对比推敲最后才能得到一个方案，省时间的就是直接去copy一个现有的产品风格，这还是取决于公司如何看待这个产品，再决定是否为了省时间而在此阶段走捷径。
7、开发过程、及时沟通
各项资源都出来之后，开发要做事了，这期间要PM主要是跟进项目，和开发及时沟通，如果有一个点开发不明白又没和你沟通，然后按自己以为的做了，理解对了就算了，理解错的话，最后的结果一定是导致项目拖延。
8、测试、设计走查、模拟运营
开发完成后，就要开始测试，主要是界面适配，系统兼容，性能、bug等问题，也要邀请交互设计、UI设计进行走查。
我们之前的项目是内容类APP，所以在这个阶段，也需要邀请运营团队录入内容，模拟运营，测试push流程等。
需要不断的去把控、监督，协调各部们的工作，保证项目按时、按质的完成，达到既定的目标。
所以，沟通协调各部门的工作，也是产品经理一个很重要的能力。
9、准备推广方案、产品上线
发布app需要一些资料比如文案、宣传图，有些特别的app还需要资质文件，这些PM都要提前做功课，并且和市场部门同事一起规划推广方案，比如在哪些渠道申请首发等。
如果产品刚上线的数据不佳，无人使用，那么需要去想办法邀请第一批种子用户，这是另一个大话题，不阐述了。
10、产品数据、用户反馈
产品上线运营后，PM就需要分析产品数据了，了解app的DAU、安装量、激活量、用户使用时长、启动次数等等，包括用户行为数据，用户都使用了哪些功能，哪些流程他们经常只进行到了一半。
并且产品新上线后，可能会有用户评论，来自应用市场、社交平台、新闻媒体的，多去听听别人的声音，多跟用户沟通，然后不然优化产品，快速迭代。
这些就是一个产品从0到1、从无到有，产品经理要做的一些事情的流程，当然这些事并不是一个步骤完了下一个步骤才开始，有些是同时进行的。
从以上叙述中可以看出产品经理工作还是挺多的，并且需要做很多的数据收集和分析，绘制各种图形图表，使用图表软件，可以一定程度的提高产品经理的工作效率和展示表达的直观性，方便各部门的理解，你不妨也来试试吧~
附录一张：产品经理技能图
产品经理技能图
产品技能金字塔
新增文字
一流产品经理和三流产品经理，最本质的区别是什么？--全都是需有能力
出于好奇，我就近找了身边几位产品经理聊了聊，梳理了最重要的三点差异。
一、用户思维
你的目标用户是哪些人？
他们的需求真的是一样的吗？
目标用户聚焦的渠道呢？微博、微信、知乎、头条呢？
前期有做过渠道A/B测试吗？
所以你的产品为了谁？解决了什么问题？你有提前去了解吗？直接一上来就开始埋头苦干，你不死，谁死？
那么真正优秀的产品是怎么做的呢？
产品竞争分析，找到产品的优势和特性；而在产品初期，他们也会花大量的精力做用户调查，找到目标用户的真正需求点。
这就是差距产生的真正原因了----用户思维贯穿产品始终，不同阶段侧重点也会不同
• 产品初期，做竞品分析，做用户调查，主要是针对某一类垂直用户找到垂直的产品需求和差异性，把产品做精，切勿贪大求全。
• 产品中期，随着用户量的增长，开始要做大量的用户反馈，小步快跑不断做好产品优化和迭代，在保证用户持续增长的同时，产品的性能和体验要随时在线。
• 产品后期，各项功能已经非常完善了，这个时候你的用户反馈需要往横行方面拓展，看看用户潜在的需求，把用户不敢想或是还未想到的提前做出来，产品开始做全做大。
优秀的产品，不是一开始就要马上去做产品，而是学会去了解你的用户。
二、数据思维
懂数据并尊重数据
1、不懂分辨真假数据，简直是万恶之源
案例：
K是某公司的产品经理，开发新品为一款跑步记录APP 。产品上线前，项目组定下的目标是一周内达到3W注册量，这个KPI，让K彻夜难眠。
某天周末，看到小区菜市场的大爷大妈们都在疯狂抢购一款按摩仪，这给了K无限灵感，他立马起草推广方案，“扫码下载APP，送食用油”，还别说，效果立竿见影，凭借大妈们的社区号召力，KPI早已突破天际。
但公司在后续分析用户在线行为时，发现DAU等指标基本为0。K他们带来的第一批用户并没有给公司带来多大价值，为什么呢？
虽然K确实是达到了APP注册量，但扫码送赠品，而且推广对象为社区大妈们，无疑就是急功近利的“作弊行为”。
2、再来说说数据背后的用户行为
五个月后K带着团队重新梳理产品框架，重视数据有效性，终于摆脱了“伪数据”的泥潭。
结果产品注册量是上去了，但分享率却依旧很低，这使得产品没法在用户之间形成二次传播，产品无法突破现有的用户圈层，这一点让他们很是困惑。
是产品用户体验不好，还是产品用户引导不明显呢？这一次他们没有自己想当然，而是拉出全部可能关联的产品数据并逐一分析。
结果在一堆数据中，他们发现产品分享界面的用户跳转率高达87%左右，用户停留时长仅仅在1-2秒之间，低于平均一般水平。
那么到底是用户对分享界面不感冒还是对分享奖励机制不满意呢？或许这个只有用户最清楚。
接下来，他们又用了一周时间，做了2000多位的用户问卷调查+1v1调查，发现有80%左右的用户并不知道有分享有奖的功能，很明显，就是分享页面不明显。
针对这一数据反馈，他们立即在用户跑步结束后，增加了语音提示+弹屏提示，“炫出你的成绩，让更多好友看到”，利用用户攀比成绩的心理，增加用户分享乐趣。
我们都知道用户行为在产品数据上呈现出‘漏斗状’，一步一步流失，也一步一步更加精分。
但是有多少能像K他们一样，找到数据背后用户真正的需求呢？或许只做一步小小的改变，结果就会有大大不同。
三、全栈思维
所谓的全栈思维指的是对上下游业务环节的多面了解，产品除了本职岗位的了解，对技术、设计、运营、市场等相关业务范畴也需要有一定认知，其中最重要的就是对运营的了解。
“为什么别人能做我们不能做，那你的产品有什么优势？”
“需求不是随便提提就能实现的，和你解释也不懂”
以上这些场景，是不是似曾相识？产品和运营的相互撕逼，我相信这是令很多产品头大的地方。
为什么两者之间的矛盾会如此大呢？我们先来看看两者工作的差异性：
产品工作指标：以用户体验为最终目标，工作比较难量化
运营工作目标：背负运营数据KPI，工作可以量化
产品沟通对象：主要为开发和设计，对内沟通较多
运营沟通对象：用户和合作方，基本为对外沟通
产品对用户的感知：是抽象的角色，一般来说有抽象的用户画像。
运营对用户的感知：鲜活的，具体的人。因为运营每天接触形形色色的用户，而且能明确到每一个人。
看到以上两者的差异就不难发现问题所在了：对用户负责的产品，每天却在做大量的对内沟通，基本上没多少‘直面’用户的机会。
但一个优秀的产品不是把自己框在产品这个狭小的业务模块里，必须得了解业务上下游的工作流程和需求，懂框架，明流程，会沟通，只有具备的全栈的工作思维，才能让自己的工作更加顺利。
我认为一位优秀的产品经理在处理这件事上，有以几点可以借鉴和参考：
1、忠于目标
大家都说产品生孩子，运营是养孩子，最终大家的目标都在孩子。如果发生了分歧，我们是不是该回到产品本身，看看产品的定位，产品所处的阶段呢？
产品有义务对运营进行产品相关培训，也必须了解运营的工作流程，具备一定运营思维；运营除了要主动对产品有所认知，也需要理解产品的工作模式和难点。
2、明确决策权
很多产品觉得自己每天围着运营需求团团转，因为运营是直接对接用户端的，所以经常会给其他部门提出不同需求，容易养成整个世界都围绕运营转的错觉。
但其实最终决策权是在产品手中的，因为产品最终是对用户体验负责的，这一点在上下游工作中必须明确。
3、加强沟通
双方确保信息对称。产品做了哪些优化，迭代了哪些功能，及时对运营进行培训；
同时运营接到用户反馈，数据分析得出的产品变化等这些信息及时同步给产品经理，好让产品经理在下一个版本优化遇到的问题。
产品和运营是密不可分的。产品为运营搭建基本的框架，运营为产品提供用户反馈和市场需求。一个不懂运营的产品不是好产品，一个不了解产品的运营不是好的运营。
产品经理基本功
一、需求管理
需求管理是产品经理的最基本的能力吧？
那么，作为「产品经理」的你，是如何做需求管理的呢？
最简单的需求管理：
1. 各级负责人：提出者（谁提出的？最初怎么说的？）、需求负责人（这个需求是哪个PM在管理？）、开发负责人（谁是负责开发团队的Leader？）、测试负责人（谁来负责测试团队按期测试？）、运营负责人（上线后谁来运营？）
2. 状态：需求中（提出者正在准备提需求）、待讨论（需求已提出，详情待确认）、已拒绝（需求被干掉了）、暂缓（需求不明确，还要再讨论；需求明确了，但现在优先级不高，需要等待重新激活……）、已确认（已经确认需求）、开发中、测试中、已上线……
3. 时间信息：提出时间、录入时间、发布时间
作为产品经理，你是否是通过这种方式去做最简单的需求管理的呢？
进阶一点的需求管理，你除了要有这张表，还要能从需求方的表达中，去寻找完整的逻辑，这个需求是从何而来，为何提出，为何要做，不做会怎么样，优先级的判断都要基于「真实需求」的管理。
什么是真实需求？
有两个故事被说了无数遍。
故事一：
美国营销大师菲利普·科特勒曾经讲过这样的故事：
一个顾客首先来到第一家店问，「你们家有12寸的钻头吗？」第一家店主说：「没有，只有10寸的钻头。」然后顾客就走了；
他来到第二家店铺，问店主：「你们家有12寸的钻头吗？」店主说：「我们家只有10寸和11寸的钻头」于是便走人了；
他来到第三家店店主还是这样的结果。
到了第四家店铺，他问店主：「你们家有12寸钻头吗？」店主说：「没有，只有10和11寸的钻头，但是，不知道您用12寸钻头做什么用啊？」顾客回答：「哦，因为我们家墙壁需要钻一个12寸的洞来装修房屋。」店主说：「原来是这样啊，我们家的10寸钻头就可以帮您这个忙，您按照12寸规格来钻，然后稍微再往里面深入打磨一下就可以了，而且还经济实惠，比12寸的价格便宜很多。」顾客想了想说：「真如您所说？」店主回答：「管不管用，您试试不就知道了吗？」于是10寸钻头就这样成交卖出。」
这就是著名的「客户要买的不是钻头，是洞」的故事。
第二个：
100多年前，福特公司的创始人亨利·福特先生到处跑去问客户：「您需要一个什么样的更好的交通工具？」几乎所有人的答案都是：「我要一匹更快的马。」
很多人听到这个答案，于是立马跑到马场去选马配种，以满足客户的需求。但是福特先生却没有立马往马场跑，而是接着往下问。
福特：「你为什么需要一匹更快的马？」客户：「因为可以跑得更快！」福特：「你为什么需要跑得更快？」客户：「因为这样我就可以更早的到达目的地。」福特：「所以，你要一匹更快的马的真正用意是？」客户：「用更短的时间、更快地到达目的地！」
于是，福特并没有往马场跑去，而是选择了制造汽车去满足客户的需求。
这就是著名的「福特造车」的故事。
多少产品经理听过这些故事？最后工作的时候，有几个能落实到真正的需求管理中去？
请自己反省。
二、决策逻辑
产品经理的屁股通常坐在用户一侧，追求让用户使用更好、更爽体验的产品，是很多产品经理毕生的追求。
但是，我接下来要说产品经理的决策逻辑，因为我敢说，大多数产品经理在做拒绝需求的理由是：
会伤害用户体验
好，看到这里，如果你是一个用这个理由去拒绝需求的PM，请你大胆的仔细的看下去。
在盛大的时候，企业文化中，对于争议的决策树是这样设计的：
1.有数据时，数据第一。没有任何人的观点可以大于客观数据的权重。如果数据说，这个产品烂，那么它就是烂，你要想办法去让数据涨起来。
2.没数据时，逻辑第一。如果大家在讨论的事情，没有数据可以做支持，或者数据并不能说明问题，那么就要比拼逻辑，所谓逻辑就是从A到B，是有顺序，有因果，有联系的。如果从A到B，没有顺序，没有因果，也不能证明其联系，那就是没有逻辑。
3.碰到逻辑也解决不了的问题，谁负责，谁拍板决策。谁负责，拼的不是title，拼的是谁要为最终结果负责。运营如果和产品争执某个功能的需求，这个需求，没有数据支持，逻辑也无法互相说服，那么很简单，谁来负责这个需求上线后的数据表现，谁来背这个KPI，谁拍板决策。
或许是我做这一行太久了。
见过很多有数据sense、逻辑清晰、敢于负责的产品，但也见过很多完全没有数据sense，甚至没有基本逻辑，只知道听老板指挥的产品。
可想而知这两类PM日后的发展会如何。
曾几何时，BAT的各种人都被猎头追捧，现在，有些公司的有些岗位，都得看入职年限了，因为被坑的次数有点多了，就知道背景漂亮对于PM或者运营或者开发来说，并没有太大意义，关键的还是能力和业绩。
思路清晰
我非常喜欢思路清晰的产品经理，同时，我又非常讨厌一种PM：思路混乱，还要滥用对标。
譬如，BAT这样做，所以我们也应当这样做，BAT不这样做，所以我们也不该这样做。
请问，微信现在体量这么大了，不敢随便做动作，所以很多产品经理都在做维护工作，是不是你现在也不要做迭代了呢？
弄清楚自己的产品所在的阶段，很重要；弄清楚不同阶段的产品应当负担什么职责，很重要；弄清楚产品本身是1，需要运营、市场让它壮大，更重要。
所以，思路清晰对于PM来说，非常关键。
你要很明白为什么别人做这个设计，你是否可以做这一类的设计。
你要明白为什么需求是这个样子，背后究竟意味着什么。
这些都依赖于产品经理的思路是否足够清晰，而不是通过简单的对标来完成。
舍我其谁
最后要说的，是责任感问题。
一个产品做出来了，做得好，数据会告诉你；做的不好，数据也会告诉你。
但，你能否承担相应的责任。
一个数据表现不那么好的产品，是继续让它拖着苟延残喘，还是当断则断，干掉它或者去重构？
有些产品经理的责任感，真的不行。
而责任感的缺失，和产品经理的考核有直接关系。
过去，在项目制架构下，产品经理是断不敢说，这个需求我不接，因为影响用户体验这种废话的，因为，这个产品从无到有，要活下去就是靠数据来证明，于是单独做出产品其实没什么卵用，还是需要运营、市场的帮助，让它持续的成长。
「产品经理改变世界」这种口号，我不反对，但这个口号说的是发起点，而不是终结点。
如果仅仅靠产品经理就能改变世界，世界也太简单了些。
所以我说，如果你的需求管理做得烂、决策逻辑又混乱、思路不清晰，还没有责任心的话，你绝对不配叫做「产品经理」。
回过头来，这个世界一定会越来越缺乏有运营思维的产品经理，也会越来越缺乏懂产品的运营。所以，说起来，机会是巨大的，能否抓住机会，看个人修为。
