产品之路-初章
时间如同白驹过隙，日夜奔流。自毕业后正式踏上产品这条路以来，至今已满两年。回想当初定下的职业规划，第一阶段便是用两年左右的时间来打磨产品经理的基础技能，将基础做到全面而坚实，达到能够独立负责一款产品或一条产品线的能力。不觉中，第一阶段的两年之约已至，此时回顾一下两年间自己在产品这条路上的成长。悟以往之不谏，知来者之可追，总结下自己的成长是否达到预期，也为下一阶段做好计划。如果这段经历刚好能够对初入产品的同学有帮助，那则更是一大幸事。
毕业前曾在360有过一段实习经历，此处暂且不提。一来因为工作内容与互联网产品关联不大，主要为产品的售前工作；二来时间不长，还经历了出差，几乎没有接触到该产品的需求迭代，所以对自身产品路上的成长帮助有限，真正的走进这个岗位还要从毕业后的第一份工作说起。
摸爬滚打的产品助理
毕业后由于种种原因，匆匆入职了一家做互联网金融的小公司，开始了产品的生涯。此时的岗位是产品助理，协助项目负责人（公司经理）做一些产品相关的工作，在职期间主要负责了APP部分功能模块以及运营后台的设计，还有一些杂七杂八的工作。这段时间的主要学习渠道是几本入门的书籍和一些产品社区，从这些内容中我大体掌握了产品经理的工作内容及工作流程，可以用Axure进行简单的原型绘制，输出结构僵硬但勉强可用的需求文档。
开始工作后，终于结束了之前的纸上谈兵，但此时的状态可谓懵懵懂懂，决心上满腔热血，实力上乏善可陈，业务能力上仅仅是产品助理中的初级水平。苦于没有人带，只依靠自身野蛮成长，也是吃了不少苦头，这时最大的困扰就是如何成长。自学并非不可行，但对于产品这个岗位来说不免有些艰难。一想到在其他大厂有导师引领和完善成长体系下的同龄产品，不免心急如焚。重重压力下，我只能从现有的渠道发力，几乎看完了知乎、人人都是产品经理社区中所有关于产品新人的文章，每天还会持续关注更新的文章，希望能从中学到有价值的东西。但看得多了，越发觉得千篇一律，纸上得来终觉浅，绝知此事要躬行，但公司却并不侧重产品研发，流程混乱且没有半点互联网气息，因此实践机会也少的可怜。在职六个月后，薪资上一些较为恶劣的问题成为了最后一根稻草，我忍无可忍，选择辞职。这半年的经历促成了我找下一份工作的两个必要条件：一是要有人带，二是一家以产品为主的互联网公司。因为我觉得毕业前后的一两年时间，是成长最为快速的塑型期，要抓紧时间打好基础，否则在这个迭代极快的行业不进则退，会被远远的甩在后面。
第二份工作就职于某教育集团旗下的一家子公司，主要产品是一款背单词APP。此时的岗位仍是产品助理，协助产品经理做一些功能设计相关的工作。对于渴求指导，渴望实践的我来说，这次的工作可以说是完美契合，既有经验丰富的产品经理带领，又是主要在做一款C端的互联网产品，即使由于种种原因工作近半年后离职，但这段时间仍是我成长最快的几个月，也是我产品路上的宝贵财富。正是这段经历，让我从只能做一些偏执行工作的产品助理，逐步成长为能独立负责需求的产品助理，向产品经理迈向了坚实的一步。
这次在职期间主要负责了该APP部分功能的前后台需求分析设计、竞品跟踪分析以及用户调研、反馈等，对我来说可谓成长巨大，主要体现在以下几方面：
1.接触到了互联网公司产品经理的完整工作流程及职责范围
完整的工作流程体现在做需求时所进行的需求挖掘、用户调研、竞品及需求分析、设计成果输出、规划排期、跟进研发进度、上线前后准备、收集用户反馈、数据统计分析、总结复盘及迭代优化等。职责范围包括组织需求评审，需求复盘等会议，跨部门沟通协调，申请、调度各部门资源等，并要对最终的结果负责。此时上述各个方面虽然都只是简单的涉及，但让我对产品经理这个岗位有了更加全面的认知，不再停留于书籍或文章里面的描述，而是切身的感受到了产品经理的价值——不仅在于设计功能或产品，也在于对整个项目推动，跟进，把控及整合。就像做一件衣服，各部门是一块块布料，产品不仅仅要按照自己的设计裁剪，更要穿针引线的把各个部分缝合到一起，并负责好售后服务。
2.强化了对自身输出内容的认识和规范
对输出内容的认识体现在文档、原型等的撰写上，不再僵硬的依照网上或部门的模板来填充，意识到了原型、文档等结构及每一部分内容的价值所在，有的放矢的给各部门输出合适的内容，提高阅读流畅度和沟通效率。对输出内容的规范则归功于前辈严谨凌厉的要求，让我更加注重每一个细节，从小事做起，一丝不苟的面对、尊重自己的工作内容。
3.建立了以数据为导向来做需求的思维方式
作为初级产品，感性并非不可取，但理性则更为可取。在成为乔布斯或张小龙之前，你的感性很难说服你的领导和研发人员，所以你需要用数据说话（从中汲取的教训，让我至今对做C端产品仍留有阴影）。无论是对于需求的分析、复盘，还是对于功能迭代优化方向的判断，数据无疑是具有极大指导意义的，这也为当时刚入行的我开启了一扇大门，开始关注起了如何埋点，做好数据统计分析，从其中找到当前的不足之处加以优化，然后再通过观察数据进行验证，周而复始，乐此不疲。但可惜的是最后负责的功能迭代，本是APP转化率很低的一个环节，上线时满是期待的我并没有能看到上线后的数据，就无奈离职了。言归正传，这让我知道了数据统计及分析对于一款产品迭代方向的重大指导意义，也是认识、了解一款产品最基本的要素。
4.建立了基本的工作习惯
这里包括的内容就很多了，如何管理时间，安排工作内容，提高工作效率等，但让我印象最深刻的就是一定要及时和各方面沟通进展，尤其是上级。入职初期，对于一些较为明确的工作，我还是能够很好的执行，但是一旦负责定义较为宽泛的工作时，往往不能明确主要目的，做了很久和上级沟通时才发现做错了方向，之前的努力自然没有任何意义，虽然其中也会有种种原因，但如果能够及时的与有关人员进行沟通，则会极大程度上的避免这种问题的发生，及时纠正方向。所以在工作中的任何一个阶段，及时的沟通、汇报来同步信息都是重中之重，切不可省。
精进“产品”，初窥“经理”
此时推开了产品大门的我，更加意识到了自己在各个方面的不足，决心尽快弥补。考虑良久后，在某产品经理教育平台上咬牙买了一期课程，更加全面系统的学习了相关的知识，并利用课后练习加以实践。由于时间紧任务重，在这次课程结束后的整体评选中也只是勉勉强强及格，没拿到优秀也有点小遗憾。不过这次的学习也算收获颇丰，让我将之前野蛮成长得来的经验梳理一番，查漏补缺的同时，也有机会把此前没涉及到的部分加以练习，例如各种方式的用户调研，建立用户画像等。
随后，由于机缘巧合，进入了如今的公司，做起了B端的产品。在适应了由C端转为B端的水土不服后，也开始肩负起了更大的责任。入职到如今的半年多时间里，从负责系统中各方面零散需求的支持，到负责整个功能模块的设计，再到如今独立负责二款APP及相关crm系统的搭建，一路走来，感触良多。更大的责任意味着需要更大的能力，也使我逐渐领悟到了“产品经理”这四个字的含义——其一为产品，主要为产品设计相关的能力；其二为经理，要能在管理和业务的层面上，给自己及团队明确目标，做好规划。
此时回顾，这期间较为明显的成长主要为下几方面：
1.强化了逻辑思维的能力
不同于C端产品面向用户的简洁明了，B端产品面向业务时往往有着极为复杂冗长的业务流程。多角色的协同合作、高耦合的业务流程、极复杂的应用场景，环环相扣，咄咄逼人，初次涉足很容易导致设计出的产品漏洞百出，逻辑混乱，难以投入使用。但B端产品的优点同样明显，不同于C端对用户心理及行为的反复琢磨和模棱两可，B端的需求和场景往往很明确的摆在那里，要只要你肯耐心去拆解，就会慢慢理出头绪。所以若想强化设计产品时的逻辑思维能力，首先要做的就是深入去了解业务，这也是一切逻辑的基础（有条件的可以定期轮岗体验，否则就需要与业务方多多沟通交流）。对业务有足够的了解后，才能对整体流程及细节有所把握，避免在无意义的问题上浪费时间和精力。其次要做的就是角色扮演，依次站在涉及到的各个角色的角度，去还原完整的业务流程，尽可能的罗列所有会发生情况，然后补充各种情况下的流程走向和数据变化，再将其合并到主流程上。最后要做的就是保持耐心，反复推演确认。这一点说起来最简单，执行起来却很难，往往一个很复杂的功能设计好后，再多看一眼都觉得恶心，但是实际经历告诉我，越是复杂到让你恶心的设计，就越有存在隐患的可能。只有从各种角度反复不断的推敲，直到让自己看到设计方案如同庖丁解牛一般清晰明朗，胸有成竹的时候，才算暂时告一段落。对于上述方法从领悟到执行，让我感觉到了自己设计方案相较之前日趋缜密和完善的同时，逻辑思维能力也逐步有了些提升。
2.突破时间管理的瓶颈
最初我并没有意识到时间管理会成为我的一个瓶颈，以为只要每天把需要做的事情排列出来，区分好优先级，时间规划就会水到渠成。例如之前对自己的工作安排大概就是：上午时间较为琐碎，用来处理一些思维长度较短的事情。到公司后，先参加一个简短的早会，了解各部门进度和目前存在的问题，然后看一看目前关注的数据走向是否有异常，如果有，则记录下异常稍后分析。最后再处理和跟进用户反馈，了解用户日常遇到的问题并收集需求；下午时间较为完整，用来处理一些思维长度较长的事情。通常会先进行一些会议，如需求沟通，需求评审等。处理完会议后，进行原型或文档的输出；晚上时间可长可短，任务紧急时加班处理未完成的工作，不紧急时简单总结回顾当天的工作成果，查漏补缺。
量变引起质变，当负责任务较少时上述方案适用，但当负责多项目的支持时，则有些捉襟见肘。越来越长的待办list和四面八方涌来的需求会逐渐瓦解你的计划，打乱你的节奏，致使工作中容易顾此失彼，手忙脚乱。挣扎了一段时间后，在时间的管理上不得已换成了另一种解决方案，现在回想起来有点类似于操作系统处理多任务时，CPU与时间片的工作原理。工作中的待办list可以看做操作系统中的多任务，人相当于CPU，对不同项目分配的时间相当于时间片。通俗的来讲就是，首先将任务按照不同的项目进行区分，当多项目需要同时进行时，就需要依照优先级分配不同的时间，然后进行轮转处理。如果在时间段内没有完成，则暂停下来处理其他事情（紧急情况除外），如果在时间段内结束或者阻塞，则立即切换到下一任务；这样一来，就能基本保证各个项目有条不紊的按照计划推进，同时使个人时间得到充分的利用，避免了事情过多但做起来却毫无头绪的处境。
3.初识项目管理
PM这个缩写，既可以表示Product Manager（产品经理），也可以表示Project Manager （项目经理），这似乎就在预示着产品经理和项目经理之前千丝万缕的联系，在实际工作中也确实如此。在当前大多数公司中，产品经理大多肩负着一部分项目经理的职责，例如项目的时间管控、可行性分析等，由于产品经理往往没有或者有着较浅的技术背景，而上述两点的确定又需要较强的技术能力，因此在这方面常常做的不太好，尤其是在需求发生变更且时间又紧迫时。这往往是引发产品与技术之间矛盾最大的原因之一，但这个问题也并不是没有办法解决的，通常可以在团队内部沟通，将项目管理的工作移交给技术leader，这里的前提是其必须要对业务有深刻的理解，知道哪些功能应该做，哪些功能不需要现在就实现，这样才能结合业务需求与产品方案，根据自身的研发资源来规划排期。
但如果产品必须要承担起部分项目管理的职责时，又该怎么办呢？个人认为此时需要做好以下几点：首先，要交代清楚本次需求的背景，例如业务方遇到了什么样的问题，产品给出了什么样的方案支持，要达到什么样的效果，实现后有多大的价值等等，和大家一一讲清楚，让团队有共同的目标，这样中途发生任何计划外事情影响需求或者开发进度时，大家讨论起来会比较容易沟通，都有一个共同的思考和努力的方向；其次，是要保持和开发团队定期的沟通交流，一来了解项目进度，二来进行适当的推进，避免开发流程卡在某一环节无人推动的情况；第三，有必要的话，帮助技术做好时间管理，当一个技术团队同时负责多个项目时，很可能不太清楚每个需求具体的优先级，这时候就需要产品帮忙梳理，来提高开发的时间价值；最后，当遇到某些意外情况而导致项目无法按时交付时，应该先与业务方充分沟通说明情况，然后结合目前现有的开发资源和项目进度，讨论并调整方案，在约定好的排期内给出尽可能多的支持，后续再进行补充和完善。切记要避免为了保持项目的完整性一味的delay，或急于求成的上线残次品给后面挖坑的情况，这样一来则会导致业务部门对产品研发团队的风险管理能力失去信任，对团队配合有着很不利的影响。
4.B端业务需求收集
由于B端产品往往需求明确，用户群体集中，所以需求收集起来也较为清晰，但清晰不代表正确，也不代表简单，反而会更具迷惑性。因为当某种需求被异口同声的传达出来时，往往会让人放松警惕，认为这就是合理的，是业务方需要的，是有着明显效果的。但事实上，业务方普遍没有或者有着不够成熟的产品思维，看待需求的角度片面单一，往往都是从自身的角度和利益出发，难以从产品整体的范畴上考虑。但这也正常，毕竟术业有专攻，如果人人都有着专业的产品思维，那么我们也就没饭吃了。言归正传，相比之下，反而是C端产品众说纷纭的需求收集，能让人更加深入和慎重的思考。因此，对于B端需求的收集，用户反馈是一方面，更重要的是要深度的了解业务，体验业务，从全局的角度出发来分析问题，明确要达成的目的。因为需求的设计并不只是为了满足业务部门自身的利益需求（例如提高人效，减少操作等），更要从公司整体的利益出发，明确需求要达成的指标对大局来将有何价值，这将直接决定需求有没有必要做及优先级如何。
来者可追
经过上述一番总结，感觉自己勉强达到了这一阶段的目标，能够完成独立分配较为明确的任务，但各方面仍亟待精进。下一阶段初步预计将是3-5年的时间，让自己成长到经理或总监级别，不再仅仅是完成任务，而是能够从业务整体的层面出发，协调配置资源，来完成核心指标。因此，在有了一定产品专业技能的前提下，下一步要做的就是着眼于更为垂直的业务领域。如果说产品的专业技能是带有必要性和普适性的职业广度，那么对于业务的理解程度就是进阶所必要的职业深度，二者相辅相成，缺一不可，一款产品如果缺少前者，功能将晦涩生硬，难以使用，如果缺少后者，功能如空中楼阁，难有价值。
成长路上，道阻且艰，愿自己能够踏实努力，不忘初心，不断成长；愿产品经理们心怀理想，让这个世界变得更好；愿产品思维不断完善，普及世人；愿世界不再需要产品经理。
