編輯導語：産品思維對于産品經理來說十分重要，能夠有效提升工作效率和工作質量。本文作者分享了有關産品經理思維要素的相關内容，從思維誤區、思維方式建議、理性思維探讨展開分析，一起來學習一下吧，希望對你有幫助。

一、概述

1. 背景

先簡單說說為什麼寫這篇文章。

作為很久（其實也就兩三個月）沒有在産品前線工作的産品人，前幾天參加了幾場内部的産品内審會，發現少部分新入行或者入行時間3年以内的産品身上，有着不少的思維誤區。

需要說明的是，本文基于2B餐飲茶飲行業進行撰寫，不一定适用于其他行業及其他類型産品。

2. 思維誤區

對于産品經理必備的那些基礎技能，包括理解能力、邏輯分析能力、抽象思維、宏觀思維、自驅力、同理心、洞察力、溝通能力、創新能力、執行力、抗壓能力、學習能力等，這些網上寫爛了的，就不去花太多的文字進行詳細的描述了。

就從以上列出來的幾點，大部分靠的其實還是天賦及閱曆。

天賦這種事沒辦法解釋，有天賦的3天入門三年大成，沒天賦的，3個月入門，13年都不一定能大成。

再說閱曆，其實就是不斷的實踐、學習、提升，見得多了，做的多了，看的廣了，研究的深了，自然就從入門到初級到中級到高級到大牛了。

初級産品還算好一點，知道自己能力淺，說話小心翼翼，但是有些産品經理到了中級階段，就開始飄了，開口閉口就是我認為XXXX，我覺得XXXX，你們不要XXXX。

甚至有些産品做到高級層次，依然會有這種很奇怪的“我認為”思維。

我記得有句話說，不要用你以為的去揣測真實用戶的需求，那樣你隻會距離他們越來越遠。

他們為什麼會有這種想法呢？我很想說，這叫半瓶子晃蕩。

大部分人都會經曆這樣一個自我膨脹的階段，我也不例外，隻是我能夠迅速調整心态。

為什麼會這樣呢？做了幾年産品了，做的多了，見的多了，自以為能力已經非常強了，同理心已經融會貫通，洞察力已經深嵌思維了，拿着以往的經曆及片面的知識去肆意下結論了。

可怕的是，很多産品經理長期如此還不自知。

3. 心态變化

現在呢，很多公司，不論大小，都開始提拔年輕人擔任管理或者帶領小團隊，或許這些人在小團隊裡确實是優秀的，但對于整個産品市場來說，其實還是偏嫩一點。

提拔你，不是因為你特别強，而是你目前的能力可能比其他産品高那麼一點，也是認可你的潛力，培養你多方面的能力，你要做的是謙虛謹慎前行，但是有些人開始膨脹了，自認為能夠承擔這樣的角色是因為自己實力特别強。

是個産品總想把高級挂在頭銜上，回頭拿那些分析工具用在自己身上試試，是高級不？

一般來說，心态的變化會産生兩條很大的分裂方向，第一個是很快受到打擊，發現自己隻是矮子裡拔高的那一個，往遠處看，高個子一大堆，然後盡快調整自己提升自己（也可能自暴自棄了），第二個則是越發膨脹，除了自己，其他人都是渣渣，然後認為薪酬和實力不匹配，開始有了亂七八糟的心思，後續就不用細說了，明白的都明白。

我自己呢，也一樣經曆過這個階段，幸好打臉來的快，醒悟的早。

我又想起了一句話這麼說的：越學越覺得自己淺薄，越學越覺得自己啥都不會。

我現在就是這種狀态，說誇張一點就是如履薄冰了。

4. 業務邏輯主線

我以前做電商、現在做餐飲，但不論做什麼，很多業務邏輯是相通，就是所謂的殊途同歸，同樣的，随着國内各種行業開始數字化、物聯網化，業務邏輯線也越來越長。

你敢保證你整條業務鍊都懂嗎？我以餐飲舉例，簡單列一下吧：

1）基礎交易閉環

門店管理、商品管理、櫥窗管理、菜單管理（貨架）、定位判斷、業務類型（自提、堂食、外賣）、訂單管理（正逆向）、POS對接、支付/退款方式（微信、支付寶等）、硬件對接（自助點餐、自提櫃、小票機等）等；

2）會員管理

注冊來源、注冊方式、基礎信息、社會屬性、會員标簽、會員畫像，與訂單、消費信息（客單、頻率等）關聯，會員資産（積分、儲值、其他資産）、會員類型（普通、付費）、會員等級、會員權益等；

3）基礎營銷

卡券能力（優惠券、儲值卡、禮品卡、會員卡、體驗卡等），會員生命周期個階段營銷方式，基于券的營銷，基于活動的營銷，精準營銷（基于用戶标簽及畫像分析）等；

4）基礎财務

訂單/賬單對賬、門店分賬對賬、積分對賬、儲值卡對賬、優惠券對賬、分類賬、明細賬、依據對賬結果輸出的會計分錄，電子發票管理；這裡還存在兩個很有意思的場景，一個是多個品牌積分互通的财務轉換處理，一個是财務側視同銷售的活動營銷；

5）供應鍊管理

供應商管理、分公司管理、門店管理（直營和加盟的區分）、采購管理（成品、半成品、物料BOM、門店及分公司計劃采購）、倉儲庫存管理（門店/分公司上報、入庫、出庫、盤庫）、物流管理（供應商對總部、供應商對分公司/門店、總部對分公司/門店、分公司對門店）、銷售管理（總部對分公司、總部對門店、分公司對門店等、門店對用戶）、成本管理（商品成本、人工成本、水電房租成本、物流成本等）、财務管理（營收占比、利潤率、坪效分析、采購計劃金額、階段預算等）等；

6）對接管理

各種三方平台對接（美團、餓了麼等），各種配送及物流對接（達達、順豐、美團、餓了麼、快遞100等），各種支付對接（微信、支付寶、銀聯、聚合支付、銀行數字貨币），地圖對接（高德、百度、騰訊等）等；

7）數據管理

需要區分數據統一及基礎數據分析，數據統一包括數據的獲取（包括自有系統及三方平台）、源數據存儲（方便溯源）、數據清洗、數據标準化、數據存儲，數據歸類；基礎數據分析包括會員分析、訂單分析、商品分析、儲值分析、營銷分析、ROI分析、門店分析、各類業務環比同比分析、C端用戶體驗分析、B端使用分析、服務器算力分析、客單價分析等。

8）總結

先列這麼多吧，已經很多了。

一般來說，想搞一個行業TOP的SaaS系統，以上的産品能力至少要具備80%吧。

而且相互之間的關聯性極多，各種業務功能有着串聯、并聯以及交叉的複雜關系，當系統複雜度達到一定程度的時候，牽一發而動全身。

所以，活到老學到老是必須的。

再看上面一開始提出的産品經理基礎能力，如果想做好上面簡單的SaaS系統，你要具備什麼能力？好像都要有吧，而且還要紮實。

除了以上所列舉的内容之外，其他行業産品怎麼做？如何做到一法通萬法通？産品經理又區分很多類型，我所列的還是基礎行業，再往深了說，還有數據産品、AI産品、策略産品、物聯網産品、工業産品等等，你還玩得轉嗎？

所以，面對行業内卷越來越嚴重，基于産品經理基礎能力，我整理了幾條思維相關的建議。

二、思維方式建議

1. 歸類歸屬及分層

1）歸類及分層

歸類，顧名思義，把同類型的東西規整到一起。再深一點，還有必要的歸屬關系。

業務帶來需求，那麼業務如何歸類？

業務是一個比較寬泛的詞，在産品側，業務幾乎就是全部前端能力或體驗的代名詞了，比如外賣業務、自提業務等。

于是，很多甲方公司會設定一個業務部門，拆分很多業務組，比如采購業務組、營銷業務組、銷售業務組、外賣業務組、堂食業務組、會員業務組、支付業務組、卡券業務組等等。

同時呢，小一點的但關聯度高的業務也可能會合并到一個組裡，比如把卡券和營銷做合并，甚至把會員、卡券、營銷做合并，把外賣、堂食做合并等等。

所以，業務分類其實也很明朗了，盡可能的不做交叉歸類，基于業務類型進行歸類，比如：

點餐業務、支付業務、會員營銷業務、儲值業務（也有把儲值歸類到會員裡的）、數據業務、财務等。

當各業務歸類，且互相關聯形成閉環的時候，其需求歸類也就好做了。

基于業務歸類對需求進行歸類整理。

我遇到過很多需求清單寫的很亂的産品經理，第一條是會員的，第二條是點餐的，第三條是卡券的，第四條又是會員的，這樣來回交叉，經常會出現需求重複、需求相似的情況。

基于業務類型進行需求歸類時，能夠有效的杜絕需求重複或類同的情況，也能夠協助判斷需求的合理性、緊急程度等，有助于去僞存真，預設優先級，并可以基于歸類，對需求進行有效合并。

比如甲方業務側提了兩個需求，分别是會員積分獲取支持多方式多來源、積分增加手動發放功能（舉例内容，忽略是否為僞需求），那麼這兩個需求是否可以合并，相信任何一個産品經理都可以進行判斷了。

随後便是功能歸類，以會員為例，會員是一個大模塊，其子模塊包含了基礎信息、标簽信息、畫像、會員資産等，每一個子模塊下又會有下級模塊，比如會員資産下有積分、集點、卡、券等資産數據。

其歸類在會員屬性下，同時又有了分層關系，從主模塊會員到子模塊到具體功能，其實已經分了三層，從以上文字所述，各層直接泾渭分明，已經很清爽了，但是當你仔細思考時，你會發現一件很有意思的事，也是很多産品經理在做而不自知的事：

有歸類，但不準确。

舉個例子吧。

從管理後台，查看會員基本信息，在詳情頁，一般會這麼設計：

一看沒啥問題吧，簡要明确了會員的主要信息。

再往深了看，你給開發的時候，表也這麼寫的，如果會員信息多了呢？

會員基礎信息、會員資産信息、會員類型、會員權益。

看文字，有歸類，看字段，歸類去哪裡了？

可以想一想，後續做數據分析使用你數據的時候，你沒有歸類，是否會造成數據處理複雜度增加呢。

同時，我們也知道，前端展示的數據是服務端提供的。

那麼在産品設計時，你直接對信息進行歸類的話：

細節問題，有助于你結構化業務類型及需求，有助于開發能夠迅速理解需求及各層次關聯關系，有助于标簽匹配，有助于後續的數據分析。

換一個角度，仍以會員為例，某一個會員從注冊時間、注冊方式開始，到類型、等級、資産、權益、會員旅程等，經常在變化，如果能夠提前做好約束，拆分主表及子表，那麼數據更新時，動作小，對服務端資源的消耗是否會降低呢？

也有産品認為，太細了，這些歸類開發人員會做的，但是你保證你遇到的都是優秀的開發嗎？

出了問題，往前翻，是你的問題，不是他的問題。

有些産品又會說了，我隻提功能，提規範，太細的話精力不夠，時間不夠。

來吧，是個産品經理都應該為你設計的功能業務邏輯負責，你的邏輯不夠細，導緻資源浪費，降低産品效率，增加了服務成本，影響用戶體驗算不算你的？

這還隻是需求歸類及分層，再往下又是功能歸類了。

還以會員舉例。

查詢一個會員信息，需要幾步？

第一步登錄後台；

第二步進入會員模塊，一般默認進入的是列表頁；

第三步搜索會員ID或手機号或昵稱等均可，查出會員；

現在會員找到了，用了四步，标準流程嘛。再細一點，查詢會員某一次儲值贈送的券數據。

這個時候，你就要看會員詳情頁能不能看到詳細的儲值信息了。

第五步，會員詳情頁，點擊儲值記錄，進入儲值記錄頁面；

第六步，儲值記錄頁面，查找需要的儲值信息。

一般來說，很多産品經理做到這裡就結束了，想查贈送的券，需要對比時間，再去會員資産券包中查詢。

換一個思維呢，在這一條記錄加一個按鈕，查看詳情，展示本次充值的金額、充值方式、贈金、積分、送券等信息。

好了，看到了信息了，那麼記錄裡有就真的有了嗎？在券後面要不要加個按鈕跳轉到券包啊？積分後面要不要加個按鈕跳轉的積分記錄啊？贈金後面要不要加個按鈕跳轉到贈金記錄啊？金額後面要不要加個按鈕跳轉到金額變化記錄啊？是不是還要查一下儲值贈禮的活動信息和記錄是否一緻啊？

回到正題，功能歸類這樣做可以嗎？各個子功能交叉，資産又跟儲值交叉，儲值又跟營銷交叉。

來，再換個思維，這些是展示在Web端的數據，數據從數據庫拉取的，數據庫是表結構。

表結構你是做好歸類和分層的。

再想一想，這些功能交叉了嗎？沒有，隻是增加了跳轉而已。

這裡涉及到場景化問題了，具體怎麼做，要看這個功能是使用普遍性高不高，誰在用這個功能，業務人員還是運營？

這個例子不好舉，但從業務到需求到功能導數據的歸類及分層，其實在産品設計階段就做好了，在設計階段就需要搞清楚，功能如何做歸類，都适用于哪些人，多角色之間的功能兼容度做到什麼程度更合适，當産品功能越做越多，你一眼看過去感覺有些亂，但是透過現象看本質，底層的邏輯是順暢的，産品就是優秀的。

而頁面的設計取決用使用者的訴求。

你設計的産品頁面結構需求基于使用該産品的人員結構進行規劃，兜兜轉轉又回到了最初，業務人員提的需求，你進行了歸類及設計，最終開發完了，業務好用、運營好用、開發一目了然、數據歸類清晰層次分明，主表子表結構，又能夠有效的減少一張無限長的大表所帶來的冗雜繁複。

後續做優化、删減、擴展，是不是更好做了？

2）歸屬

再說開頭的歸屬關系。

沿用前面的例子，需求是會員積分獲取多方式多來源、積分增加手動發放功能，作為産品經理，很輕松就能列出很多獲取積分的方式，我們單拿手動增加積分的功能來說吧。

我曾經遇到過一種情況，因為特殊原因，需要給某一位或者某幾位會員增加積分的，當時負責的産品直接以下方結構增加。

第一種：

第二種：

在會員詳情頁積分數額後面，放了一個加号的icon，點擊彈窗：

從單一場景來說，似乎這麼做沒有問題。

換一個場景看看，積分清算、積分溯源、積分成本扣減時，這些沒有歸屬的積分産生的金錢成本誰來承擔？

在做積分消耗時，我們會把積分産生的成本歸屬到對應的門店、分公司或總部，那麼上面這個做法，應該誰來承擔？或者從操作員身份來判斷？需要繞幾個圈圈？如果操作員的歸類和分層沒做好無法區分或區分的難度大呢？

這裡，缺了一個歸屬。

我提了個建議：加一個歸屬門店字段，預設枚舉包括現有的全部門店、總部、分公司，如果總部和分公司字段在其他功能體系中都沒有，且隻支持門店歸屬，還可以開一個虛拟門店或多個虛拟門店，将積分歸屬到對應的虛拟門店。設定該業務能力權限，門店人員隻能選擇自己權限匹配的門店或者預設的虛拟門店。

這樣一來，做積分清算時，可以直接把這部分積分歸類到對應的門店，由相應的門店來承擔。

但是還有個問題，如果這部分積分需要多方同時承擔呢？如總部、分公司、門店各自承擔一部分？大家應該都知道該怎麼設計了，無非是指定數額或按比例。

舉這個例子，也是為了表明，在産品功能設計階段，歸屬關系的重要性。

所以，産品經理，是個細緻活。

2. 追根究底

這個點需要與實際場景做關聯。

不論你做的産品面對的是C端用戶還是B端用戶，你的需求都會有很多來源，作為産品經理，需要做好3件事：

需求歸類在上一段已經做了描述，就不細說了。

優先級判定應該基于目前産品的階段及需求内容進行判斷，比如大家常說的緊急重要、緊急不重要、重要不緊急、不重要不緊急等等。

重點說一下需求判斷，這一點，目前很多初中級産品可能會思考不足。

需求判斷最根本的目的是去剖析了解需求的核心目的，即透過需求看本質，找到最核心的根需求。判斷時，需代入相應的角色，如市場角色、使用者角色等。

找到需求的根本，可以實現2件事，第一去僞，第二定位。去僞自然是篩掉僞需求，定位是為了确定該需求的使用場景。

具體怎麼做呢？

結構化思考，該需求轉化成功能後，其作用是什麼？有無當前可替代的能力？有無類同的需求？

功能推演，将自己代入到實際使用者，梳理全部業務流程，包括正逆向，包括與周邊功能的關聯。

我們還以會員手動增加積分來舉例。

當提出這個需求後，第一步歸類到會員主業務、積分子業務模塊中。

第二步思考這個功能的作用，特殊場景下，為用戶增加積分，如某活動發放積分失敗補償、投訴及其他補償等，目的是為了保護用戶體驗，提升服務質量，同時，還需要考慮，這個功能一般誰來使用，可以是客服、運營、營銷、業務人員等。還需要考慮其他有可能産生該需求的場景。

第三步，找定位，尋根本，列關聯。積分補充能力，其涉及到了積分獲取方式，涉及到了積分發放歸屬，涉及到了積分獲取記錄，涉及到了積分來源溯源，涉及到了積分成本核算等。

如此，需求的追根究底算入門了。

3. 簡約而不簡單

設計時，頁面、功能、業務邏輯做的簡約，一目了然，不繁複。

簡約≠簡單，需要有深層次思考，考慮與周邊能力的關聯性、後續可持續的拓展性等。

再以會員舉例。

會員詳情頁很多的産品恨不得一股腦把所有信息都放進去，比如：

類似這些信息，在會員詳情頁一次性展示全了，且内容繁多。

一眼看去除了數據多一點，似乎沒什麼問題。

但，請靜下心想一想，誰，哪個角色需要看會員詳情信息，還要看到這麼多的數據？

業務、運營、營銷、客服？這些信息展示的目的是什麼？是為了讓需要的角色來查詢相關的信息的，那麼什麼角色會查呢？他必須一次性看到全部信息嗎？他是否能夠迅速從這麼多信息裡找出他所關心的信息呢？

那有沒有另一種可能，每個角色需要的信息也不一樣？

再考慮一個權限功能，之前的例子裡提到了手動增加積分可以在會員詳情進行配置，那麼這個權限限制了哪些角色？

反反複複又回到了上面的建議，歸類和分層。

對功能和字段歸類，對内容進行分層。

基于分層做權限，基于歸類區分主表及子表，默認展示主要信息，其他的不重要的，放到更細的下一層詳情裡。

那麼，當指定角色進入到該頁面時，看到是隻是十來個主要字段信息，再細的或者擴散的信息，點擊對應的字段名稱或數據前往下一層查看即可。

如此，在設計上符合歸類、分層、歸屬的思維，體驗上又簡約大方，核心信息一目了然。

故，簡約而不簡單。

4. 邏輯體驗

我們回想一下剛入行時被前輩一直叮囑的話：2C産品重體驗，2B産品重邏輯。

随着時代的進步，行業的發展，這句話要改一下了。不論是2C還是2B，都是體驗與邏輯性共存。

所以，我們産品需要從多維度思考業務邏輯及用戶體驗，多維度指的是用戶維度，用戶包含涉及産品的全部用戶（使用者、管理者），包括2C\2B\2G等。同時，在做産品設計時，同步考慮功能在服務端的執行效率，盡可能減少甚至杜絕浪費資源的做法。

再舉個例子：

某品牌需要給門店安裝兩台雲打印機，分别是标簽打印機和小票打印機，這兩台打印機均需要通過後台綁定到系統門店上，才能有效的給茶飲咖啡訂單打印杯貼标簽及訂單小票。

但是，這兩台雲打印機屬于不同的品牌，一個支持掃碼綁定，一個不支持。那麼，你在做綁定功能時，是怎麼做的呢？看看這兩種設定吧：

第一個方案：

1. 綁定打印機-選擇掃碼綁定-掃設備二維碼識别-識别成功-确認信息提交-綁定成功；
2. 綁定打印機-選擇掃碼綁定-掃設備二維碼識别-識别失敗-返回頁面2-手動綁定-進入頁面3配置信息并提交-綁定成功；
3. 綁定打印機-頁面2選擇手動綁定-進入頁面3配置信息并提交-綁定成功。

第二個方案：

1. 綁定打印機-進入頁面2選擇打印機品牌-進入頁面3掃碼識别-确認信息并提交-綁定成功；
2. 綁定打印機-進入頁面2選擇打印機品牌-填寫打印機信息并提交-綁定成功（支持掃碼的，在打印機ID行展示掃碼icon，不支持的不展示掃碼icon）。

從體驗和邏輯上來看，哪個方案更合理呢？

先說第一個方案，3層頁面關系，50%的幾率掃碼識别失敗，同時這失敗的50%需要調用服務端能力；再說第二個方案，2層頁面關系，基于預設打印機信息，判斷是否需要支持掃碼；

從體驗上來說，第一個方案頁面多，易掃碼失敗，用戶體驗差，第二個方案頁面少，掃碼失敗幾率低，用戶體驗好。

從邏輯上來說，第一個方案鍊路長度比第二個方案多一條，同時易錯率大于第二個方案。

忽略其他關聯性因素，純以上面這個功能來對比，個人建議方案二，體驗及邏輯的并存。

5. 關聯性反對思維

要做到避免蒙眼造需求，你以為的不一定是你以為的，你以為的，或許會降低産品效率且增加多重複雜問題，當你為某一個角色提供你所認為的輔助功能時，應考慮是否會對其他用戶甚至整個産品産生影響。

還可能會存在出了事故責任定位問題。

同樣，舉上面雲打印機的例子。

某産品害怕門店人員不會綁定雲打印機，打算在管理後台增加了遠程綁定功能，通過運營協助門店綁定打印機。

在面對這個主動需求時，我們提出了以下問題：

1. 如果運營綁錯了門店怎麼辦？
2. 第一個問題的延續，綁錯之後造成了業務失誤誰來承擔？
3. 如果是門店提供的信息錯誤導緻運營綁定錯誤該誰來承擔？
4. 如果所有門店知道能夠遠程綁定，都上報工單說自己不會，申請遠程綁定怎麼辦？
5. 如果門店操作硬件設備失誤，導緻遠程綁定一直不成功或錯誤，影響了運營的其他工作内容，又影響了自己門店甚至其他門店的營業，該怎麼處理？

包含且不僅僅是以上問題。

所以，産品經理在“造”需求時，或者在分辨類似的需求時，多思考，多判斷，多推演，學會質疑，學會反對。

三、理性思維探讨

1. 以小處着手、大處着眼，做到透過現象看本質，了解需求背後的意圖，找到需求的根；
2. 摸人性，從社會心理學角度去剖析用戶心理，提升同理心，有效基于人性優化産品力；
3. 明社會，閉門造車不可取，要了解社會現狀，緊跟實事，緊跟政策，别被大勢淘汰；
4. 鑒行業，緊盯競品甚至周邊産品，行業從來不是以一刀切的方式區分的，很多行業之間存在互通關聯關系，學會借鑒競品、借鑒類同行業做法再創新；
5. 把控細節、結構化思考、宏觀戰略組合拳模式打出去，定義産品核心戰略發展方向；
6. 抽象思維能力=無數次具象後的推演能力，多學習、多實踐、多思考、多複盤、舉一反三，形成自己的知識體系，才能夠在面對業務需求時，瞬間抽象出實現方法，即腦中有畫面，表達有條理。

本文由@ 白澤 原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。

,