背景介绍：坐标上海，计算机专业大四学生，17年6月起在电商行业（D轮人数700+）当产品经理实习生，时长7个月。和另一位资深PM共同负责B2C微信商城的产品工作，有幸得到认可，深度参与产品全流程，负责了10余次产品迭代的落地，过程中通过大家帮助填了不少坑。
近段对工作内容作了梳理总结，相较于实习前通过网络渠道自学构建的PM理论体系，我得到了许多新的和见解，在此整理与大家分享，请教探讨，更好地在PM道上迭代自己，砥砺前行。
做总结前，首先要清楚自己做过哪些事，无论结果好坏，不要漏掉，完整的经历参考会使总结价值更准确全面。
实习初期，我用了两周时间熟悉产品和团队磨合，后在师傅带领下开始负责项目。中后期我的工作日常即为一个或数个需求线并推，就是大家常说的从0到1实现流程，具体环节如下：
每天的工作经历和，通过周期总结和项目复盘的形式，可以直观检验PM技能是否得当，技能具体内容不再赘述（例如AT的PM能力模型），硬实力也好软实力也罢，都是为了更好地打磨自己负责的产品而服务的。
对于初级PM而言，更加注重于执行层面，即需求的效果。通过项目的高速迭代给予需求线每个环节的反馈，不断改进有问题的环节，用更完善的PM技能体系解决后续问题，进而实现迭代。下面是我思考的一些技能点（资历尚浅不可妄称方）。
Boss的需求一般是从战略维度或者商业价值（例如承接合作方需求）考虑，结合公司利益和战略发展从宏观角度思考需求的背景和原因，想不明白就请教leader，有助于培养格局和眼界（外行拍脑袋Boss不在此列）。
针对客户，内部同事或者PM自身挖掘的需求（通过运营数据，竞品分析，或者纯脑洞），通常使用Kano模型筛选，重要紧急象限法排期，同时也要考虑开发成本和预估收益，例如C端商城页面改版优化，可一定程度增加客流率，开发周期短，优先级就高。
作为B2C产品，既要满足B端业务场景和后台易操作性，也要重视C端使用体验。故设计时需先定框架，再完善界面，最后查验原型。
原型设计完成后，分别从用户和测试角度，模拟所有流程，确保满足业务和逻辑完整，尽量避免后期来源于PM的需求改动。否则既增加了设计研发的工作量，也会降低团队对PM自身的信任，不利于后面后续工作的推进。
我在实习初期负责的项目，在的地方上都踩了很多坑，有些需求改动甚至造成返工，浪费了大家不少时间。
设计环节：原型尽量走线框图+文字说明（演示除外），速度快，逻辑清晰。按钮、字体、色系等可以与设计讨论，但浪费过多时间纠结于表现层，得不偿失。PM是服务于业务的，若产品业务性都不完整，陶醉在交互和界面问题上就没意义。业务本质搞清楚后，有空可再琢磨表现层。
研发环节：和研发的沟通是产品推动的关键，这点感触很深，除了研发评审会时把需求用流程化语言表述之外，我改进了几点方式。
将产品（主要包括需求的功能点、业务点、价值点，我理解为产品）准确传达给其他团队，需要PM站在对方立场上，用对方话术去沟通，这也是同理心运用的体现。
例如针对客服团队主讲实现功能，操作方式，方便商家售后答疑；针对运营团队，则要谈客流、复购、拉新、促活这些能给商家带来业务增长的手段，让运营推给商家和潜在客户；针对销售团队，主要内容则需要围绕产品的价值点（为什么能卖这个价钱）、较其他竞品的优势、满足哪类客户何种使用场景这三部分展开。
做到准确地推广，可谓产品想法完整的实现了，用大话讲则是这个产品迭代属于PM的意志，且有流量，有市场去检验。
东西做的好不好，用户的反馈和上线后一定周期的运营数据不会。每一次成功经验或失败教训都是耗费公司资源和团队的辛劳砸出来的，是PM无论怎样谈理论都得不到的，弥足珍贵，复盘的重要性有时甚至大于实现，所以对项目的复盘和个人的总结就尤为关键，无司是否有复盘要求，自己最好在上线一周内趁热打铁，完成此工作。
个人复盘：一般是对需求线环节的检验，一看“我的PM技能体系”哪些地方还需要“知识升级”，二看工作态度和习惯上需要完善地方，完成迭代的过程。
实习时负责100+团队的产品答疑工作，腾讯通聊天窗口每天都闪烁不停，为手上事情及时完成同时处理沟通，我采用了番茄工作法，先腾出25分钟用来专注处理问题，然后5-10分钟处理外部事务，40分钟一组循环（开会等场合除外）。论坛也有很多大牛推荐其他针对PM的时间管理方案，选择适合自己工作节奏的就好。
产品实现过程中，想尽办决每个问题，而不是草草尝试觉得无解就放弃。即使解决，思考是否有更高效的方案。PM领域需要深耕，而的动力就源自内心的热爱，有种不达目的不的“狠劲”。
从张小龙在微信公开课的讲述可以看出，微信这个工具深深地印着他的产品思维，产品体验重视到近乎偏执。但是大多数PM，为了商业价值和公司利益，会更多从性价比角度定夺，假设这个功能一定程度增加体验，但实现成本很高，基本会被砍。但这种是否一定是正确的，平衡点在哪，这里希望能得到各位前辈指导。
用户、场景、需求千千万，产品方案千千万，但构建思维是相通的，一个模块可以形成一个需求设计的轮子（例如注册模块，常用的就几种场景），轮子结合具体业务就能运行，数个轮子调整结合就是业务方案。PM在初期可以通过大量实践掌握自己的轮子库，个人感觉有点像七巧板，怎么组合地更精巧，给产品做减法，更好地服务于业务目标，是PM要持续的内功。
对于PM特别是新人而言，不能把“改变世界”的空话挂在嘴边。但是这个作为初心，作为最终目标，没有错。拆分目标为职业规划，做好执行，应付眼前的苟且的同时，也不忘诗和远方，做好实力的准备，等待机会的到来，没准真能“改变世界”。如人所言：仰望星空，脚踏实地。
老生常谈的话题，但工作中还是容易忽略。第一点，手上任务节点主动汇报，让上级知晓进度，保持信息同步。第二点，需要上级确认拍板的及时催促，上级都很忙，不及时催，耽搁的是自己任务的进度。
任务中遇到问题，自己查资料，想出清晰的方案（不是拍脑袋、凭空想的那种）A、B、C给到上级，再分别补充对每个方案的想法和依据，给出自己的选择。之后上级拍板，阐由并讨论，切忌抛给上级一堆问题。
不要一天都坐在工位上做自己的事，等别人来问。跟进手上每一个任务，主动询问进度，卡在哪个部门就及时出面，想办决（即使问题不是自己的），这样项目才能推起来。调用其他部门的资源及时告知其部门领导。
作为团队的协调者，遇到各种障碍和阻力在所难免。自认情绪管理做的不错，但有时还是会控制不住，在工位上抱怨bug多，研发延期等等。虽然当时火大，但在工作中这种消极情绪只会传染给团队，带来消极影响。所以即使有也别表现出来，将精力都投入解决问题中。
作为新手，确实更注重执行层面，但不意味着放弃对问题的上层化思考。思考做的每一个功能对用户的价值，对公司的价值，对PM的价值。有时间刷刷行业动态，思考发展战略不是中高级PM的，趁上级空闲时多请教。
途径和方法枚不胜举，重要的是阅读过他人分享的干货后，加以思考，并执行，执行的具体手段可以是运用到产品工作中，也可以写成总结文档做输出。仅仅停留在看完觉得好然后点个收藏的层面是远远不够的，吸收率很低，必须消化为自己的知识体系。
互联网行业大都敏捷原则，其实我这篇实习复盘总结也如此。由于资历尚浅，积累还远远不够，主要结合了踩过的坑，同事和领导传授的经验，认知与思考来写的，内容偏主观和片面，更像是工作笔记。而且受限篇幅，许多点没有详细举例说明。若有机会在未来接触更多高增长性的业务（俞军老师的定义），得到更系统的实战锻炼和指导，通过实践反馈—修正认知—反馈，小步快跑，才可能形成自己淬炼出来的，扎实可靠的产品方。
我觉得PM在初期的塑造挺关键的，有好的导师和业务能少走很多弯。道阻且长，希望彼此都能沉下心去思考，更好地解决问题，~