这份手记是十年前的我写的。准确说,是 2015 年夏天的那个我。那时候我每天都在一个产品上较劲,一边带团队、一边自己也下场画原型、改文案,常常半夜还在改一个按钮的位置。这份东西最早叫《产品管理手记 8.3》——8.3 是因为它前面已经有过 7 个迭代版本,是我自己一个人在公司内部不断改、不断在新人入职会上讲出来的稿子。
放到这里,我没有改它的语气。十年过去,有些产品形态确实变了——那时候我们还在讨论 Apple App Store 审核周期,讨论"摇一摇"那一类基于陀螺仪的创意——但产品这件事本身的规律没怎么变。一个人,夜以继日打造另一群人会喜欢的东西,这中间会反复掉进哪些坑,十年前和十年后,几乎一模一样。
有人跟我说过,在他们想象里,软件产品开发是一群极客藏在阴暗的角落悄声无息地捣鼓些惊世骇俗的东西。也有人天真地认为,有了一个好点子,再找几个软件工程师,就可以开发出誉满天下的 APP。还有一类人——常年浸淫在成熟业务里的管理者——忽视工程师本身的创造力,把大量注意力放在流程、模式、资本上,觉得产品自然会冒出来。
这些误解本质上是同一个东西:对软件这件"创造"出来的事的不理解,甚至是恐惧。
其实软件产品的设计和开发并不神秘。它跟盖房子是同一种东西——是一件高度专业化分工、非常严肃的事情。它涉及到千百个、几万个使用者的喜怒哀乐。所以打造产品,你必须用极其谦卑和敬畏的心态去对待,因为只要你有一点点傲慢,你都不会得到你想要的结果。这是我做产品这些年最大的一条体感。
可是绝大多数团队不是这样的。"坑"已经成了很多设计师和工程师的宿命,大家在挖坑、跳坑、埋坑、逃坑的轮回里挣扎——项目紧的时候人手不够,闲的时候人员窝工;版本迭代周期越拖越长,交付一再延期;开发人员压力大、经常加班,但效率不升反降;产品好不容易交付了,业务需求又变了,不得不重新来过;再过半年,bug 暴雷,客户投诉;本来还算挣钱的项目,拖了几年,人困马乏,人走茶凉。
这些我都见过。我自己也曾经在里面。
我后来给我们团队总结过两个词,Wow! 和 Damn it!。
做产品的人有两种瞬间。 一种是 Wow! 的瞬间——你看到一个用户第一次打开你做的东西,愣了一下,然后笑了。你看到 App Store 上有人留言说"这玩意儿救了我"。你的同行私下问你这个细节是怎么想到的。这种瞬间很短,但它是真东西,是你做这一行还在坚持的原因。
另一种是 Damn it! 的瞬间——更多。是上线前一天发现一个核心逻辑彻底错了。是 CEO 临时塞进来一个需求,说"这个简单嘛你顺手做一下"。是设计师交上来的稿子你看了一眼就知道用户根本看不懂。是测试的同事跟你说昨天那个 bug 没修复完今天又复现了。
这本东西大概就是写给这两种瞬间之间所有的人——你已经看到过 Wow 是什么样子了,但你每天还在 Damn it 里挣扎,你想知道这中间有没有一些可以学的规律。我相信是有的。
我做产品这么多年,见过最多的一种死法——高层不懂,中层不敢,基层不会。
高层是真不懂产品。他们之前可能是销售出身、是财务出身、是做大客户关系出身,他们对"产品"这两个字的理解就是"销售额"和"市场份额"。所以他们说出来的需求,要么是"做大",要么是"全",要么是"对标"。
中层最难。中层手里有人有预算,他知道老板的话不对,他也知道下面真正该做的是什么。但他不敢说。因为他要的是绩效、是不出错、是不被砍掉。所以中层最擅长的事情,是把高层的话翻译成下面能执行的指令,但他不会顶上去。
基层是真的不会。他刚入行,他还没有见过好产品是怎么打磨出来的。他每天处理的就是一个又一个具体的工单——把这个按钮挪一下,把那个文案改一下。没人教他怎么从用户目标出发。他甚至不知道有"用户目标"这个东西的存在。
这三层加在一起,等于一台报废机器。我见过的烂产品,80% 死在这上面。
这本手记是我自己积累的一点抵抗这种死法的笔记。它分四块:产品定义、产品设计与创意、产品开发管理、人才与团队。从"什么是失败的产品"开始讲,讲到"99% 的烂产品始于复杂",讲到怎么定义产品、怎么研究用户、怎么调研需求、怎么做迭代、怎么管研发、怎么带团队。
它不是工具书,我没有打算把它写成一本谁都能照着抄的手册。它更像是我自己在过去这些年里反复跟自己讲、跟团队讲的那些话。如果它里面有任何一句话,能让你少走一点弯路,我就心满意足了。