仅从个人的理解和最近2年我干的事情上面，来写点我的心得。
2011年，领导找到我，说新的项目经理完全达不到他对这个职位的期待，1年多的时间几个上线产品在公司内部完全无法实施，逻辑不清楚，需求不明确，产品不完美，用户不满意，实施不下去。他说希望引入产品经理的新概念，希望由我这个做前端的人来尝试。当然，你的头衔变了，你的工资还是不会变的（老外就特么实在）。花一个高级前端开发兼界面设计的钱，还特么能把你当产品经理使唤。从个人角度来说，一个巨大挑战摆在面前，上还是不上.... 当然上了。
高姿态的说：“ 理想大于物质！” 。心理低姿态的说，能升上一级，将来的回报肯定超过付出。
上路
从P产品开始，作为来公司以后主要参与开发的产品，对P有非常厚的感情，期间主程序员易手，新项目经理上任。这产品可谓，生命多坎坷，还没生出来就经历各种折磨。P Beta简陋不堪，我来公司以后主要接手功能设计和前端设计，后期我逐渐淡出P项目，加入其它项目组，再后来P 1.0 推出和无法正常上线实施，可谓一片凄凉。
下面就罗列下，我们对小P做了什么....
1. 了解产品状态： 虽然1.0版本已经上线半年有余，实际基本上没有人使用，原因一，公司高层没有强制使用。原因二，产品是在无法使用。很多BUG，逻辑不清楚，几次演示都不成功。审批流程断断续续，无法顺畅执行，甚至运行时抛黄页。原因二成为原因一的诱因，原因一也让原因二继续不断的深入又深入。
2. 深挖产品需求：以前作为产品设计者，我们只关注设计。我们看到的都是整理好的产品需求，对应需求做产品，甚至不知道为什么会开发这样一个产品。了解公司的现状，找到产品最终使用者，无视他们的抵触情绪，陪笑脸搞关系，深挖需求。小P能给公司带来什么样的改变？怎样让公司决策者认识它？怎样才能让用户接受它 ？
3. 验收产品质量：作为开发者，自己都没办法顺畅使用的产品，是不应该发布出来给用户使用的。所以，接下来的步骤，就是挖掘自己的问题。充当测试者，用户体验者，几十轮的不停测，碰到问题全部记录到Task列表，针对每个Issue分析，是否BUG，是否需求，是否需要处理。需要处理的，立即找到开发人员，分派任务进行Debug和更新。直到自己能顺畅的使用和进行演示。此时，虽然产品并不完美。但是，能够演示已经足够说服决策层下决心应用P产品。得到决策层的支持将注入整个团队新的活力，随着新鲜血液的加入，P 2.0项目组初见雏形。
4. 协调开发和支持：面对为一个不成功的产品，谁也不会愿意接手烂摊子，一靠领导强制安排，二靠私人关系。每个BUG类的Issue，自己都深挖源头，找到大致的问题，然后找到开发团队的同事，重现给他，甚至直接解释什么原因造成的BUG。每个需求类的Issue，不清楚的，跑遍相关部门，围追堵截，找到相关人搞清楚需求，不紧急的需求，全部延后。紧急的需求全部放到开发列表中。陪人加班，帮忙买晚饭，一个问题一个问题击破。因为开发团队跟产品经理没有上下级关系，所以开发进度的控制基本靠你个人的能力来跟进和推动。
5. 产品质量把关：比第一次的更加严格，从用户界面，到用户体验，从黑盒到白盒，自己的产品不完美是无法让用户接受你的新产品的。不经百炼难成钢，大刀阔斧。不停的迭代和重构。P产品像一个孩子一样在整个团队手中不断成长。直到有一天的演示会议中，老大说了句让整个团队欣慰的话，“我现在可以说，我所看到的P产品，可以使用了！”，P 2.0 是时候上线了。
6. 产品上线：不是发布出来就结束了，并不是高层让大家使用此类软件，大家就会乖乖的使用，总会有各种各样的借口来拒绝你的改变。各种冷眼职责，必须笑脸相迎。甲方虐我千百遍，我待甲方如初恋。组织各种培训会议，撰写各类手册，录制DEMO。老大在实施过程中给了很大的帮助，组织培训，帮你一起培训，培训后进行测验，不及格的通知家长。
7. 后续技术支持：对于小的开发团队，想专门有人做Support，像客服一样是没有可能的，复杂的产品也不容易找到专门的客服，培训客服还不如自己支持，产品经理就要兼做客服。每天不断的电话骚扰，碰到问题不明白的，不会使用怪你软件不好的，系统问题怪产品不好的，各种大爷让你跑断腿的，1VS1陪读的，手把手教学的。技术支持是对产品提升有重大帮助的重要环节，往往实践出真知，有些隐藏的BUG就此被挖掘出来，有些新的需求不断被提交到开发小组，新的需求就能不断完善 P 2.0！产品就能不断的改进，越来越成功。在各种部门中穿梭，也让产品经理的人际关系提升，方便以后再深入各个部门去拿需求，脸熟了就好办事。进入良性循环的轨道，事情往往得心应手。
2013年初，公司业务萎缩，大举缩减部门，在P 2.0 和老大的帮助下，我成为幸存者中的一名。 并且获得了另外一个产品M 的全部管理权限。
所谓与人玫瑰，手留余香。我为人人，人人为我。将近两年的辛苦付出，在此刻给予我足够的回报
收拾行装，继续上路。
