<不断输入不断输出，在未来某一天构建自己的产品体系>
从不同角度产品经理有着不同分类，之前和一位产品经理聊天，从发展角度他将产品经理分为三类，一类是执行产品经理，老板交给明确清晰的需求，只需按照特定路径完成功能设计推进项目保证上线就可以。第二类是增长产品经理，独立负责部分功能模块，带着KPI去思考产品背后的用户、需求、场景，通过数据验证上线的功能并保证KPI的完成。第三类是破局产品经理，这类产品经理或是给已经成熟的产品带去新的数据增长方向开启产品的下一个生命周期，或是在某个领域定义新的产品，实现获客进而占据一定的市场份额。每个产品人都会经历产品路上的不同阶段，而必经之路是产品新人阶段，即做好一名执行产品经理的角色，这个阶段极其痛苦且有些漫长，是产品路上的第一个渡劫。而这个阶段作为新人主要是被动接受导师交给的产品需求，而自己需要做到的是拆解已有的需求点并在导师的指导下完成功能设计和项目推进。被动接受是这阶段的主要状态，但与此同时又需要自己主动学习，像一块干海绵吸水，快速了解涉及产品的各个方面。
过去快一年时间里作为一个产品新人（实习生角色）我既有跟着导师做数据增长也有跟着做一款全新的产品，从0到1实现产品框架的搭建并实现数据上的从0到99+。这个过程踩过很多坑，在每个坑里都收获很多最终实现个人成长并顺利度过第一个渡劫。学产品就像练功夫一样，既要修炼外在的一招一式又要练内功心法，只有内外兼修才能真正成为一名高手，成为拥有一套产品方法论的人，将产品能力内化成自己的底层能力，进而实现知识技能迁移用在其他行业。
心法修炼篇
<时间管理>
产品实习生面试通过就开始在公司上班啦，当时面试虽然能和面试官聊一些产品的东西但那些都是在背书上的理论或别人的面试经验，实习才是真正开始了自己的产品之路。而在最开始上班期间导师跟我介绍基本的工作流程，并交给一些小的需求点让自己来做，所以工作时间很轻松。当时也没有时间管理意识，大部分上班时间都在刷手机各种APP或者和微信里的朋友聊天。随着工作的逐渐深入，工作量增加后发现自己的时间很混乱，要么是有时不知道做些什么，要么忙的没有头绪和方向感。
作为一名产品新人在一开始进入这个角色时就应该有时间管理意识。对时间管理总结一句话是：有条理的强制自己关注那些重要的事情，抑制住对紧急事情的冲动。首先把想做的要做的事情写下来，很多人都会用清单记录软件，去记录自己需要做的事情，其实用什么软件不重要，重要的是写在自己看得见的地方。我之前也会用一些记录软件但发现自己并不习惯每天都打开这些软件，所以在工作中我会把要做的事情写在每天都会用的axure软件上，而在生活中我会在微信上把自己的聊天窗口置顶，接下来需要做的事情都发给自己，每天打开微信的频率最高自然记得要做哪些事情。其次别给自己留太多时间，今日事今日毕，不管在生活还是工作中很多人都有拖延症，其实拖延的问题点就是给自己留有太多时间。最后给要做的事情进行优先级排序，保证要做的都是重要的，允许中间穿插小事情但保证不影响其他事情的进度。对于事情的优先级判定主要从紧急程度和重要程度来考虑。目前我的每天工作安排是早上来到公司先看一看负责模块的数据情况，体验自己的产品（成为自己产品的核心用户），根据前一天的事情优先级开始一整天的工作，同时也要穿插着面对其他人和你有交集的事情，下班前记录一整天的工作总结和收获。
<owner意识>
产品实习生和毕业生面试经常会被问到产品经理属于一个什么角色？没有标准答案，主要看你对产品经理这个岗位的理解并考察面试者是否有主人翁意识。一个产品或功能的上线需要多部门多岗位的协同努力，但这里面的核心是产品经理，它需要对结果负责，去协调所有人共同完成上线工作。所以一名产品经理没有owner意识，很难想象他是否能推动产品顺利上线。
实习初期导师会交给我小的需求，带着我完成prd的书写和需求评审，之后便是项目跟进了。而我当时犯得错误是以为产品经理出完prd完成评审就是其他人的事情了。出图有设计、开发有各端的研发，有测试去测bug。清楚记得我的需求完成开发和测试在发版前，导师把我叫过去问开发出来的功能为什么和我的prd不一致，我当时哑口无言，最后只能硬着头皮让开发改过来。从那以后逐渐明白owner意识对产品人来说是最基础的要求，用我特别推崇的产品经理王诗沐来说产品人要有创业精神。人都是自私的，只会对自己的事情更上心，所有做产品时有owner意识才能保证推动项目顺利进行，一旦出现任何问题最终负责任的还是自己，别指望有人给你擦屁股。
<形成自驱力>
虽说有时候选择比努力更重要，但如果不努力很容易就落后被淘汰。在产品培训会上产品总监讲过一个故事，他研究生毕业在百度做产品，可他本科毕业的同学在百度已经是他的领导级员工了。这成为他进入职场后工作中最大的驱动力，在前一两年尽可能的把工作的每件事做好，学习更多的知识技能为的是能赶上他的同学，以最短速度缩小两人的差距。产品岗需要掌握的东西本来就很多，需要有很强的综合能力，产品新人在前两年需要不断的主动学习各种知识，尽可能多的掌握各项能力，从需求分析到项目推进再到数据分析都需要去打基础，还要多体验各类产品深度思考形成自己的产品感。我在工作和生活中也有自己的驱动力，大学里有一个同学长得很帅能力有超强，属于那种不用很努力就可以把事情做好的一类，毕业后去了bat中的一个公司。这同样激励着我去更努力地学习产品知识，早点形成一套完整的产品方法论。
<需求分析>
用户、需求、场景是经常挂在产品嘴边的几个词。需求的来源从哪来？面试的时候我们经常回答需求收集主要通过用户调研和反馈、数据分析、老板或上司给的任务、产品经理自己对产品的把控等。在实际工作中需求来源也确实主要是这几个方面，但当我们接到需求后还需要分析需求，这时候就不得不提同理心和人性这两个词了。
同理心和洞察人性是很多产品大佬都多次提到的关键词。其实在早期工作中自己并没有太多感受，需求都是自己的导师明确给出，比如我们要做一个排行榜或者评论区。那作为产品新人就需要考虑怎么去设计这个评论区，可能这个阶段更多的是锻炼我们的逻辑思维和产品设计能力，对需求分析的要求并不是很高。但其实即使这样，我们在设计时也应该去想为什么要做评论区？用户有哪些需求？经常去思考很有助于提升我们的产品感。
最近我开始独立去负责一个社区模块，不再是以前导师告诉我我们需要具体做哪些功能，导师说我们要重新做一个社区并扔下了KPI，至于这个社区有哪些功能，内容方向是什么都是需要我自己去思考的。这时候需要设身处地的去想我的用户是谁？有哪些特征？有着怎样的需求？在什么场景下会来到社区？这个社区能给用户带来什么？社区的内容怎么建设？都是需要去思考的。其中最重要的是如何做到准确的找到用户的真实需求，并能很好的把握用户需求，有针对性的设计产品功能去实现和满足用户需求创造价值。最近看了《上瘾》这本书（https://www.jianshu.com/p/f38c67890174）和听了梁宁的产品课对人性把握和同理心这一块有很大感受附上之前写的两篇相关文章（https://www.jianshu.com/p/56077063dddd）。
<沟通能力>
沟通能力是产品经理必备的几个基本能力之一，而在产品人日常工作中沟通也占据了很大一部分时间，沟通能力的重要性自然不必多言。在需求评审会、推动项目进度、跨部门协同时都需要对接不同的人去沟通。沟通的目的是为了同步信息并保证信息的传达者和接收者对信息的理解一致，但在工作中经常因为沟通的问题而浪费很多时间，主要原因在沟通方式和沟通技巧方面。沟通的方式多种多样，有办公软件、邮件、电话、视频、面对面沟通。选择的沟通方式主要取决于沟通的内容复杂程度和重要程度。如一般简单性沟通通过办公软件文字或语音沟通即可，比较正式或跨部门的沟通则需要发邮件，因时空问题可以选择电话视频沟通，如果沟通内容既复杂又涉及人员较多可通过面对面会议形式选择沟通。
沟通是信息传达者表达内容，接收者接收信息并确认两者信息是否一致的过程，在这一过程中有一个沟通漏斗转化模型，信息传达者脑子里要表达的信息是100，可能到最后接收者复述出来只有20的信息，在这一过程中信息的真实性和完整性都有折损。而沟通技巧则是提高转化率，主要表现在信息传达者在表述前需要列好要表达的信息内容并有层次感，比如金字塔型，先阐述结果，再列举如下1、2、3条理由，这样有助于信息的完整减少遗漏的可能性。此外在表述时也要有层次的说出来，以便信息接收者更好的理解，同时在面对不同的沟通对象，产品人需要用不同的话术，比如在和用户沟通时总是提DAU、转化率、留存等产品术语便不合适了，用接收者习惯理解的用语更有利于沟通。在确认信息是否一致时，也有值得注意的地方，尽可能的听完对方的表达再阐述自己的想法，避免总是打断对方的思路，同时对于谈话的内容主题要把握好。我们在和同事沟通时很容易就聊跑偏，造成沟通效率低下，既然是在确认信息时就应该保持专注度，可以开玩笑但不能像聊天形式浪费工作时间。
<项目管理>
产品人除了日常收集需求定义产品以外，另一个重要工作就是项目管理，推动项目进程保证需求正常上线。产品新人在项目管理这一环节都吃过不少亏，比如rd在开发时总会说需求评审时细节没讨论这个功能做不了，qa测试时rd又会说pm没说要做这个功能啊，需求评审完项目进度迟迟推进不动，有时是rd找pm催图，有时rd找pm催着要接口。pm作为需求的负责人需要协调所有相关人员，必须保证每个环节的进度是正常，对需求的理解是无误的，一旦出现问题pm就需要担责任并承受巨大的项目delay压力。
说了这多项目管理中的问题，那项目管理的是如何定义的？项目管理是通过周密的计划管好项目中的人、事、物，达成项目目标。对于pm而言项目管理就是通过推动设计、开发、测试等人员保证需求如期保质量上线。那如何做好项目管理呢？一般在需求评审完后便进入项目排期阶段，产品经理在确定相关人员后需要通过利用甘特图制定项目上线计划即项目周期。其实很多人在这个环节有着很大困惑，pm怎么能确定行之有效的项目周期呢？开发给的时间是不是可靠的？在确定计划时主要去询问设计同学的出图时间、找技术经理确定各个开发位置的开发时间再向qa确认测试时间就会有一个可行的项目排期计划。对于新人而言如果不确定给的时间是否靠谱就简单的办法就是找到相关人员的直属leader确定排期，不过随着工作的深入pm对设计和开发的了解也应该可以有效判断项目排期。
列好项目计划后就开始执行，而这一过程中pm要做的是确认项目细节，监督项目进度。在项目细节方面主要是在出图和正式开发时ui和rd会反复跟pm确认细节和可行性的问题，至于细节的密度和数量上取决于pm的prd文档和需求评审时的效果。在每一环节pm都需要自己去确认项目的阶段性成果，比如ui出完图后要看一下视觉稿是否和prd一致，设计样式是否符合预期，rd开发完后在测试前pm要先打包体验一下，页面样式是否和视觉稿一致，页面逻辑是否有误或缺漏，qa测试完在上线前pm也需要再次确认测试包是否和prd一致，只有通过多次确认才能保证上线时功能、视觉一致，没有逻辑错误或缺失。此外在项目推动阶段，例会是不可缺少的部分，例会的目的在于项目期间各岗位有开发风险要及时提出，尽早暴露风险减少项目delay的可能性。
项目推动中需求变更是不可避免的，在相关人员中，rd是最容易砍需求致使需求变更的。比如某个功能实现不了，某个页面逻辑要改动。此时是pm和rd沟通和博弈的过程，不过作为pm最重要的一个原则是面对影响用户体验和功能不完整的要求坚决不能妥协，哪怕项目存在delay风险。之前我在跟进产品某一板块大改版项目时，在某些功能实现样式和逻辑上因为性格原因选择向rd妥协，在项目验收时老大找到我很严厉地将几个妥协的存在的问题指出来，要求必须在上线前改掉保证用户体验否则项目就延期上线。其实这就是自己妥协带来的后果，所以pm在保证prd细节完整且合理基础上，面对rd提出变更需求时一定不要轻易妥协和让步。此外项目推动中也会存在风险问题，pm作为项目推动者和负责人，面临风险时一定要及时上报给自己的leader同步所有相关人员并联系能解决项目风险的关系人。在一次需求迭代中，临近产品首发发版时，测试发现一个影响用户体验的bug，当时的rd却解决不了这个问题，而恰巧当时的技术负责人在开会，我在一面将问题汇报给leader时另一方面去和渠道同事同步问题并确认最后给线上包时间。
招式练习篇
<prd文档撰写>
prd是产品需求文档的简称，那产品需求文档又是什么？是对产品需求的完整描述、是开发和测试的唯一凭据、是pm综合能力的体现。prd的载体形式没有固定标准，可以是Word也可以是Axure（之前实习的两家公司prd文档就分别是Word和Axure）。对于新人而言一开始上手写prd时不知道如何下手，具体包含哪些内容，需求细节的密度是怎样？这时一般会有自己的导师给到一份prd模板或是指导新人如何去写一份合格的prd。那好的一份prd文档应该是怎样的呢？我曾看过一句形容令研发满意的prd：优秀的prd文档应该是像伪代码一样。prd文档主要包含项目背景、项目预期、统计需求、方案描述。
项目背景是为什么要做？解决什么问题？其实这是新人很容易忽略的一点，一开始写prd文档时会直接开始画原型并在评审会时直接开始向相关人员介绍原型图和需求描述。这样就会让项目相关人员很难理解为什么是这样设计的，并提出各种质疑。有时候项目背景一句话就能表达清楚，看似简单的一句话可以减少研发的很多误会，减少沟通时间和理解成本。此外prd中还需要说明项目预期，即有哪些需求点从而能有怎样的预期效果。主要有两方面，一是指标项，二是指标值，指标项又分为核心指标项和辅助指标项，比如之前跟着导师做的一个付费练习需求核心指标项就是提高付费练习收入，辅助指标项是提高新用户订购率和老用户的复购率。指标值是日收入提高多少？订购率和复购率在原有基础上提高多少个点？统计需求也是很容易被忽略的一个点，它是指打点统计，我们在上线一个功能后通过埋点统计用户的行为，比如页面的pv、uv，按钮的点击次数，页面停留时长等，既作为功能上线后的效果验证，也可以通过数据分析做之后的功能优化。
方案描述是指要做哪些功能？页面功能是怎样的？逻辑和策略是怎样的？这一部分是prd的核心，也是作为新人最头疼的一点，主要问题包括交互图该怎么设计才合理又美观？逻辑和策略该怎么定？细节描述的密度是怎样的？新人写完prd文档给自己导师看一般暴露的问题很多经常需要多次返工修改，比如逻辑和策略不完善或混乱、交互图设计不合理等。在最开始做产品实习生的几个月，只要需求稍微复杂一些我的prd文档几乎每次都会被返工，一度怀疑自己毕业后是不是真的可以胜任产品经理这个岗位。随着之后几个月参与一个新产品从0到1的过程（一周一版的迭代），通过大量的prd撰写和产品体验自己的prd写作能力有了一定的提升。对此自己总结的几点是：1.善用图，功能需求较大时最好有流程图和思维导图，需求列表，能用交互图展示的尽量不要通过大段文字描述。2.需求细节不要遗漏，在描述页面逻辑和策略时我们很容易认为某个逻辑不用写上，研发自己知道，但实际情况是研发不会去写prd上没有的逻辑，所以在写的时候要多注意细节。3.多思考需求背后的逻辑做到关联性思考，比如做某个页面有图片时不仅要考虑图片的尺寸大小，还要想到图片未加载出来时候的loading图。
prd文档撰写前要收集需求分析需求，上面有写这里不再赘述，在分析需求后如果是较大的需求在评审前需要进行可行性预沟通和方案考量，即叫上各位置核心的人员一起讨论方案。比如最近我做的一个社区改版项目，在正式评审前叫上自己的导师、运营负责人、技术负责人、交互设计师一起针对社区改版的需求进行可行性预沟通和初版方案考量。集中讨论方案的可行性、成本、是否最优等问题。在正式的需求评审前pm需要将自己的prd文档至少提前一天同步给所有相关人员，保证在评审前他们看过prd并能在评审会上指出文档上待讨论的点。
需求评审会其实是很多新人最怕的会议，因为每次评审都免不了被研发喷，被质疑的都要怀疑人生。除了自己prd文档逻辑不够清晰和细节描述不完整以外，在需求评审会上也有几点需要注意的地方。首先是评审时一定要先交代背景，即为什么要做这个需求，否则一上来就直接讲需求肯定会直接被研发打断。其次陈述需求和页面逻辑时一定要面面俱到，不要放过一个细节，之前我就犯过类似错误，prd上写着进入帖子详情页再退出该条帖子置灰表示用户已读，但评审时没说出来等到开发完我指出这个我prd上写的功能为什么没做，rd很强势的扔下一句你评审时并没有没提到，这时候提出来就属于加需求了，我没时间。最后某些细节有争议点如果只涉及某个岗位就私下里再讨论，不宜在评审会上争论，有些时候需求评审会开几个小时，一方面是在会议上pm和某位研发一直争论某一逻辑细节浪费相关人员时间，另一方面评审时容易偏离主题，甚至会和研发等聊起来。这样导致效率很低。评审时有修改或争议的点pm都需要及时记录下来，并在会后修改确定下来并同步给所有相关人员，否则之后项目推动过程中会带来很大的沟通成本。
<产品设计>
产品设计的一般流程是需求分析、产品定义、受益预估、产品设计、推进落地。这一流程里有很多前面已经具体提到了，比如需求分析、推进落地等。这里主要想分享自己在产品设计过程中的感受，首先是目标拆解，对于新人而言需求来源可能更多的是自己导师提给自己的，这时候的需求点都比较具象，即明确知道为什么要做这个功能，需求是什么，而新人只需要进行产品设计和推进落地即可。当自己真的开始独立负责某个模块时目标拆解就变得尤为重要，而目标一般都是定量和定性的，比如接下来需要提高日活和留存，日活提高几个点留存率提高多少，根据预期收益去拆解目标，通过哪些功能设计满足用户需求进而实现数据提升。在产品设计时根据预期收益去拆解目标会让需求更完整，也更容易确定需求的优先级。此外在产品设计时我们要先保证给用户一辆自行车，满足基本需求随着迭代从自行车换成电动车再换成轿车，带来更好的用户体验，而绝不是一开始就想着给用户轿车，先从轮子造起，再搭建车身最后把造出一辆完整的轿车。
其他想说的
态度决定一切，all in一切
少说多做，切忌心态浮躁
保持好奇心
真正做到深度思考
不要完全相信qa
待提升的几点
随着项目经验的积累，不断犯错和背锅中，在某些产品能力和技能上已经有了较大提升。但目前而言仍有一些急需提升的点：
1.需求分析能力，这是一个长期积累和提升的地方，对于用户、需求、场景的理解和人性的洞察需要伴随着其他知识（心理学、经济学、逻辑思维）的沉淀和工作经验的积累逐步提升，平时需要多看书多思考。
2.产品感，是基于产品经理对产品的熟悉与理解，在大量把玩产品并深度分析产品之后，在脑中储存足够多的相应场景，并在产品工作中遇到相应的问题时能随时调用来解决问题的一种熟练表现。在面试时回答场景类问题时总不理想的原因就在此，工作之余除了要经常体验工作相关的竞品也需要深度体验和分析某一类产品集合，解读产品的背后逻辑和不足并能给出自己的解决思路。
3.逻辑思维能力，工作和生活中都很依赖的一种能力，也是自己长期欠缺的。在平时思考想问题时要做到关联性思考。
4.数据分析能力，新人阶段工作上接触的数据信息也很少，但随着工作深入数据分析变得必不可少。
5.性格和情绪瓶颈，性格和情绪就像底层的操作系统，决定你能走多远。之前尤其在性格方面对于做产品而言很吃亏也很致命，需要让自己的性格变得自我变得强势，情绪上也要更加沉稳和恬静。
上面五点很大程度上决定了自己的产品高度和能力，其他方面的能力都会随着工作经验的积累和他人差距不大，而真正衡量一名优秀产品经理的核心指标就是目前自己所不足的地方。
<交流也是一种输入和输出，希望可以和有意愿的人多交流（v：a958189341）>
网友评论