作为一个资深产品经理，这几年工作中遇到的挫折和收获，数也数不清。看到用户数的不断增长和好评我会犹如打了鸡血，听到伙伴的质疑和用户的指责我也会在回家地铁上默默掉眼泪，后悔当初的选择。对于新入行的童鞋，我这个老鸟只有一句话：产品经理这个职业犹如生活，你认真对它，它就会认真对待你，但要成为一个优秀的产品经理，必须要征服这三座大山。
◆需求收集和挖掘阶段
产品每一个迭代、每一个功能点，其实都是产品经理坚持和妥协后的结果。首当其冲，产品经理就需要面对 “用户价值”（即人们常说的用户体验）和 “商业价值” 的平衡与取舍。
需求是产品经理每天都要打交道。产品设计是为需求服务的，需求分为功能层，即业务需求，和体验层，即视觉、人机交互和文案三方面的体验。
需求一般都来源于哪里呢？又如何判断优先级呢？
人们常说是用户的需求为产品第一需求，其实这个有些偏颇。第一个产品都是为公司或团队的总体战略服务的，我们在挖掘用户需求之前，需要确认产品的目标行业、领域、用户群及使用场景是什么样的。
举个栗子：淘宝不是一开始就有货到付款。支付宝已经很好地满足了用户的支付问题和对商家的信任问题。随着用户量的增加、中小城市尤其是对网络和网购不发达地区的渗透，货到付款才应运而生。除了战略、目标用户群体，当然这个功能的上线，依据的还有数据的挖掘与分析，用户的反馈和竞品的发展。
需求评估的本质是价值评估，一般是如下几点：
① 受众的大小，即核心价值还是延伸价值；如百度地图最核心的就是找路线，有了这个才有后面的打车和找饭馆等具体细化的场景化需求。
② 用户使用频次，高频次打低频次。最近微信取消了下拉拍小视频这个功能，下拉拍小视频不是一个高频的需求，数据显示，用户通过朋友圈发小视频的比例高达 95%，而下拉只约占 5%。这个数据有效的支撑了需求变化。
③ 还有就是依赖程度了。
以上这些评价指标都可以用数据指标来判断：
① 数据指标中更多应该使用相对值来评估功能的价值。绝对值容易被操控，如市场部被供应商买了垃圾流量，这时候我们用人均激活量、日均浏览等来判断更为高效。
② 数据解读要更为谨慎，如下面这个很多地方都看过的栗子。
作战指挥官由此认为，应该加强机翼的防护，因为分析表明，那里"密密麻麻都是弹孔，最容易被击中"。但是统计学家却有不同观点，他建议加强座舱与机尾部位的装甲，那儿最少发现弹孔-----因为他的统计样本是联军返航的受损飞机，说明大多数被击中飞行员座舱和尾部发动机的飞机，根本没法返航就坠毁了。
需求评审会：我们该坚持和放弃什么
试错是必经之路。一些开发和项目经理在需求（PRD）评审会时，常常会质疑你的设计和产品需求提炼的产品功能，他们的口头禅是 “我是用户，我就不会用这个功能，我会 xxxxxx”，这个时候千万不要急，慢慢道来，你的设计的背景和场景是什么，达到什么目的，要是有前期数据依据那就更有说服力；若是这个是他一家之言，你可以直接忽略他的言论，因为他只要一发散，就容易到了花很多时间讨论和会议主题毫无帮助的讨论。更何况，用户种类千千万万，我们谁都是用户，谁也都不能代表用户。
不要惧怕冲突，和摩擦。每个产品参与者都有自己的立场和着眼点，项目经理希望功能点越少越好这样交付周期会宽裕，运营人员希望产品功能越灵活越好，这样营销活动种类丰富，但又希望操作简便。
因此我们在需求文档前需要明确：
①用户对象；
②核心功能点和达到的目的是什么，即是什么和为什么；
③评价这一功能效果的数据指标是什么，即价值是什么，大的有时是战略目标，有时只是某个时间段内的产品小目标，两者都要有数据可以体现，如月投资人数、网站日二跳 UV 数、又或是周 投资额）；
④设计这个功能点的原因是什么，做依据的历史数据；
⑤如果要减少一个功能点，我会舍弃或是降低哪个功能点的优先级，连续问自己 2 次。这一点是我自己习惯用的，因为我是一个爱 “贪多” 的产品经理，大家看看就行。
这些准备好后，我们在评审会开始时就将前 4 点阐明，这样评审会参与者们也会对需求有个宏观的认识。进而我们就可以对产品功能、流程和交互做进一步说明。
评审阶段的言行
不要出口伤人，侮辱人格的脏话是严禁的，你可以语速快，声音适当抬高，但务必就事论事的探讨争议点。若让他人不开心，可以会后给予解释和道歉。其实在每一次撕 X，“打怪升级” 过程中，我的口头表达能力，说服能力，临场反应、决策判断能力都在提升。等你积累到一定段位，在产品相关人员中建立了 “威望”，你会被他们接纳，你所说的会让人更信服，这是需要一个过程的。
PRD 评审会是 review 你的产品逻辑、用户使用场景和 demo 稿，是非常有针对性的，不要一味当成了辩论赛，靠三寸不烂之舌来定输赢。如果实在争论不下，可以这个问题放一放。如果必须有个结论，我的建议是，技术实现角度一定要信任技术人员，用户体验设计就听取设计人员的专业建议，因为一切的争论都会在后期用数据来论证。
需求评审会一定要开发人员和测试人员参加，仅是开发 leader 或是项目经理都不行，因为只有在一线做执行的开发和测试人员，才能将真实的现状和所需时间反馈出来，他们思考的细节点有时候是超越产品经理的。
开发工时的评估
我的经验是作为 PM 结合需求方的意见和运营推广时间给予一个排期，当然开发团队肯定是会认为这个时间比较紧张（几率高于 80%），他们需要重构一些东西，还需要依赖其他团队的开发成果，另外还需要拆解下。当然前提是其他团队的产品经理的东西不会优先级更高插进来，等等。这时候需要耐心听取下开发 leader 和项目经理的排期，刚开始磨合一般要多沟通几次开发排期，因为往往你以为只要只有一个改动点，后面到了预期时间又发现其实在开发看来是好几个改动点，这个是需要一段时间的磨合。
对于交付时间点的妥协前期也是无法避免的。等你了解了整个开发团队的技术能力、开发效率、谁擅长哪一个功能模块，3~4 个迭代后就会对开发时间周期有个很好的把控。
这里还需要提的就是，几个版本的 PRD 和 demo 稿，甚至是 api 接口定义等都需要文档留存下来，需求和设计会变更和更迭，文档也需要实时更新。如果人员更迭，这些文档可以更快帮助新人上手工作，也可以为后期产品优化提供前期考量的思路和着眼点。当然你在准备工作年报甚至是面试、演讲或出书时，这些历史文档都是你曾经努力和成长的记录。
◆迭代阶段：迭代质量和迭代速度
很多人都说产品经理是需要天赋的，要有产品 sense，点子多脑子活络的人很适合产品经理，我个人的感悟是点子和想法的确在很多时候都是可以使产品起死回生的，但在产品经理职业发展的初中级阶段，点子本身没有什么，都需要扯皮和谈判来明确其价值。很多人会想到，少人会做，更少的人做成。
产品经理是需要跟进开发过程的，每一次迭代都感觉是和时间赛跑，时间和资源都是有限的，很多时候我们干着产品经理的活还得操着项目经理的心。建议大家都用纸笔画一个时间轴（专业一点可以用甘特图），什么时间点输出什么，并用 outlook 的日历功能做提醒，这样到了某个时间点确认交付的东西，不会有遗漏。如 12.3 出交互稿，12.5 出视觉，12.9 出 api mock，12.16 完成开发并送测，将这个时间轴分享给这个产品的所有干系人，这样大家都会对产品进度和时间进度有所把控。
来到点融我感触最深的就是，这是一个工程师文化很浓厚的团队，工程师会对自己和团队的技术能力和成果感到非常骄傲和自豪，大家目标很宏大，但是却又脚踏实地的在一点点的抠细节，加班加点的在赶功能。
很多创业公司的业务部门经常会拿产品功能和技术缺失来作为理由解释业务增长的下滑和瓶颈，我曾经服务过的一家公司，初期产品功能非常少，也创造了大促一天 1800 万的销售额。这个数字是普通一天销售额的十几倍。举这个例子不是为产品找借口，只想说产品功能有时候就是锦上添花的部分，有了核心功能就上线验证，去看数据变化和用户反馈，才能为下一步产品功能走向确定目标。
还有一点非常重要！无论进度多赶的项目，发布前，请一定要内测！一定要内测！一定要内测！重要的事情说三遍。产品经理一定要参与测试，要验收后才能上线！这是血的教训。
曾经我跟进的一个对外合作的小项目，由于那时候 landingpage 页没有开发环境和 STG 环境来测试，需求方和开发都觉得时间紧急且项目小，先赶上线再线上看下使用体验是否有需要调整，这下可怕的噩梦开始了。第一次主站的注册页面 banner 没有根据用户行为做替换，赶紧撤下了 debug，原来这个 landingpage 页没有调注册 api。第二次，我们点击 Landingpage 页面上面的按钮无法正常获取优惠券，又一次赶紧撤下了 debug，原来这个页面的参数少了一个，开发工程师又要修改，我们是一周一个 release，这样等于导致 delay 了 2 周，由于中间隔了 2 周时间较旧，导致这个活动对外合作方又得重新通知线下推广渠道的渠道商，这还需要花近 2 周时间，等于这个活动实际和预期的上线时间差了 1 个月时间。
不同设备的适配性测试也是需要的。现在很多的产品都是 mobile first，看似 pm 的工作更聚焦，其实这无形中包含了很多的工作量，平板还是 mobile，是 iOS 还是安卓，是 native 页面还是 H5 页面，是 iPhone5 还是 iPhone Plus 的屏幕尺寸，产品功能和体验都需要上线前后进行测试和检查。
除此之外，还需要性能测试，尤其是伴随一些促销等运营侧的功能。高并发的情况是否考量？应急的预案是什么？若竞争对手攻击该如何处理？这些不仅仅是运维同学的事情，也是需要 Pm 加入一起准备的。一个产品经理的职业生涯，没有遇到过黑客攻击、竞争对手打击和上线后功能的回滚都是不完整的。
◆职业发展、人际交往
选择做产品经理，除了面对迭代、功能和需求的纠结，也有职业发展上、人际交往上的的笃定和挣扎。
做产品是需要强大体力和旺盛的精力来支持的，最近的我白天常常需要 5~6 个小时参与大大小小的会议中，需求沟通、需求或文档评审、资源沟通、与项目经理的、交互稿视觉稿跟进、与老板汇报进度、跨部门争取资源、只有下班了同办公室的同事都走了的时候，我可以安静的整理下思路，写下文档，总结下自己的不足与收获。白天开会晚上加班写文档想必也是很多产品经理的日常写照吧。当然这也和我刚入职，和各部分还需要时间磨合有关，时不时我也在告诫自己需要提高效率，调整与不同部门的沟通方式，对于掌控力很强的项目经理我只需要 PRD 评审会沟通好就行，对于产品线和项目众多的开发和 UED 们，我需要时不时带着零食和笑话去 “慰问” 下他们。
互联网改变了你我的生活，也让我们听到了不同的声音，看到了多变的视角。什么极简主义、金线论、反反智主义、钝感力，每一个观点每一种文化都有其面具性和立场罢了，这个世界是多元的，正因为这些观点和立场有其发声的权利才显得互联网时代的开放和可贵。作为产品经理，或是作为互联网时代的一份子我们都要多听多看，学会理解、善待和接纳。面对复杂，保持欢喜~
