篇一:《产品经理试用期总结》
尊敬的公司领导
本人于201X年X月X日加入公司，任X产品经理一职。主要工作职责为引导开展市场活动，提供学术支持，解决产品市场推广过程中的问题，规划产品长期发展方向等。
加入公司之后，我进行了XXXXXXXXXXXX工作。
在工作的半年时间中，无论是公司流程的介绍还是核心工作的指导，我都从领导和同事们身上得到了非常大的帮忙。对于我个人在市场领域的发展，奠定了基础，让我更有信心来完成产品经理工作。
因为对于产品经理一职，我自己的理解是作为产品的灵魂，需要确保产品的有一个概念，以XXX为例，XXXX就是一个很好的概念，产品经理首先需要丰富这个概念，再设计一些项目来包装宣传这个概念，将项目结合到客户的需求点上，最后监督指导项目的落地开展，产品经理的工作核心不仅是执行，更重在思考。所以在未来市场部的活动，具体事项要放手由一线区域同事来执行，由产品经理提供相应的学术支持。但在现实中，以往的活动大家更多的去注重会议的会务质量，而忽略了学术质量，两者的不平衡导致了公司资源的浪费、人员时间的浪费、甚至对品牌的破坏。对此，我也更加有紧迫感和使命感，时刻提醒自己有责任在这个岗位上把XXXX的学术内容丰富起来，并且更多的给予区域学术负责人，在执行XXX相关会议时以帮助和指导。
半年工作汇总我也发现了自身的不足之处市场工作需要严谨的态度以及严格的时间管理，在今后工作中我也将更加关注这些问题。
以上为试用期有感而言，最后再次感谢领导和同事们对我的信任和帮助。
XXXXXXX 2014年12月9日
篇二:《一线产品经理的工作感想》
一线产品经理的工作感想
只是个人的工作心得和所思所想，信马由缰一通，做产品的人能大致看得懂就行了。
没啥铺垫的，直入正题，一块块来先上一张图
需求文档看不看
当你辛辛苦苦写出来一堆需求文档，跟UED的同学定好交互、视觉、重构;满以为技术会认真对待，但是你会发现，技术同学基本不会看你准备的一堆东西，基本是按照自己的理解来开发，当开发不下去，第一时间也不是看文档，而是看测试用例，或者直接跟产品沟通;基本文档只是QA同学对着写用例。
刚刚开始工作的时候，对于技术不按照文档开发，是比较着急上火的，经历一段时间后，发现重点就好了。产品的本质是保证产品核心功能的质量，保障用户体验，用户端和商户端的功能不能含糊;运营后台、客服后台之类的，保障功能完整和业务流畅的基础上，可以给技术适当的自由发挥;就算是前台页面，多听听技术的意见，让技术同学参与进来;开发过程中，保持沟通，对于技术提出的问题，最快速度的响应。
什么样的需求要写文档?对于功能性、涉及业务流转，状态切换，边界条件灰常多的需求，流程图、交互、PRD一个都不能少;对于非功能性的需求，提升用户体验的部分，文档可以不准备，准备好原型图，然后在上面标注出重点，交付的时候讲清楚。
todolist与优先级
产品在迭代过程中，不断有新的需求，不断有需求被完成，通过list来管理这些需求，整理的过程也是对产品思考的过程，不停问自己，这个需求用户是谁，解决什么问题，是否必要，以及是否必要现在就做?
list的好处就是，可以尽量多的记录所有需求，虽然有些天生就是被砍的命，但是list一堆需要完成的事情，对整个项目组都会有紧迫感;一句话讲清楚每个需求，标明优先级，负责人，对应的开发，开始时间，完成时间，完成状态，让项目组所有人(包括老板)，都知道我们现在有多少事情在做，已完成来多少，接下来做什么。
需求永远做不完，对于优先级安排，平时工作中最常用的就是四象限法，重要又紧急，重要不紧急，紧急不重要，不紧急也不重要，根据项目实际来做判断。
需求会议
2014年都是一周一次迭代，每周都会有下次迭代的需求会议，并不是真正意义上的需求评审，产品驱动的公司，基本就是需求讲解，交付，以及相关时间点确认
需求准备要充分
在需求会议上，面对技术和QA，甚至老大们的挑战，这是正常的，他们会问为啥要这么做，为啥不那么做，甚至直接对你的需求提出挑战这个东西不靠谱，不可能;拍桌子打板凳的事情也时有发生;唯一避免发生的情况，就是对于需求的准备要充分;不管面对何种挑战，讲清楚数据、用户需要、和竞争对手怎么做的，基本就能说服;一般只要保持平和的心态，不会有大问题。
真有自己无法立即解答的，快速承认错误不好意思，这个是我没有准备好，会后我再去做详细调研和准备，快速跳过这个问题，继续下面有把握的内容;会后再去完整论证，并把问题描述清楚，邮件给大家;既可以避免冲突，会后大家平和心态来对待，也便于解决。
讲好我的故事
这里应该是讲好用户的故事，为啥叫讲好我的故事，因为产品需要把自己代入到各个角色中;做过几次用户访谈，很多用户描述这样一个场景，我快下班了，拿出点评App搜索附近找吃的;运营说这个这个很烦，我需要这么这么做，其实可以这样就解决了;
客服说，这个信息在这里查，那个信息在另外一个页面，每条记录处理的时间增加多少分钟;
最有意思的是商户端，商户那边有签合同的、店长、负责人、前台、收银，会计，每个人都有可能来用我们的后台，去商户端做访谈的时候，观察他们如何使用点评的产品;
讲需求的时候，先描述用户遇到的困境，绘声绘色，动人心弦;如何做到，代入自己的角色，不要假装用过，而是自己真正使用过程中的痛点，放大再放大，感情方式来打动技术。
描述痛点只是第一步，可以清楚描述，如果这个需求做来，运营效率可以提升多少，节约多少成本，最终转化率预计提高多少，以及ROI(投入产出比)，所有功能点的改进，最后都可以结算为Money，因为钱，会让所有人兴奋，并集中精力来解决问题。
让更多的人参与需求讨论
需求被挑战，会有点不舒服;但是若所有人都表现出对你的需求漠不关心，那才是最难受的。如何让技术更多的参与需求讨论首先可以挖掘对业务有兴趣的人，多跟他们聊，他们会主动告知他们的想法。一般工作几年的技术比刚刚工作的童鞋更关心;其次让技术有存在感，定时告知他们相关的产品数据，月用户数，月增长量，收入等，根据技术所开发的功能点，细化到此功能带来的数据，以及同比环比数据;最后在Scrum中，计划扑克能够让所有人都参与到需求当中，因为每个人都要评估task的工作量，目前来看，效果还不错。
确定好时间点和相关责任人
Scrum确实是一个好的方式，能够估算出工作量，并且技术自发领取任务，直至每个人工作内容都填充满整个sprint。
在未开始Scrum之前，每周一次需求会议，只是交付好相关需求，由开发主管来指派任务，并定好工作计划表，然后QA同学补充相关测试安排，最后敲定上线时间。
其实不管何种方式，最终的结果导向就是，产品尽快上线，且以最有效、风险最小的方式。
适当地砍需求
产品是不需要懂技术，但是如果能根据需求大致预估工作量，排期更简单;每次我都会提前多准备一些，连交互和重构都准备好，摆出一副不做此需求是誓不罢休的架势;资源充分时，技术童鞋会主动领取需求的，但是当工作都排的比较满的时候，就很难了;所以需求评审时，每个需求的优先级都排的高高的，将用户痛点描述的栩栩如生，如果技术实在抱怨太多，或是总拿51230.com那样的婚恋网站来举例，那就象征性地砍掉一部分，前提是保证核心必须完成，其实当时砍掉一部分，不会一直砍下去，而且心里也会有满足感;其次给技术紧迫感，赶紧完成，后面还有一堆事情呢，即使这次迭代不做，下次迭代也需要完成。
产品开发过程中
保持沟通
在产品开发过程中，技术都是非常有责任心的，会帮你考虑边界条件，作为产品积极响应技术提出来的各种疑问，是维系技术与产品之间很有效的方式。虽然有一些问题，可能是技术对需求的理解并没有产品那么深刻，讲清楚就好了，没有必要上纲上线，因为最终大家的目的都是为了产品，另外公司开始实践的Scrum也对整个团队保持沟通，既是要求，更要成为一种习惯。
认真对待测试用例
测试用例，又是一个保证产品质量的利器;刚开始工作的时候，认为测试用例只是QA同学的工作，第一版本App上线做UAT的时候，发现对着需求文档并不能完整验证完所有需求，但是对着测试用例，所有的主流程，辅助流程，边界条件，非功能性需求，清晰明了，感觉太有用了。所以每次都提前完成需求文档交付QA，QA在技术正式进入研发完成用例文档;在过测试用例时，产品同时参与，避免一些需求理解上的偏差，此外技术同学对着case开发，比需求文档描述更清晰，另外技术同学可以参与部分自测;UAT的时候，也是产品的参考。
需求变更与delay
需求变更是永恒的话题，Scrum中一般是不接受需求变更，其实不允许变更的本质不是需求定板不动，而是对产品提出了更好的要求，从需求调研、准备、设计、交付每一步都需要考虑周全和清楚;即使在要求严格的Scrum中，需求真的不能变更么?如果临时线上bug造成用户无法访问，技术同学是不是要停下手中工作，来排查线上故障呢。作为一个产品，不
是神，尽量保证所有的需求都是合理且必要，并且将所有的需求准备工作做到位;如果还不能避免，就要影响甚至说服整个团队来拥抱变化。
正确处理需求变更
需求变更已经发生，那就赶紧处理吧。如果是产品没考虑清楚，用户调研或者数据支持出错，果断向团队承认自己的错误，没有人会责怪一个真心诚意道歉的人;并在第一时间交付变更后的需求文档、交互、视觉、重构等，并跟技术沟通如何以最小的代价，完成此次实现;若技术的工作在本次迭代已经安排很满，那考虑需求的紧急程度，适当情况下，可以放到下个迭代去完成。
若是因为行业或者市场变动，产品转型等原因，直接向团队传达变更的原因，以及接下来的产品规划，让所有人都看到一个清晰明确的目标，技术会有疑问和挑战，耐心解答，通过行业数据、竞品等角度去阐述;遇到老板变更需求，那比较简单，因为老板的需求优先级永远是最高的，但是作为跟技术直接沟通的产品，要认真对待老板变更的部分，若老板频繁变更需求，烦的是技术，会不会以后合作留下影响呢。
关于产品delay
不管产品还是技术，没有人愿意看到delay的;面对delay，怎么处理?换个思路就算delay了，只要用户还能用，服务照样跑，地球还照样转。如果真的导致用户不能访问，整个技术团队肯定加班加点，不吃不喝也会搞好的。一旦出现delay，整个团队一起来排查delay原因，是需求变更，还是资源没到位，还是项目之间的耦合关系，前面小的改动，导致后面项目的延期，做好每次的总结会议，并在下一个迭代中避免此问题。
目前团队中正慢慢引入Scrum敏捷开发，而本篇总结，大部分是基于小瀑布模式的迭代;需要学习的还有很多，一转眼又过了两个月，正式工作已经八个月，需要走的路还有很多，跟随整个team一起成长。
算是工作总结吧，主要是自己梳理一下，路还长，继续跟着一班牛人加油呗！
篇三:《产品经理试用期总结》
尊敬的公司领导
本人于201x年x月x日加入公司，任x产品经理一职。主要工作职责为引导开展市场活动，提供学术支持，解决产品市场推广过程中的问题，规划产品长期发展方向等。
加入公司之后，我进行了xxxxxxxxxxxx工作。
在工作的半年时间中，无论是公司流程的介绍还是核心工作的指导，我都从领导和同事们身上得到了非常大的帮忙。对于我个人在市场领域的发展，奠定了基础，让我更有信心来完成产品经理工作。
因为对于产品经理一职，我自己的理解是作为产品的灵魂，需要确保产品的有一个概念，以xxx为例，xxxx就是一个很好的概念，产品经理首先需要丰富这个概念，再设计一些项目来包装宣传这个概念，将项目结合到客户的需求点上，最后监督指导项目的落地开展，产品经理的工作核心不仅是执行，更重在思考。所以在未来市场部的活动，具体事项要放手由一线区域同事来执行，由产品经理提供相应的学术支持。但在现实中，以往的活动大家更多的去注重会议的会务质量，而忽略了学术质量，两者的不平衡导致了公司资源的浪费、人员时间的浪费、甚至对品牌的破坏。对此，我也更加有紧迫感和使命感，时刻提醒自己有责任在这个岗位上把xxxx的学术内容丰富起来，并且更多的给予区域学术负责人，在执行xxx相关会议时以帮助和指导。
半年工作汇总我也发现了自身的不足之处市场工作需要严谨的态度以及严格的时间管理，在今后工作中我也将更加关注这些问题。以上为试用期有感而言，最后再次感谢领导和同事们对我的信任和帮助。
xxxxxxx 2014年12月9日
篇四:《产品经理技能要求与评价》
PM能力要求概述
（一）概述
完成特定的产品工作，需要特定的能力组合和层级。职称就是这个能力组合与层级的反映。我们对典型的PM工作职责内容描述如下
1．完成完整的产品任务。包括如下内容
发现问题——>分析问题——>决策判断——>提出方案——>落实方案——>评估效果 不管是对内的产品设计/改良工作，还是对外的合作沟通，循环都是相似的。只是方案的设计和落实方式，会有差异。
2．负责完整的产品方向。包括如下内容
产品/运营规划（目标制定，任务分解，优先级安排等），为完成产品目标必要的人员规划和培训，工作方法梳理，协调资源和人力推动产品目标的达成。
(二)构成
（注本文中所提到的“问题”有两种情况。一种是现有产品、策略中存在缺陷，导致用户需求满足不好；另一种是存在某种需求，而我们尚无相应的产品或者功能去满足。）
问题发现能力
问题发现的衡量，既体现在数量上，也体现在对各类具体case背后，用户体验影响一致性的抽象上。
个人提交的问题报告（含邮件、正式报告等）以及需求提案（含邮件、正式报告等），会被列入问题发现能力的考察材料范畴。而被采纳的报告和提案，则是其中的关键。
2．问题分析能力
问题分析，是指对问题的本质、分布、影响和走势的探究。能力的衡量，体现在分析过程的严谨程度，以及结论的合理程度上。
个人提交的调研报告，分析报告，评估报告等，会被列入问题分析能力的考察材料范畴。
竞争分析能力
竞争分析是指对影响产品发展和成败的外界因素（包括直接竞争对手、上下游产业链、政策与环境等）进行分析，目的是剖析清楚这些外在因素对产品的影响模式、影响程度。
个人提交的竞品分析报告，行业发展趋势分析报告等，会被列入竞争分析能力的考察材料范畴。
决策判断能力
该能力指进行问题分析、竞争分析之后，结合本产品的价值和目标、以及企业的目标和规划，给出合适的行动方案思路，或者对他人的方案进行合适与否的判断的能力。
决策判断能力会体现在调研和分析报告中（做不做，上不上线，为什么等），也体现在优先级判断中（何时做）。
方案设计能力
不同类的产品工作，设计的表现会有不同。偏应用的产品/功能设计、偏运营的运营方案设计、偏策略的理想模型设计等，都属于设计实现的范畴内。这里的方案不是指技术方案。
个人提交的MRD，活动策略方案，策略思路方案等，会被列入设计能力的考察材料范畴。已上线工作所体现的设计水准，会被作为方案设计能力的佐证。{对产品经理的转正评价}.
产品和运营规划能力
规划是指阶段性的产品目标确定，以及为达成目标，将目标分解成若干可实施任务的能力。在某个阶段内，对某个方向进行关键问题的定位，并确定该阶段的工作方向，也是工作规划之列。
个人提交的阶段性工作规划和执行状况汇报等，会被列入产品规划能力的考察材料范畴。
工作推动能力
大多数的产品工作需要协作解决。所谓推动能力是指对一个问题跟进到底，调用一切可调用之资源，推动问题最终落实的能力。困难总是有的，需要的是那种为达到目的、不畏麻烦的推动力。
上级和协作团队的评价，会是主要的考察材料。
表达沟通能力{对产品经理的转正评价}.
这是指在利益共同体范围内的表达和沟通能力。
各种总结、培训场合的主题发言，各类分析报告、设计文档，都是表达沟通能力的考察材料范畴。协作团队的反馈，也会是重要的参考依据。
指导能力
为低阶的PM提供工作指导，以及个人发展规划帮助的能力。
个人的指导思路和方法，阶段性的指导计划和总结，以及被指导人的困惑和成长状态，都是
指导能力的考察依据。团队经理的意见，也会是重要的参考依据。
10.对外沟通谈判能力
指和非利益共同体沟通谈判的能力。
以上不包括“素质”。素质不在职称考察范围内。道德水准、文化认同等，都属于绩效考察范畴。
三、PM能力的衡量
能力主要通过两个方式来衡量综合工作表现和工作成果。
综合工作表现是指一个员工在日常工作细节中所表现出的业绩水准。
工作成果是指主要由该员工的个人贡献而所得的阶段性或最终成果。这是最主要的能力衡量手段。在产品循环的不同阶段，会产生不同的成果，并能反映不同的能力。
对于每个职称的申请，都需要提交相应的工作成果（书面材料或者口头阐述）。例如，为了证实自己在问题分析方面的能力，就需要提交相应的需求/问题分析报告。
指导力度
完成任务所体现的能力，除了受到自身能力高低影响之外，还受到指导力度的影响。受到的指导力度越大，则能力要求越低。
指导力度分三级
第一级指导人告知做什么，并且告知怎么做，在实施过程中随时进行教导（Coach）； 第二级指导人告知做什么，但怎么做需要被指导者自己思考；
第三级指导人只是指出一些目标方向，被指导人自己想明白要做什么和怎么做。
在一级指导下完成任务，就能力而言并不胜任。完成该任务，