染雾“产品经理”, 一个重未被真正定义的争议角色. 他有时是模糊的, 有时却又清晰无比. 有时他是产品的缔造者, 但更多时候他却是开发和设计人员眼中的公敌.很早以前就想抽时间来写一篇文章, 说说我对 “产品经理” 这个角色的想法. 后来一直因为时间关系没有动笔. 再后来自己也懒得动笔了. 再后来, 随着我遇见过的产品经理越来越多, 加上自己也亲自做了一年多产品经理, 从不同角度再次认识了这个职位. 今天, 我想把这些经历分享出来, 聊一聊产品经理.因为没有清晰定义其职责范围, 所以在下文中我提到的 “产品经理” 将会是很宽泛的概念. 我会尽量以目前业界的事实标准来界定产品经理的职责范围并进行讨论.
产品经理是一个没有明确的概念的角色。这个职位的职责有时候是模糊的，有时候又清晰务必。说他是产品的缔造者，但却不招开发和设计人员的喜欢。产品经理的职责和修炼方式也各有不同，不可一概而论。
1、新蛋产品经理: 分而治之
第一次接触到这个职位, 是在新蛋做对美业务时. 所有的需求文档都是美国直接发过来. 写需求文档的被称为 “BSA”, 意即 “商业系统分析”. BSA 会将详尽的需求文档发到项目参与人员手上, 然后进行电话沟通, 传达项目的背景与商业目标. 确定大家没有问题之后, 就会开始项目排期, 进入到开发阶段. 对于稍大型的项目, 还会有 “BSD”(商业系统开发) 参与, 负责所有技术资源的调动. 有的项目里 BSD 还会参与 coding, 负责技术方案, 架构和底层实现等. 下面的开发人员会根据 BSA 的需求和 BSD 的方案进行开发, 直至提交测试和最终上线.
大体上在新蛋 “产品经理” 的职责是由 BSA 与 BSD 两个职位来分担的. 前者负责需求, 后者负责实现. 而一个小项目往往从属于更大的项目, 因此 BSA 实际负责的会更多. 项目进度的把控也是由两个角色共同负责. 一般来讲, BSD 会负责掐住开发时间, BSA 则负责整体进度. 与其它公司不同的是, 除 BSA 提出需求之外, 还有另一个被称为 “WM” 的团队专门负责提出和验证需求, 并交由他们选定的 BSA / BSD 去执行.
值得一提的是, 新蛋的 BSA 与 BSD 都相当专业. 我接触过的几位 BSA 都会和我详尽沟通需求, 对问题尽其可能解答. 那时候 BSA 通常选择在电话里直接沟通需求背景, 而在文档中则详尽描述需求对应的每个功能点. 对每个功能都配上 UI 界面与交互流程. 后来我在阿里时, 一位同事拿他的 Axure 给我解释什么叫 “高保真 PRD”, 看着他那图多字少, 流程混乱的文档, 我只能蛋蛋一笑.
BSD 也不是虚职. 我遇见的 BSD 都有极强的代码功底, 他们本身往往就是项目的技术架构师, 在项目里负责根据情况调整技术方案, 协调技术资源和与进度把控等工作, 类似其它公司的架构师 + PM.
要注意的是, 新蛋的 BSA 们似乎没有涉及到与运营相关的工作. BSD 们更不会涉及. 这块工作通常交由 Marketing 部门去做. 当然也有可能 BSA 们会做运营相关工作, 只是做为底层开发人员的我并不知晓 :-(
2、阿里巴巴产品经理: 大包揽
后来我来到了阿里巴巴 B2B. 在这里真正零距离与传说中的 “产品经理”, 阿里称之为 “PD”(Product Director/Designer)一起工作.
在阿里巴巴, 一个合格的 PD 首先必须是成功的 saler. 阿里内部有 “打鸡血” 的传统, 每次做项目, Kickoff 都恨不得能办成晚会. 做为项目发起者的 PD, 必须有良好的 “忽悠” 功底. 当然, 我说的 “忽悠” 是褒义词. 因为在大公司, 特别像阿里这样的巨型航母里, 不见得每个项目都有意义, 做了都能看到实际的成效. 怎么调动项目参与人员的极积性, 让他们认为自己手上的项目是最牛逼的? 这必须要求 PD 会说, 有些时候还要善于画大饼. 除此之外, 阿里的 PD 们相更贴近用户, 更加 “草根”. 由于公司的轮岗制度, 大多 PD 以前做过运营甚至客服, 在这些一线职位摸爬滚打几年后, 对公司的用户群体会有更深入和直白的理解.
其次, 阿里的 PD 还必须是团队的 CEO. 从产生想法, 需求调研, 到 PK 项目资源, 向项目组传达需求和目标, 再到 kickoff, 进度跟踪, 随时根据情况迭代需求, 再到安排测试 case, 验收功能, 产品上线, 直至产品运营推广, 数据分析, 用户反馈和版本功能迭代等, 都由 PD 一人负责. 并且 PD 还要为产品的表现背最大的 KPI 指标. 所以好的 PD 必须是好的 CEO, 上窜下跳, 费尽口舌为项目做好三件事: 找方向, 找人, 找资源.
当然, 做的事多了, 就很难精通某个方面. 所以我合作过的 PD, 大都会遇见以下问题:
MRD, PRD 不清晰. 特别是 PRD, 由于产品需求经常一变再变, 甚至到了开发阶段仍然状况不断. 加上项目时间永远不够(有趣的是, 我从没有参与过时间充足的项目, 每个项目都号称时间紧迫资源紧张)因此很多时候 PRD 成了一纸空文, PD 不会持续更新, 就算写也只是草图画画. 到最后各种需求变成了口头交流.
流程进度把控能力较弱. 我做项目时就常遇见为赶 deadline 或初期没想清楚中途再改需求导致增/砍功能的情况. 常常搞得 UED / 开发团队一片怨声.
PD 大多不了解(广泛意义上的)技术却又自持理解用户. 这是个很大的问题, 常常导致 PD 想做的东西开发人员并不真正理解, 而开发的问题又很难被 PD 真正重视. 长期以往, PD 与开发产生了各种互不信任.
但即使有各种问题, 公平的说阿里的 PD 们还是具备强大的专业能力与敬业精神. 特别是在用数据说话这方面, 我遇见过多位强大的 PD. 但我的映像是, 阿里的 PD 们总是缺乏一些互联网 sense. 当然, 一家之言.
3、创业团队产品经理: 铁人汉堡
离开阿里后, 我加入了一家创业公司. 在那里我的身份由开发人员转变为了团队管理和产品经理. 和老大谈职位时, 做为 UEDer 我聊了很多对产品设计的空想. 于是老大让我负责这块东西. 就这么着我开始了产品经理的生涯. 前后一年多时间, 做出了一个移动端产品. 这次亲身体验, 让我有了机会从另一个角度看待产品经理.
在创业团队里, 要求每个成员都能够 “一专多能”. 如果说阿里的 PD 是 CEO, 那创业公司的产品经理无疑是 CEO 中的铁人. 在事情的每个环节上, 都要求产品经理想得更清楚更加深入. 因为这时候产品经理背的不再是 KPI, 而是公司的方向, 甚至是公司这么多兄弟的饭碗(这么说一点也不夸张. 虽然有的公司老大很强势, 但也需要下面一帮产品经理帮着去实现他的想法). 这时的心理压力和所处环境与大公司做项目是不一样的. 事情变得极其琐碎, 需要搞定内(老板, 开发人员)外(商业, 渠道, 媒体等)各种事情. 至于客串 HR 招人, 清洁员工打扫卫生那更是便饭.
在创业初期, 基本没有自己的休息时间. 产品开发时我跟着开发一起加班, 连续一个月凌晨两三点回家. 产品刚上线时又常在周末被电话叫起来看数据. 所以那个时候, 我真的成了铁人.
同时, 创业公司的产品经理又是 “汉堡”. 为什么呢? 因为产品经理常常被夹在老板与开发人员之间. 老板看到的方向, 想做的事, 由产品经理负责转化为产品功能. 另一方面对于 UED, 开发等团队而言, 因为信息不对称常常不理解为什么要做这样的功能? 所以产品经理需要不断与团队成员沟通, 分享数据, 解释问题. 但要命的是, 一方面产品经理们没那么多精力, 另一方面并不是所有需求都能事前想通, 事情总在不断变化. 所以产品经理的想法经常修改, 难以执行下去. 久而久之, 产品经理成了大家的出气筒. 老板认为产品经理执行力不强, 而开发们则总认为产品经理没有想清楚, 不想投入太多资源和精力. 这是我在一年多的创业里所体会看到的.
每个职位都有几本人人推崇, 称之为 “必读” 的入门书籍. 做前端的有 Oreilly《xxx 权威指南》动物书系列, 交互有 Alan 写的《交互设计之路》或《Don’s make me think》. 而对于产品经理, 放眼望去最具人气的应该是《人人都是产品经理》了吧. 可惜的是, 前几本书都经受了时间的考验,确为经典. 而后者近来却质疑不断.
当然, 首先声明我这里并非要讨论这本书. 因为我没有完整读完它, 仅仅看过一些片断, 在阿里内网里看过作者的一些东西. 这里只是想说说它的书名: 人人都是产品经理.
真的吗?
其实我十分理解作者取这个名字的用意. 但这个名字就如同魔盒, 一旦开启便失去了控制. 特别是对那些和我一样没有读过本书的人. 它似乎在告诉大家, “产品经理” 没什么了不起的, 人人都可以做. 就像滥大街的 “客户经理”, “销售经理” 一样. 但产品经理门槛真的这么低, 这么好做以至于刚毕业没任何文章的大学生也敢来应聘这个职位?
4、其实通过上面我所描述遇见过的产品经理们可以发现, 和任何职位一样, 想真正做好产品经理并不轻松. 很多时候甚至是痛苦. 《人人都是产品经理》告诉人们拥有哪些特质就可以成为产品经理, 而我则要列出一些点告诉你缺乏了这些不能够成为产品经理.
缺乏抗压能 
[产品经理职责及修炼]
