最长的一章,也是我最在意的一章——人和团队。
产品定义可以学、产品设计可以练、工程方法可以背——但人这件事,是产品成败的最深层因素。同样的方法论、同样的资源,放到不同的团队里,产出可以差十倍。这一章讲我对人和团队的所有判断。
先讲一件你必须想清楚的事——人为什么愿意做创新的事?
我观察过很多产品团队,做过一个非正式的统计——69% 的创新动力,来自内驱力;28% 来自外驱力;剩下的 3%,是各种偶然因素。
内驱力是什么?四个东西:自我实现、认同感、好奇心、价值感。
外驱力是什么?三个东西:钱、责任、KPI。
外驱力不是不重要——它是基础。但外驱力只能让人"达标",做不到"超越"。一个人愿意为了钱加班到 9 点,但很少有人愿意为了钱在凌晨 2 点突然想到一个好 idea 跳起来去做。后者要靠内驱力。
很多公司管理的逻辑是反过来的——他们以为 KPI 设得好、奖金算得清、责任压得到位,人就会创新。错了。KPI 和钱只能管"产出量",管不了"产出质"。一个 KPI 完美达成的团队,可以做出 100 个用户不要的功能;一个内驱力旺盛的团队,可以做出 1 个让用户感动的功能。
我那时候带团队,把至少一半的管理精力放在保护和滋养内驱力上——给团队成员自由度、给他们看到自己工作的影响、保护他们不被无意义的管理动作干扰、让他们之间相互认同。这些不是"虚的"——这是真金白银决定产出质量的事。
很多管理者会说,我团队的核心竞争力是——完整的思考、快速的学习、良好的沟通、杰出的技术、彼此的信任。
这些都好,但都不是核心。
产品团队的核心竞争力,就两个字——速度。
用最快的速度去迭代、去试错、去优化。
为什么是速度?因为产品的胜负,本质上是"谁先找到对的方向"。两个团队同样在摸索,谁能在更短的时间里完成更多次"试错-反馈-修正"循环,谁就先找到对的路。
技术比你强、思考比你深、沟通比你顺、信任比你紧——这些都很好,但如果你的迭代速度比对手快 3 倍,你的"思考完整度"在每一次迭代里都会被快速补足;反过来,对手再"完整",在你的速度面前也是一只笨重的恐龙。
我那时候反复跟团队讲——速度是第一战略,质量是速度的副产品。先保证速度,然后用反馈打磨质量。如果一开始就追求"完美",速度就没了,质量也跟着没了——因为没有真实反馈的"完美",就是闭门造车。
产品经理是我心里最有重量的一个岗位,也是最难的一个岗位。我列举几条我观察到的"残酷现实"——
第一,产品设计师最需要关注的用户,只有一类:初学者。
第五章讲过——初学者是决定产品命运的人。但初学者是非常非常难驾驭的。因为他们是普通人,没有任何培训就在用产品,他们的耐心比金子还稀薄,他们的反馈比石头还冷。无论是企业应用还是个人软件工具,都一样。
驾驭初学者,要的不是"功能更多",是"理解更深"——理解他们打开 APP 那一秒的认知状态、情绪状态、动作习惯。这种理解只能靠观察,不能靠想象。
第二,专业用户或熟练用户提出的需求,往往会导致产品复杂。
这一点反复念过——但还是要再讲一次。一个产品做久了,会聚拢一群"老用户"——他们用得熟、用得深、用得久。他们会给你提很多需求——加这个、加那个、改这个、改那个。
这些需求每一条都"合理",但它们的合理性是对老用户合理,对新用户不合理。你听他们的话,你的产品就一步一步变成只服务老用户的"专业工具"——新用户进来就懵。
我那时候有一条原则:老用户的需求,听 30% 就够了——一定要留 70% 的注意力给那些"还没说话"的用户——那些下载完试了一分钟就关掉的人。
第三,产品设计者随着做产品越深入,会逐渐演变成专业用户,离真实用户(初学者)越来越遥远。
这一条是产品经理的宿命。你做这个产品做了一年,你打开它的速度比新用户快 10 倍,你知道每个按钮的位置和每个交互的逻辑——你已经不能用新用户的眼睛看自己的产品了。
这一点很残酷,也很现实,是需要长期提醒自己的重要方面。我那时候每隔几个月就做一件事——让一个完全没接触过产品的新人,在我面前用我们的产品。不是为了得出什么结论,是为了强行让自己看到"陌生人眼里的产品长什么样"——这种"陌生感"我每次做都觉得震撼。原来这个按钮这么不明显、原来这个文案这么难懂、原来这个引导根本没人看。这些每一次都是新的发现。
第四,产品设计者对功能增加和组织有丰富的激情和熟练的技巧,对删除功能却普遍缺乏勇气和方法。
加是本能,删是反人性。一个产品经理,他做 PRD、画原型、设计交互——这些都是"加"的动作。但他什么时候真正问过自己:"哪一个功能可以从这个版本里删掉?"
很少。极少。
我那时候在团队里定过一条规矩——每个迭代,必须至少删掉一个功能或者一个界面元素。哪怕是个小东西,也要删。这条规矩执行下来,几个版本之后产品就开始变轻了——而且团队对"删"这件事的肌肉也建立起来了。
第五,大家对待简单就像梦中女神一样,渴望地直流口水,但谁也不敢上前拥抱;对待复杂就像嫌弃要饭的一样,唯恐避之不及,却每天跟她谈情说爱、眉来眼去。
这是我当年最爱说的一句话之一。
简单是大家公认的"好",但真正去做的时候,大家都怂——怕老板觉得你做得"少"、怕用户觉得"不够全"、怕竞品比下去。所以嘴上喊简单,手上一直在加。
复杂是大家公认的"不好",但每次开会都在讨论"还要加什么"——一边骂复杂,一边制造复杂。这种分裂在 99% 的团队里都存在。承认这种分裂,是第一步。然后下一步,要有人在团队里专门负责"减"——通常这个人就是产品负责人。
第六,视觉也是产品迭代中的重要部分,它是体验的一部分。
有些工程师只重视功能和算法迭代,觉得"视觉是设计师的事"——视觉永远拍后面排。结果就是,功能跑得很欢,视觉永远停在上一个版本——一个不更新视觉的产品永远见不到高频用户,因为它的第一眼就让人退缩。
视觉迭代要和功能迭代一样重要、一样有节奏。
第七,你可以外包开发、外包测试、外包财务、甚至外包老板——但客户体验,你绝对不要外包。
这条是底线。客户体验是产品团队的"灵魂"——它不能外包给任何人,包括最优秀的外包团队、最有名的设计公司、最豪华的咨询机构。
为什么?因为体验是无数个微小细节的累积——一个文案、一个动效、一个加载状态、一个错误提示——这些东西每一个都需要做产品的人对自己的产品、自己的用户有深度的感情和理解。外包的人不会有这种感情和理解——他没有义务有,他做完合同就走。
我见过太多公司的产品死于"外包了体验"——他们把交互设计外包给了一个 4A、把视觉外包给了一个工作室、把客服话术外包给了一个咨询公司——结果产品里里外外全是别人的口气,没有一丝自己的。这种产品没有灵魂,用户能感觉到。
第八,最残酷的现实——亲属、投资人、管理者、下属、客户……他们只会对好产品点赞,对烂产品无情地抛弃——仿佛从未见过。无论你多努力。
这句话写出来很冷,但它是真的。
产品的世界没有"同情分"。你加班加到吐血——用户不知道。你团队为了这个版本通宵三天——用户不知道。你为了一个细节跟设计师吵了七次架——用户不知道。用户只看到打开 APP 之后的那一刻——他喜欢,就用;不喜欢,就走。
这件事知道了之后,你会有两种反应——一种是觉得很委屈,觉得世界不公平,然后开始抱怨。另一种是接受这个现实,然后把所有精力放在"做出真的让用户用完之后会喜欢的东西"——只有这件事,是有意义的;其他所有的"努力",在用户那里都不算数。
我属于第二种。我接受这个残酷,因为只有接受了这个残酷,才能做出真正的好产品。
领导者在产品团队里干什么?三件事——指导、保护、激励。
指导:不是"指挥",是"指导"。指挥是命令,指导是引导。一个好的产品负责人,在团队遇到决策困难的时候,能用自己的判断帮团队选一个方向——不是替他们做决定,是帮他们看清楚。
保护:这一条最被低估。领导者最重要的工作之一,是把外部的干扰挡在团队外面。老板临时塞进来的需求、销售部要的新功能、运营部要的临时活动、合作方要的特殊接口——这些噪音如果直接传到团队,团队就废了。领导者是这堵防火墙——他要把噪音挡住、把价值高的东西放进来、把价值低的东西过滤掉。
激励:激励不是发奖金。激励是让团队成员看到自己工作的意义——他做的这个功能影响了多少用户、他写的这段代码省下了多少时间、他做的这个设计被多少同行称赞。这种"看到影响"的激励,比金钱激励持久得多。
设计师做什么?不是做 Mock up。
很多设计师,80% 的时间花在画 Mock up——画交互稿、画视觉稿、画动效稿。这些是产出物,但不是工作核心。
设计师的工作核心是这三件事——理解、归纳、拆分、简化需求。
做完这四步,Mock up 才是水到渠成的产出。绝大多数设计师跳过前四步,直接画 Mock up——画得很漂亮,但不能解决问题。这种设计师在工作三年之后,通常会撞到天花板,因为他们的能力建立在"画"上,而不建立在"想"上。
我归纳过优秀设计师的最重要的一个特质——对现状不满意。
不是抱怨型的不满意,是建设性的不满意——他看一个产品、一个界面、一个交互,本能反应是"这里有什么是可以做得更好的"。这种本能在他身上是 24 小时开机的,不分场景。
我那时候招设计师,面试我经常问的一个问题——给你一个你每天在用的 APP,你能不能在 5 分钟内,挑出 5 个让你不爽的细节?
不会的设计师,就是那些觉得"产品都挺好的"、"用户能用就行"、"差不多就够了"的人。这种人不应该做设计。 能在 5 分钟里挑出 10 个不爽的设计师,他可能有点钻牛角尖,但他对细节有真实的敏感度——这是他可以训练的天赋。
我宁愿招一个钻牛角尖的、有真实感觉的设计师,也不要一个温吞的、什么都行的设计师。
很多团队以为成就感来自——
这些都不是真正的成就感。这些是结果,不是源头。
我观察过真正有干劲的产品团队,他们的成就感来自一个东西——物尽其用。
"物尽其用"四个字,是说他们做出来的东西,被真的用了——而且用得很好、用得越来越多、用得越来越深。一个产品发版了,他们守着数据看用户在用什么、用了多久、有没有回来——看到自己做的东西真的在被人用、在改变别人的生活,这种成就感是任何奖金都换不来的。
反过来,你看那些被外部指标驱动的团队——他们做出来的功能上线了,看一眼数据,数据涨了就开庆功会,数据没涨就找借口。他们和自己的产品之间没有真实的感情联系。
有感情的团队和无感情的团队,做出来的产品有质的区别。
很多公司纠结"团队要不要在一起办公"。我的答案是——
重要的是有共同的产品目标,而不是共同的办公室。
这句话在 2015 年讲,是有点超前的——那时候大部分公司还坚持"必须坐在一起才能干活"。但我那时候已经看到一些远程协作做得很好的团队——他们靠的不是物理空间,是清晰的目标和文档化的沟通。
不是说在一起办公没有好处——咖啡间的偶遇、白板的现场涂改、午饭的随便聊天,这些都是有价值的。但这些价值在一个目标不清的团队里,毫无用处。
我见过太多团队,天天坐在一起,但每个人脑子里的"目标"都不一样——他们的协作是"假协作"。也见过一些分散在不同城市甚至不同国家的团队——但所有人对目标的理解高度一致——他们的协作反而更有效率。
物理空间是协作的"放大器",目标共识是协作的"基础"。没有基础,放大器越强,误差越大。
我对"牛人"两个字非常警惕——它经常被滥用,被用来标榜一些表面上很厉害但实际并不解决问题的人。
我对真正的"牛人",有一个非常朴素的定义——
他不停地在发现问题,他在不停地解决问题。
就这一句。
不发现问题的人,他做的事是按部就班——领到一个任务,做完,下一个。这种人能干活,但不"牛"。 发现问题但不解决的人,他在抱怨——他能指出 100 个不爽的地方,但不动手。这种人能给团队添堵,但不"牛"。 只有同时不停地"发现问题"和"解决问题"的人,才是真正的牛人——他们的内驱力旺盛、判断力清晰、行动力强大。这三件事缺一不可。
招人的时候,我看的就是这三件事——他能不能看到别人没看到的问题、能不能动手解决、能不能持续地做下去。这三件事都对,他就是牛人。
一个产品设计走到中段,经常会卡在某个问题上——这个功能怎么设计都不舒服、这个交互无论怎么改都别扭、这个流程怎么走都有 corner case。
这种时刻,99% 的团队会做的事——坐在会议室里头脑风暴,想各种花式方案。
我那时候的做法不一样——
不要在原方案上死磕,回到使用者目标。
具体说,两个动作——
第一,聚焦使用者目标。这个功能、这个界面、这个流程,最初是为什么用户的什么目标做的?走着走着,我们是不是已经偏离了那个目标,只是为了"把这个方案做完"而做?
第二,回顾使用者行为。真实用户在这个场景下到底怎么做的?他打开 APP 的第一秒在想什么、第三秒在做什么、卡住的时候是怎么反应的——把这些行为重新看一遍。
90% 的"难解问题",在做完这两个动作之后会自动消解——因为你会发现原来的方案本身就走偏了,正确的不是"在错的方案里继续打磨",是"回到目标重新选一个方案"。
这件事难在哪里?难在承认自己之前做错了。一个团队已经在某个方案上投了两周,你现在让他们"回到原点重选",大家会本能地抗拒——觉得这两周白干了。
我那时候经常跟团队说——两周的投入是沉没成本,真正的浪费是你为了不浪费这两周,再花六个月在错的方案上。
产品体验测试,看似最技术化的环节——其实最不技术化。
我用一个词来概括——直觉。
体验测试不是"按检查表打勾",不是"按 KPI 跑分",不是"按数据对比"。这些都有用,但不是核心。
体验测试的核心是,把产品递给一个真实的人,看他的反应——他皱眉的瞬间、他犹豫的瞬间、他笑出来的瞬间、他放下手机的瞬间——这些瞬间,你能不能感觉到、能不能理解、能不能转化成产品上的调整。
这是直觉的工作。它需要的不是流程,是经验加敏感度——长期看人用产品看出来的敏感度。
我那时候在团队里有一个"早期内测"环节,5-10 个早期用户,我自己跟他们聊、看他们用、记他们的反应。这些一手观察,比任何用研报告都有价值。直觉是从这些一手观察里长出来的。
这一节我可能要得罪人——其实在产品团队里,不需要项目经理这个岗位。
至少,不需要那种典型意义上的"项目经理"——画甘特图、追进度、开协调会的那种。
为什么?因为他做的事,产品经理 + 团队自己应该能做。
进度的把控,是迭代节拍内置的——节拍走起来,每一个角色自己就知道该交什么、什么时候交。 风险的识别,是产品经理 + 各个 lead 在每日站会和每个迭代复盘里自然完成的。 跨团队协调,是产品经理的核心职责之一。 依赖管理,是架构师 + 工程负责人的职责。
项目经理在中间能做的事,绝大部分是冗余的——他做的越多,反而越打断真实的协作。
那如果非要这个岗位,他应该做什么?——一个角色:Timer。
控制严格的迭代节奏,是产品团队共同要关心的。如果团队自己做不到,可以有一个 Timer——专门盯着节拍,确保发版日不偏移、迭代不拖延、关键节点不漏。这个角色权力很小,但价值不小。
注意——是 Timer,不是 Project Manager。Timer 关心节拍,不关心内容;关心 deadlines,不关心 trade-offs。这是两个完全不同的岗位。
最后,把我观察到的几个"屡试不爽的错误"放在一起讲——这些都是我反复在不同团队见过的,几乎每个团队都中过其中几个:
不断地做功能上的加法,从不做减法。 在设计上考虑得"完整一些",再"完整一些",最后做出一堆 nice-to-have 把产品压垮。 用商业目标替代使用者目标——把销售额、利润当成产品方向。 一年只发布一个"惊天地泣鬼神"的大作——慢周期 = 慢死亡。 相信市场调查——把问卷数据当真理。 以程序员为中心的产品管理组织——程序员是好工程师不等于他是好产品经理。 以老板的需求为核心的需求——老板是产品的最大风险来源之一。 让程序员根据自己的美术水平去做前端视觉设计。 没有设计,直接开发——这种产品上线后一定要返工三遍。 根据市场细分(segmentation)来定义产品——前面讲过了。 不得不依赖培训手册才能学会的产品。 根据竞品分析的优势列表来定义产品——你做出来的就是竞品的劣化版。 迷恋模版,迷恋高手——模版让你失去思考,高手让你失去判断。 不关注用户行为,关注用户语言。 给使用者过多的选择——选择越多,决策越难。 把自己的 Wants 当成客户的 Needs。 把客户说的 Needs,当成用户的 Use。 不收集反馈,或者反馈过晚。 过于复杂的交互设计。 过多的创意——一个产品做一个真正的创新已经够难,五个创新一起做就是灾难。 依赖项目经理。 跟大公司合作小产品——大公司的流程会把你这个小产品拖死。
这些错误,我每一个都见过——很多我自己也犯过。把它们列出来,不是为了让你"避免",而是为了让你下次开会的时候,当某一个错误又要出现时,有人能站起来,说一句"这个我们做过,不行"。
这种"团队记忆",是产品团队最珍贵的资产。
