工作之前

角色转变

从程序员开始

大二起，发现自己在信息技术方向上的兴趣，更多地偏向互联网。说干就干。初中有用 FrontPage 和 Dreamweaver 自制网页的小经验，便到图书馆拿 HTML 和 CSS 方面的书读起来。一天时间通读，就手工写出了 Div+CSS 的代码，整齐美观，颇为自豪。快速学习的能力是一方面，最重要的地方在于，这份网页不再是通过 Dw 点来点去、画表格或者使用层东拼西凑，而是纯手工且符合万维网联盟（W3C）标准。这意味着我写的东西不再是玩具；它们进入了可应用的行列；

特长和志向不在视觉设计，我也不满足静态网页。选择 PHP，因为它使用广泛，入门容易。有了初中 Basic 和大学 C 语言的基础，这样的脚本语言很快可以写出来。很自然，MySQL 和 Javascript 列入了我的书单。

为了检验学习成果，我立了一个博客项目。衡量其好坏的标准在于，能囊括目前博客网站的多少功能。为了检验应用能力，大胆独立外包了一个电商网站，其中的关系、权限的复杂度与支付功能是从未遇到的。网站勉强顺利开发到一半，老板突然决定改设计成商品展示网站。这下自己减负很多，项目圆满完成。

项目经理

做外包项目的同时，我已经把自己定位成 PHP 程序员。空闲之余，在 PHPChina 网站上捞各种招聘信息。经过多番了解和学习，我发现自己并不适合开发：

• 数学不好，而且对之深恶痛绝
• 缺乏复杂逻辑计算的天赋
• 代码看多了眼睛疼

综上所述，恐怕我根本不是开发的料。不过只是借开发之力，完成“项目”。而且，开发也不是我想要的，因为我：

对一个项目（工程、产品）导向感敏锐。不敢称为“战略”

执着于产品设计。包括版式、视觉、文案等

要求苛刻，追求完美。对字符、像素级别的单位挑三拣四

我想要：

• 改变世界。我们的生活糟糕透顶，需要一个东西彻底颠覆
• 有价值。有力量持续改变

我以为这样的孩子名头叫“项目经理”，他来决定程序员写什么。走进项目的流程，进入其涉及的范围，第一步便是搞清什么是“项目”。这个时候又才了解，相对的，还有“产品”这个概念。

产品经理

产品旨在满足需求。产品经理的职责是探索和定义产品：探索价值，定义解决方案。

这正合我的胃口。我转个弯，一方面，广泛学习请教产品知识；另一方面，也做项目自察。做产品容易“假大空”，为了避免如此，我把在博客园上本来准备为技术沉淀的博客，搬迁到了独立博客上。使用独立博客的好处是：

• 显得专业
• 能够炫耀
• 要花钱，所以得坚持
• 本身便是一款产品

自此，开始研习产品的学问，所思所得都记于此。

应聘淘宝

3月8日 投递简历

淘宝是我应聘的第一份正式工作。

去年得知它们有一“产品经理特训班”。既然专门为咱们这号人打造，自然不能错过。

22日 参加宣讲会

全程很傻很天真地做了笔记。囧。

27日 现场笔试

路痴加上得到了错误的指引，硬是在校园里绕了一个多小时。

淘宝笔试的题目分为数学题、逻辑题和论述题，题型为选择题、填空题和问答题。数学考概率、数据结构和指针；逻辑考推算、解除纠纷和推理；论述考写字楼电梯设计和淘宝买家产品设计。刚拿到题目还是觉得挺别扭的，毕竟大学里的考试，你懂的。认真做下去之后，不仅发现难度正好，还觉得挺有意思。最后一题因为时间紧张，只剩下5分钟，答得没有条理，也不够细致。

4月14日 现场面试

准备最多的还是“保洁八大问”和群面攻防术。我以为会有多复杂，多紧张，结果到了淘宝面试现场也就那样。

一面首先自我介绍。根据网上的经验，一句话结束。然后面试官震惊了，要我说个10-15分钟，然后我就震惊了。介绍完毕后，主要是询问自己一个做着玩的项目，重点在商业机会。完毕，面试官叫我直接去二面，我本来以为要等个几天的。

二面首先自我介绍。根据上一轮经验，我准备开始滔滔不绝。结果，我说的每一句话都被打断——这回是盘问而不是询问了——我也知道，压力面来了。在交谈的过程中，根据学生会的经验，主要把握三点：线索、成果和收获。线索是跨话题的润滑剂（井井有条就免了，能不生硬已经万幸，又不是演戏），成果是成功的收获，收获是失败的包装。

看上去很淡定是么？其实根本就不是这样，哈哈哈。还好也没差哪去。

这次面试最大的不足在于，畏惧权威，依据不严谨，导致说服力度没有到预期的档次。另外，我不推崇繁复的自我介绍，因为简历上已经写得明白；我推崇相互尊重。

18日 收到录用书

进入淘宝商城

开始

纸上谈兵

初来乍到，第一反应就是和所阅相比完全不是一回事——这些书还都是有关互联网、大产品部门；和学校更是风马牛不相及。具体说来，就是和预期各种不符。根据我的理解：

• 产品经理无授权领导，交换意见后拍板决定
• 产品需求文档保持更新，有据可查
• 项目经理负责掌控项目进度
• 开发不受到打扰，专心进行编码工作
• 运营负责提供数据，供产品经理决策
• 用户体验部门充分独立，为用户体验提供捷径
• 会议有了邀请制、预告和纪要，因此高效
• 经过充分讨论 / 思考，得出问题最佳突破口
• 最终产品功能好用，途径从简

事实并非如此。

方向、目标、途径

当一套知识体系不够用的时候，捷径是获取并切换成另一套，比如公司对员工技能的定义。这一套概念非常有效，因为它努力避免了套话，把具体的能力细化成可以考量的规范；最重要的是，经过证明，它行之有效。好比同样是《小学生守则》，中国讲“诚实守信”，美国讲“考试不许作弊”。

达成目标最好的技能是主动，但有一股劲使不出也不是个事。这个时候，我发现《启示录：打造用户喜爱的产品》当真是葵花宝典啊啊啊，尤其是第28-30章，一条一条地讲碰到什么问题，怎么去做。比如：会议太多，导致产品毫无起色，怎么办？

我开始的做法是，抱着本本去开会。如果内容无关紧要，我就可以做自己的事。但这样明显会有几个问题：

做事分心

会议上的内容没有听好（特别是当别人问起来，自己一无所知时，就悲催了）

显得（也确实是）效率低下，做事不专心

书里介绍的办法是：直接划去（借口推辞）不重要的会议。比如，有的会是讨论背景，有了结论（做不做，做什么样的需求）后才能和产品经理讨论具体需求。曾经出现这样的状况：讨论了一个上午，把这样的需求删了，或是归并到另一个部门里，自己白白牺牲。

在横冲乱撞（很能导致瞎忙活）前，看看有没有好办法；但不论怎样，做，总有收获，错误的路径划去一个是一个，就像爱迪生那样。

工作

工作环境与同事

工作起来比较轻松、开朗、活泼；既很黄很暴力，也很闷骚。好吧，最后两句是我自己加的。大家干起活儿，会碰到各种狗血。比如，教师节，周围会有淘宝大学的同事拿着垃圾桶敲锣打鼓，旁边还挂着牌子：严肃&回避。

休闲吧的桌上足球不用说，免费的咖啡和奶茶不必说，22点半以后送上门的宵夜自不必说，周六周日来公司可以蹭两餐饭也不必说，最让我觉得有意思的是咱们的卫生间。其间会挂有宣传画，也就是广告，像出什么产品啦，有什么相亲活动啦，做什么折扣啦，用词极为忐忑。比如：二十一世纪最缺什么？老湿！欢迎各位小二来××为大家讲解××。来就有奖品赠送，至于你信不信，反正我是信了。地球再也无法阻止你湿了，快来报名吧！

咳咳，接下来是重点：一次在男生小便池前看到的宣传画是：卫生巾在聚划算打7.5折，于是各种苏菲弹力贴身。男生的大便的隔间里，除了有贴心的卷纸、挂钩和肥皂盒（放手机用）外，还有一块纸板一支笔。我俗称为吐槽板，因为咱们会在上面进行各种吐槽，什么找不到女朋友啊，月光太冷啊，等等。不仅如此，还会整整齐齐地盖楼，各种苦屄你伤不起。

办公桌之间的隔板低到相当于没有。我的师兄在我左侧，老大在后面，整个产品技术部的领导就在我对面，囧。同事都很年轻，所以都 hold 住。好吧，正经一点，总的来说就是：团结紧张，严肃活泼。

每天出入大门，保安同学都会亲切地微笑，道声好。一次周末因事赶去公司，15点多才买了泡面当午饭，扫地的阿姨很温馨地和我讲：小伙子，再忙也要吃好饭。

认真工作的人，真美。

需求文档与原型

如果产品需求文档不靠谱，或许有这些解决办法：

• 冗长。像写散文一样，精炼语言；按功能点 / 场景撰写，使用有序列表；重要的废话放在附录里
• 不直观。绘制高保真 Axure 原型
• 容易过期。任何改动，都更新到文档里，口头除外
• 存在版本控制偏差。严格标明版本（包括文件名和文档内部），每个版本都输出 .pdf 文档

原型也有：

• 非高保真。高保真意味着生成的是 .html 页面，而不仅仅是截图。菜单是能弹出的，下来列表是可以下拉的。直观，可以简单试用
• 交互复杂。原型是为了演示逼真；复杂交互由于藏得太深，容易忽略。对于复杂的交互，不如拆开成场景。以注释的形式附在交互处旁边，标注其将进入什么场景。“注释区域”必须一看就知道是注释
• 无法精确还原功能点 / 场景。精确还原需求文档所写是原型的意义。对于一个场景，能对用户的所有行为做出响应。为了避免使用者漏掉某个行为，以注释在形式在空白处穷举

重要的是执行。最重要的这一步，我还很欠缺。

沟通，还是传话筒？

一款产品通常这样经过：需求（来自运营）→产品→开发+用户体验→安全+测试→发布→反馈（来自运营）。产品只是传话筒吗？如果去掉产品环节，让他们直接沟通，会不会更好呢？

不会。因为：

• 提需求的同学精于运营，缺乏可行的概念。他们知道自己有痛处，但不知道什么可以做（不知道所以想不到点子），什么不能做（想到了点子却做不到）。于是局限了满足需求的方式，更重要的是，隐藏了深层需求
• 开发和用户体验的同学精于实现（可行+可用），缺乏对价值的把握。运营和开发同学直接沟通的成本非常大，一是语言不通，二是难以对需求进行有效挖掘

产品可以做的事有：

• 掌握现有产品 / 工具 / 技术 的实现范围，跟踪其外延。做决策时便有确凿的依据，什么功能能实现，什么不行。不行的话，可以做到怎样的程度，需要多少成本
• 深度挖掘需求。运营同学有了需求后，往往会告诉产品他们想要的，却鲜说（或说不出）真正渴望的东西。如果是这样，一来没有满足真正的需求，导致需求变更频繁，二来，体现不出产品的价值。比如，他们想要一瓶可乐，我们给了，他们又觉得不行，想要一杯橙汁。而他们的实质是口渴了，需要一杯白开

在实际沟通中，某些开发和运营同学明显比我考虑得周道；再加上开发更懂技术，运营更谙运筹帷幄之道，作为产品新人，我表示压力很大。

说“不”与责任心

对产品负责，就是产品在大产品团队合力的情况下，平稳地向积极的方向迭代，有数据和指标可查。在迭代的路上，总会半路冷不丁杀出来一个坎坷，躲都躲不掉。说说我遇到的情况：

• 更多需求（产品）
• 更多需求（功能）
• 需求变更
• 缺乏开发人手
• 会议太多
• 邮件太多
• 缺乏思考时间

对于以上的种种问题，步骤有二：

说“不”。很多情况（≈麻烦），直接拒绝，会省下很多精力做真正该做的事。做产品要精，但不代表事必躬亲

• 对于非一条产品线（部门）的需求，大部分直接回绝
• 同一条线，则根据其价值、开发人手、关系有选择地考虑。需求的紧急程度永远不在考虑的因素范围内，因为所有的需求都自称最急迫。其重要程度则有明显的区别，比如能带来多少交易额，提高多少转化率、流量等
• 对于一款产品本身功能的多寡，则逐个砍，砍到除非确实不能满足需求或严重影响用户体验。这里存在两点，一是有的需求不可避免，比如为了应对政治、营收和竞争对手需要；二是“用户体验”的概念泛化，每个人嘴里都在说这四个字，成为各种挡箭牌。产品的好坏，取决于其核心竞争力。做不好核心，边边角角再漂亮都没用
• 不少会议可以推掉，如前所述。推不掉的会议可以参加需要自己参与的部分。会议纪要非常重要，未出席的会议，主要靠它来了解情况
• 绝大多数口水邮件都可以忽略。MS Office Outlook 2010 就有这个功能，单击一下，自动忽略指定话题

推动。以前我用的词是“跟进”，被老大否了；以前我说“他们”，老大要我说“我们”。别小看词汇，反映的是态度

• 需求一定是可以变更的，控制好变更频率是王道。我的实例是，每周四提变更需求，周五确认需求，评估可行性和开发周期。在开发周期内，冻结一切需求（1%的紧急需求除外）。下周一开工，周三发布上线，拉取运营数据，周四评估是否提新需求还是变更
• 缺乏人手非常普遍。首先，提需求前考虑人手状况；然后，确认需求时确认开发资源（人手、服务器状况）；最后，开发周期内，定期向开发同学询问是否需要帮助，顺便掌握进度和人员情况。如果在立项之初就争取不到人手，办法有：让需求方排优先级；证明需求的价值；向老大请求支持；找朋友帮忙；自己顶上；砍掉该需求
• 利用个人时间思考。我们都笑说产品一天的工作是：白天开会+晚上写文档。时间挤一挤，总是有的。有意思的是，做产品不存在工作地点和时间的局限，很多好的点子就来自生活

感悟

对人尊重。大多数同事都平易近人。养尊处优惯了，遇到不对板的就显得手忙脚乱。一次营销活动，运营的同学非常强势，没有好脸不说，语气还咄咄逼人。经常会说，“哦，你把这个给我做了”，“那个怎么又出问题了，你是怎么搞的”。而我又是个暴脾气，一两回还行，次数多就非常受不了。

后来师兄问我是不是觉得很委屈，我一个劲点头。他告诉我，要学会看人，这也是尊重人。尊重，意味着考虑其人的性格、办事风格以及当时的环境。那位运营同学平时就是这个样子，办事也比较容易激动。当时她负责的活动别人不大看好，她一揽全局接下来，想做出成绩。更重要的是，她并不是对我一个人这样，而是所有人。将心比心，谁都可能有这样的时候。

其次是对“尊重”二字的理解。尊重体现的是修养，而非“交换”。好比，横穿马路就像一百人对自己骂娘一样感到耻辱。这是自发的。笑笑，说几句好听的；或是有确凿证据时指出对方的错误，再来一起解决，都有助于合作，最后达到产品预期。

对事认真。不做就说“不”，做就做好。做出来的东西怎样，和别人没关系，是对自己水平和能力的表现。字如其人可能玄乎，但产品如其人，就实实在在了。做不做得了，做得怎样，体现了自己多少价值，团队凝聚力何如，评论怎样，都凝结在产品里。

做好是底线。做产品非常重视积累。若立志做一款改变世界的产品，那么每一块铺路石都必须做到最好。