前两章讲的是"什么不是好产品"。这一章正面回答——什么是产品,什么是好产品,什么是真正的需求,什么叫刚需。
我用一句话来定义产品:产品是制造出来、能满足人们某种需求的东西——它可以是有形的物品,可以是无形的服务,可以是一个组织,可以是一种观念,也可以是它们的组合。
这个定义看起来很泛。这是有意的。
太多人一说"产品",脑子里就只有"软件 APP"。但你做过产品就会知道,软件 APP 只是产品的一种壳子。同样是一个打车这件事,有的团队做出来是 APP,有的团队做出来是一个微信小程序,有的团队做出来是一通电话热线——它们的"产品"本质是同一件事:把一个人送到他想去的地方。壳子不同,产品的内核可以是一样的。
把产品想成"东西"是一种很狭窄的视角。产品其实是一种"关系"——是你和你的用户之间,围绕某个需求,达成的一种契约。这个契约里你的承诺是什么、你的兑现是什么、你出问题时的补救是什么——这些加在一起,才是你的产品。
这也是为什么我后面会反复强调"用户目标"。因为产品的本质是回应用户的目标,不是承载功能的容器。
好产品有两个标准——一个商业标准,一个用户标准。
商业上,好产品的标准很硬:销售额、利润、规模。这三件事不是脏字,不要避讳——一个产品养不活自己,它就没有持续做下去的资格。我见过太多团队拒绝谈商业,他们觉得谈钱伤感情、谈钱不"产品"。这种态度其实是不负责任的——你做这个东西消耗了团队几个月甚至几年,它如果连自己的成本都赚不回来,它就不该被做出来。
用户那边,好产品的标准是三个字:可用、易用、乐用。
可用是说它能解决问题。这是最低标准。一个备忘录,能记下文字,可用。
易用是说用户不需要培训就能上手。这一条 99% 的产品过不了。我每次拿一个新产品给身边完全不懂技术的家人朋友试一下,90% 的产品在三分钟之内就会有人问我"这个怎么搞"——这就已经不易用了。
乐用是最高境界。它是说用户用完了不只是完成了任务,他还想下次再用。他会在心里给你打一个标记——"这玩意儿挺顺"。这种感觉是最难做出来的,因为它不是某个功能造成的,它是产品所有细节累加起来的一种总体感受。一个动效的节奏、一个文案的语气、一个加载状态的设计、一个错误提示的人性化——任何一个细节足够好,都能让产品往"乐用"那边推一小步。
商业上成功,用户那边喜爱。这两件事不冲突。一个真正的好产品,两件事一起做到。一个产品如果只在商业上成功,但用户那边骂声一片,它撑不过两年——这种例子我见过太多。反过来,用户那边喜爱但商业上死掉的产品,也是悲剧——它做到了被人爱,却没活下来。
什么是产品需求?
我喜欢用一个特别小的例子来讲——"运动时听音乐"和"休息时听音乐"。
这两件事看上去都是"听音乐",底下其实是两个完全不同的产品需求。
运动的时候,我对音乐的要求是:节奏稳、动感强、切歌方便、最好能戴在耳朵上不掉、出汗了也不会有问题、操作的时候我手是湿的甚至带着手套也能点。我对歌词没有要求——我跑步的时候哪有空看歌词?我对发现新歌也没有什么强烈的兴趣,我要的是稳定持续地给我一个 BPM 区间的歌。
休息的时候,完全反过来。我躺着,我可能在看书,可能在发呆。我对节奏的要求是慢、是松弛、是有空隙。我对歌词反而很在意——我可能会闭着眼睛把整首歌的歌词在心里过一遍。我喜欢被推荐——给我点没听过的、安静的东西。
同一个用户、同一件事("听音乐"),在两个场景下,他的产品需求几乎是相反的。
我讲这个例子是想说:功能、特性、指标——这些都不是真正的需求。真正的需求是被场景决定的。同一个用户在不同场景下,他要的是不同的东西。你做一个音乐产品,如果你只看"用户在听歌"这一层,你做出来的东西就是平的——它在跑步的时候不好用,在睡前也不好用。
这件事是产品定义的起点——不是从功能列表出发,而是从一个具体的用户、在一个具体的场景下、要解决一个具体的问题出发。
"刚需"这个词被用得太烂了。每个 BP 上都写着"我们解决用户的刚需",但真的去看,大部分都不是。
我自己有一个特别简单的定义:刚需就是,你满足了,他不一定会笑;你要是不满足,他肯定会哭。
吃饭是刚需。睡觉是刚需。喝水是刚需。手机有信号是刚需。地铁能在该停的地方停是刚需。这些东西你给到了,用户不会感激涕零——他认为这是理所当然的。但你哪天没给到,他立刻翻脸。
打车软件能把车叫来,刚需。叫不来,刚需变事故。 报销系统能让我把钱拿到手,刚需。拿不到,刚需变愤怒。 邮箱能把邮件发出去,刚需。发不出去,刚需变投诉。
这些都是刚需的样子——你做对了,用户面无表情;你做错了,用户雷霆万钧。
跟刚需相对的,是"伪需求"或者"想要"。"我希望这个 APP 多一个夜间模式"——这不是刚需,这是 nice-to-have。"我希望这个聊天工具能撤回 24 小时前的消息"——这不是刚需,这是少数高频用户的痒点。这两种东西不是不该做,但你不要把"想要"误认成"刚需"。一个产品如果把太多"想要"当成"刚需"去满足,它会快速变重、变慢、变乱。
我那时候在团队里,每次有人提一个新功能,我都让他回答两个问题:第一,这个东西没有的时候,用户会不会哭?第二,这个东西做出来,用户会不会笑?
如果两个都不会,那这个功能就根本不该做。 如果只满足了第二个会笑,但第一个不会哭——做,但不优先。 如果两个都满足,那就是刚需,立刻排进迭代。
这个判断方法简单到可以拿出来给团队当框架用。它的难处不在判断本身,而在你愿不愿意承认——你提的很多东西,其实没人哭,也没人笑。你只是自己觉得它"应该有"。
承认这一点,是做产品最难的一关。