优秀的产品经理，必须翻越这三座大山
|
作为一个资深产品经理，这几年工作中遇到的挫折和收获，数也数不清。看到用户数的不断增长和好评我会犹如打了鸡血，听到伙伴的质疑和用户的指责我也会在回家地铁上默默掉眼泪，后悔当初的选择。对于新入行的童鞋，我这个老鸟只有一句话：产品经理这个职业犹如生活，你认真对它，它就会认真对待你，但要成为一个优秀的产品经理，必须要征服这三座大山。 ◆需求收集和挖掘阶段产品每一个迭代、每一个功能点，其实都是产品经理坚持和妥协后的结果。首当其冲，产品经理就需要面对 “用户价值”（即人们常说的用户体验）和 “商业价值” 的平衡与取舍。 需求是产品经理每天都要打交道。产品设计是为需求服务的，需求分为功能层，即业务需求，和体验层，即视觉、人机交互和文案三方面的体验。
需求一般都来源于哪里呢？又如何判断优先级呢？ 人们常说是用户的需求为产品第一需求，其实这个有些偏颇。第一个产品都是为公司或团队的总体战略服务的，我们在挖掘用户需求之前，需要确认产品的目标行业、领域、用户群及使用场景是什么样的。 举个栗子：淘宝不是一开始就有货到付款。支付宝已经很好地满足了用户的支付问题和对商家的信任问题。随着用户量的增加、中小城市尤其是对网络和网购不发达地区的渗透，货到付款才应运而生。除了战略、目标用户群体，当然这个功能的上线，依据的还有数据的挖掘与分析，用户的反馈和竞品的发展。 需求评估的本质是价值评估，一般是如下几点： 受众的大小，即核心价值还是延伸价值；如百度地图最核心的就是找路线，有了这个才有后面的打车和找饭馆等具体细化的场景化需求。 用户使用频次，高频次打低频次。最近微信取消了下拉拍小视频这个功能，下拉拍小视频不是一个高频的需求，数据显示，用户通过朋友圈发小视频的比例高达 95%，而下拉只约占 5%。这个数据有效的支撑了需求变化。 还有就是依赖程度了。以上这些评价指标都可以用数据指标来判断： 数据指标中更多应该使用相对值来评估功能的价值。绝对值容易被操控，如市场部被供应商买了垃圾流量，这时候我们用人均激活量、日均浏览等来判断更为高效。 数据解读要更为谨慎，如下面这个很多地方都看过的栗子。
作战指挥官由此认为，应该加强机翼的防护，因为分析表明，那里”密密麻麻都是弹孔，最容易被击中”。但是统计学家却有不同观点，他建议加强座舱与机尾部位的装甲，那儿最少发现弹孔—–因为他的统计样本是联军返航的受损飞机，说明大多数被击中飞行员座舱和尾部发动机的飞机，根本没法返航就坠毁了。 需求评审会：我们该坚持和放弃什么 试错是必经之路。一些开发和项目经理在需求（PRD）评审会时，常常会质疑你的设计和产品需求提炼的产品功能，他们的口头禅是 “我是用户，我就不会用这个功能，我会 xxxxxx”，这个时候千万不要急，慢慢道来，你的设计的背景和场景是什么，达到什么目的，要是有前期数据依据那就更有说服力；若是这个是他一家之言，你可以直接忽略他的言论，因为他只要一发散，就容易到了花很多时间讨论和会议主题毫无帮助的讨论。更何况，用户种类千千万万，我们谁都是用户，谁也都不能代表用户。 不要惧怕冲突，和摩擦。每个产品参与者都有自己的立场和着眼点，项目经理希望功能点越少越好这样交付周期会宽裕，运营人员希望产品功能越灵活越好，这样营销活动种类丰富，但又希望操作简便。 因此我们在需求文档前需要明确： 用户对象； 核心功能点和达到的目的是什么，即是什么和为什么； 评价这一功能效果的数据指标是什么，即价值是什么，大的有时是战略目标，有时只是某个时间段内的产品小目标，两者都要有数据可以体现，如月投资人数、网站日二跳 UV 数、又或是周 投资额）； 设计这个功能点的原因是什么，做依据的历史数据； 如果要减少一个功能点，我会舍弃或是降低哪个功能点的优先级，连续问自己 2 次。这一点是我自己习惯用的，因为我是一个爱 “贪多” 的产品经理，大家看看就行。这些准备好后，我们在评审会开始时就将前 4 点阐明，这样评审会参与者们也会对需求有个宏观的认识。进而我们就可以对产品功能、流程和交互做进一步说明。 评审阶段的言行 不要出口伤人，侮辱人格的脏话是严禁的，你可以语速快，声音适当抬高，但务必就事论事的探讨争议点。若让他人不开心，可以会后给予解释和道歉。其实在每一次撕 X，“打怪升级” 过程中，我的口头表达能力，说服能力，临场反应、决策判断能力都在提升。等你积累到一定段位，在产品相关人员中建立了 “威望”，你会被他们接纳，你所说的会让人更信服，这是需要一个过程的。 PRD 评审会是 review 你的产品逻辑、用户使用场景和 demo 稿，是非常有针对性的，不要一味当成了辩论赛，靠三寸不烂之舌来定输赢。如果实在争论不下，可以这个问题放一放。如果必须有个结论，我的建议是，技术实现角度一定要信任技术人员，用户体验设计就听取设计人员的专业建议，因为一切的争论都会在后期用数据来论证。 需求评审会一定要开发人员和测试人员参加，仅是开发 leader 或是项目经理都不行，因为只有在一线做执行的开发和测试人员，才能将真实的现状和所需时间反馈出来，他们思考的细节点有时候是超越产品经理的。 开发工时的评估 我的经验是作为 PM 结合需求方的意见和运营推广时间给予一个排期，当然开发团队肯定是会认为这个时间比较紧张（几率高于 80%），他们需要重构一些东西，还需要依赖其他团队的开发成果，另外还需要拆解下。当然前提是其他团队的产品经理的东西不会优先级更高插进来，等等。这时候需要耐心听取下开发 leader 和项目经理的排期，刚开始磨合一般要多沟通几次开发排期，因为往往你以为只要只有一个改动点，后面到了预期时间又发现其实在开发看来是好几个改动点，这个是需要一段时间的磨合。 对于交付时间点的妥协前期也是无法避免的。等你了解了整个开发团队的技术能力、开发效率、谁擅长哪一个功能模块，3~4 个迭代后就会对开发时间周期有个很好的把控。 （编辑：云计算网_汕头站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
