为什么写这篇手记

这本书，最早起笔于2012年。

这本书最早叫《产品管理手记 》，是我在产品设计、开发和项目管理过程当中的心得体会。最早这些东西都是我的工作日记，后来凑在一起，我才发现，不知不觉中他已经成为敏捷迭代的心法。

十多年过去，有些产品形态确实变了，那时候我们还在讨论 Apple App Store 审核周期，讨论“摇一摇”那一类创意。在那个年代我们惊讶于微信的诞生和快速迭代。

而今天，在AI的加持下，软件开发变得易如反掌。你可以用24小时开发一个苹果的App，并成功审核上线。

社会经济环境发生了变化，技术发生了变化，用户对象，发生了变化，但是打造产品的一些最基本的元素、原理、产品开发的本质规律没怎么变。

在产品开发过程当中，产品经理或者工程师会反复掉进的那些些坑，十多年前和十多年后，几乎一模一样。

为什么要写这个

有人跟我说过，在他们想象里，软件产品开发是一群极客藏在阴暗的角落，悄声无息地捣鼓些惊世骇俗的东西。

也有人天真地认为，有了一个好点子，再找几个软件工程师，就可以开发出誉满天下的 APP。还有一类人，常年浸淫在成熟业务里的管理者，忽视工程师本身的创造力，把大量注意力放在流程、模式、资本上，觉得产品自然会冒出来。

这些误解本质上是同一个东西：对软件这件“创造”出来的事的不理解，甚至是恐惧。

其实软件产品的设计和开发并不神秘。

它跟盖房子是同一种东西，是一件高度专业化分工、非常严肃的事情。

它涉及到千百个、几万个使用者的喜怒哀乐。所以打造产品，你必须用极其谦卑和敬畏的心态去对待，因为只要你有一点点傲慢，你都不会得到你想要的结果。

这是我做产品管理这些年最大的一条体感。

可是绝大多数团队不是这样的。“坑”已经成了很多设计师和工程师的宿命，大家在挖坑、跳坑、埋坑、逃坑的轮回里挣扎，项目紧的时候人手不够，闲的时候人员窝工，版本迭代周期越拖越长，交付一再延期，开发人员压力大、经常加班，但效率不升反降，产品好不容易交付了，业务需求又变了，不得不重新来过，再过半年，bug 暴雷，客户投诉，本来还算挣钱的项目，拖了几年，人困马乏，人走茶凉。

这些我都见过。我自己也曾经在里面症状。

Wow 与 Damn

看到任何一个产品，我心里总是会冒出两个词，Wow！或者 Damn it！。

我想其他做产品的人也经常会有这两种瞬间。 一种是 Wow！的瞬间，你看到一个用户第一次打开你做的东西，愣了一下，然后笑了。你看到 App Store 上有人留言说“这玩意儿救了我”。你的同行私下问你这个细节是怎么想到的。这种瞬间很短，但它是真正有价值的东西，是你做这一行还在坚持的原因。

另一种是 Damn it！的瞬间，更多。

是上线前一天发现一个核心逻辑彻底错了。是 CEO 临时塞进来一个需求，说“这个简单嘛你顺手做一下”。

是设计师交上来的稿子你看了一眼就知道用户根本看不懂。

是测试的同事跟你说昨天那个 bug 没修复完今天又复现了。

这本笔记记录了我的心路历程，也是写给这两种瞬间之间所有的人，你看到过 Wow 是什么样子了，但你每天还在 Damn it 里挣扎，这中间有些可以掌握的规律。我相信是有的。

高层不懂、中层不敢、基层不会

我做产品这么多年，见过最多的尴尬的局面，高层不懂，中层不敢，基层不会。

高层是真不懂产品。他们之前可能是销售出身、是财务出身、是做大客户关系出身，他们对“产品”这两个字的理解就是“销售额”和“市场份额”。所以他们说出来的需求，要么是“做大”，要么是“全”，要么是“对标”。

中层最难。中层手里有人有预算，他知道老板的话不对，他也知道下面真正该做的是什么。但他不敢说。

他要的是绩效、是不出错、是不被砍掉。所以中层最擅长的事情，是把高层的话翻译成下面能执行的指令，但他不会顶上去。

基层是真的不会。他刚入行，他还没有见过好产品是怎么打磨出来的。他每天处理的就是一个又一个具体的工单，把这个按钮挪一下，把那个文案改一下。

没人教他怎么从用户目标出发。他甚至不知道有“用户目标”这个东西的存在。

这三层加在一起，等于一台无法运转的机器。这个机器上的三个重要的齿轮很难严丝合缝的咬合在一起。我见过的烂产品，80% 无一不是跟组织的能力有关系。

这本手记是我自己积累的一点对抗这些现实的笔记。它分四块：产品定义、产品设计与创意、产品开发管理、人才与团队。

我从“什么是失败的产品”开始讲，讲到“99% 的烂产品始于复杂”，讲到怎么定义产品、怎么研究用户、怎么调研需求、怎么做迭代、怎么管研发、怎么带团队。

它算不上工具书，我没有打算把它写成一本谁都能照着抄的手册。它更像是我自己在过去这些年里反复跟自己讲、跟团队讲的那些话。如果它里面有任何一句话，能让你少走一点弯路，我就心满意足了。