做產品是有配方的，一個文章列表，一個文章詳情，再加上一個用戶系統，就可以做出一款最簡單的資訊產品。有配方不代表就每個人都能做好，這跟有菜譜也不是每個人就能做好菜一樣。想要做好產品，還需要產品經理對功能的設計有更深入的瞭解，要清楚用戶傳遞的信息是什麼。

有兩位廚師，甲是家庭中掌勺的廚師，爲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條，不知曉即使實現了搜索功能，也無法找到自己想要尋找的內容。

這些，是隻有設計者和開發者才知道的信息。

面對用戶反饋的需求，或者其他來源的需求，產品從業者要意識到功能傳遞的完整信息，再根據這條信息做出理智的判斷。

功能，即是用戶需求的載體，同時，也是產品向用戶傳遞信息的載體。

面對一些會傳遞出負面信息的功能，或者是一些我們無法駕馭的功能，無法準確控制信息內容的功能，需要有拒絕的勇氣。

對於產品經理而言，拒絕是一項能力，並且是一項極爲重要的能力。