做产品是有配方的，一个文章列表，一个文章详情，再加上一个用户系统，就可以做出一款最简单的资讯产品。有配方不代表就每个人都能做好，这跟有菜谱也不是每个人就能做好菜一样。想要做好产品，还需要产品经理对功能的设计有更深入的了解，要清楚用户传递的信息是什么。

有两位厨师，甲是家庭中掌勺的厨师，为10人提供美食，乙是米其林三星餐厅的主厨，为超过10000位客户提供美食。

现在，两人共同参加了一场厨艺比赛，优胜者将获得优秀厨师的称号，你认为，谁会获胜呢？

甲为家人掌厨，是业余厨师，乙为客人掌厨，是专业厨师，尽管两人都是厨师，都会做饭，但前者对美食的要求是健康，好吃，果腹，后者却是将美食视为一种艺术，视为一种创作。

只有一位优胜者的情况，获得优秀厨师称号的，只会是乙。

米其林是一家全球闻名，历史悠久的为餐厅做权威鉴定的机构，其将美食餐厅划分为三个星级，评级过程中相当严谨，近乎苛刻。

一星餐厅：值得去造访的餐厅，是同类饮食风格中特别优秀的餐厅。

二星餐厅：厨艺非常高明，值得绕远路去造访的餐厅。

三星餐厅：值得特别安排一趟旅程去造访的餐厅，有令人永志不忘的美味，值得坐飞机专程前去用餐。

01 “做”产品与“做好”产品

产品经理其实和厨师一样，功能就是我们使用的食材，将功能按照某种规则搭配在一起就成了“产 品”。严格上来讲，产品经理比厨师还要容易，因为最终“烹饪”环节是由开发团队完成，我们只需要进行功能的搭配，不需要“烹饪”。

且，现在的互联网市场比以前更加成熟，有很多“标配功能”，也有很多“标准规则”，这些公开的“配方”，让做产品变成了一件极为容易的事情，即使是一位行业外的人员，只要使用的产品足够多，使用产品的时间足够长，也可以按照自己的使用习惯，通过功能搭配的方法，做出一款产品。

一个文章列表，一个文章详情，再加上一个用户系统，就可以做出一款最简单的资讯产品。

但，做产品与做好产品，是两个截然不同的概念。

“做产品”只需要将产品可视化呈现出来，可以实现业务逻辑，系统可以运作，当用户执行某种功能操作时，能输出结果，就算是做出了一款产品。

“做好产品”却需要将产品视为影响大众的一种艺术，将我们对某种事物的理解，将我们对某个行业的理解，以产品的方式向用户进行传达，我们会经常思考，信息如何才能传递给更多的人？这些信息如何才能被用户正确地解读？如何确保这些信息在传递过程中不会发生变化？

这是一项能够对千百万，乃至上亿的用户产生直接影响的艺术。

做产品，会更关心如何实现某项功能。

做好一款产品，则需要驾驭功能，通过功能的设计达到我们想要达到的效果，但却不会被功能所束缚。

我们更关心功能是如何产生作用，功能会向用户传递哪些信息，关心这些信息对用户行为的影响。

02 功能的作用

公司有AB两款电商产品，A是一款新的电商产品，每天有10000人产生下单行为，其中有50人会购买多件商品，B是一款成熟的电商产品，每天同样有10000人产生下单行为，其中有5000人会购买多件商品。

本次迭代，公司只提供了8万开发预算，已知购物车需要5万的开发成本，且不能复用，产品总监向产品团队提出了一个疑问：

“我们应该在哪款产品实现购物车功能，才能让这项功能产生最大的作用呢？”

对于程序而言，相同功能运行的结果是相同的，不论是在A产品里，还是在B产品里，购物车功能运行的结果，都是允许用户一次性购买多件商品。

但，功能运行结果，不等同于功能的作用，为多少用户提供了某种特定服务，才是功能的作用。

通常情况，我们认为功能的作用与使用人数呈现正比关系，使用人数越多，功能作用越大，但这是一种后置的分析方法，是建立在功能已经实现后的对比分析，只具备复盘总结的意义，不具备前置的决策指导意义。

另一组关系对比，更适合对功能做前置的分析：

功能的作用与“潜在用户规模”成正比关系：潜在用户规模越大，功能的作用越大；潜在用户规模越小，功能的作用越小；潜在用户为0，或接近为0的功能，则不会产生作用。

产品里的每一位用户对产品的使用倾向会有些许差异，以电商为例，有的用户热衷优惠券购物，有的用户热衷秒杀，有的用户热衷团购，还有的热衷更加快捷的直接购物，这些功能被一部分用户使用，同时也被一部分用户弃用。

案例中，AB两款产品每天下单用户都是10000人，A产品每天有50人购买多件商品，B产品，每天有5000人购买多件商品。

产品用户相同，潜在用户规模却截然不同，购物车的作用就完全不同了。

这也意味着，评估功能是否会产生作用时，不能建立在产品有多少用户的基础上，而是要建立在功能有多少潜在用户的基础上。

并不是所有产品的用户，都是功能的用户，只有那些已经出现特定行为，遇到特定问题，对功能具备诉求的用户，才是功能的第一批用户。

03 向用户传递的信息

一款新上线的内容社区产品，每天有10000人使用，但产品上线时间太短，沉淀的内容只有5000 条。

这款产品没有向用户提供搜索功能，所以，经常会有用户向产品经理反馈，希望产品能上线搜索功能。

搜索功能的开发成本并不高，团队也完全有资源快速实现这项功能。

你是产品经理，你会怎么做呢?

做出判断之前，我们需要先思考一个问题，用户的需求是搜索功能? 还是搜索结果？

产品为用户提供的任何一项可操作的功能，都在向用户传递不同的信息，不论设计者是有意的，还是无意的，这些信息都将影响用户后续的使用行为。

为用户提供搜索功能，意味着用户可以使用搜索功能快速寻找自己想要阅读的内容，这是用户所理解的功能的作用，也是功能向用户传递的信息。

但这条信息并不完整，还需要加上功能的结果，才是完整的向用户传递的信息。

搜索功能有可能向用户传递出两种信息：“你可以搜索，并且，可以找到你想要查找的内容” 以及“你可以搜索，但找不到你想要查找的内容”。

如果是前者，这条信息将会拉近用户与产品的距离，会增加粘性和信任度，但，如果是后者，这条信息就会让用户感到失望，产生负面情绪，并且这个情绪还会和产品挂钩。

案例中的产品，如果满足了用户的需求，为用户提供了搜索功能，就是向用户传递出了第二种信息“你可以搜索，但找不到你想要查找的内容”，因为5000条内容，相对于10000用户对内容的搜索需求而言，显得微不足道。

功能的操作效果与功能的结果共同构成了向用户传递的信息，前者相当于信息的序言，类似于交流前的自我介绍一样，后者才是信息的正文，才是用户真正关心的，会对用户行为产生影响的内容。

由用户提出的搜索需求，实际上，也是对搜索结果的需求，而不是搜索这项功能，不能提供搜索结果的搜索功能，对于用户而言，没有任何意义。

现实工作中，设计者容易疏忽信息的正文部分，仅仅对信息的序言部分进行解读，似乎这些需求都是合理的需求，成本可控的情况，都是可以满足的需求。

然而，恰恰是提出这些需求的用户，在需求实现后会最先流失。

设计者与用户存在一个极大的信息偏差。

用户不知晓产品的完整情况，不知晓系统沉淀的内容只有5000条，不知晓即使实现了搜索功能，也无法找到自己想要寻找的内容。

这些，是只有设计者和开发者才知道的信息。

面对用户反馈的需求，或者其他来源的需求，产品从业者要意识到功能传递的完整信息，再根据这条信息做出理智的判断。

功能，即是用户需求的载体，同时，也是产品向用户传递信息的载体。

面对一些会传递出负面信息的功能，或者是一些我们无法驾驭的功能，无法准确控制信息内容的功能，需要有拒绝的勇气。

对于产品经理而言，拒绝是一项能力，并且是一项极为重要的能力。

#相关阅读#

产品经理的视觉设计

做产品，没有“标配功能”

产品的BUG——信息传递错误

#专栏作家#

枯叶，微信公众号：枯叶咖啡馆。人人都是产品经理专栏作家。9年经验产品经理，3年产品总监经验。擅长数据增长，商业模式。曾孵化过千万级用户规模的创业产品

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于CCO协议。