編輯導語：作為產品經理，你是如何抽象功能設計的？B端場景與C端場景下的抽象產品功能設計，又有哪些不一樣的思路？假如這類問題出現在面試場景中，你該如何拆解和應答？本篇文章裡，作者就該問題進行了解答，一起來看看吧。

面試官發問：請你以一個專案為例，談談你是如何抽象功能設計的？這是面試中非常常見的場景，面試初中高階的產品崗大機率會遇到的問題。

以前看過一個很牛的自媒體的主理人說，我每天堅持輸出一篇高質量內容，還要做社群運營，大家覺得我好像無所不知，相關的問題都能信手拈來。其實並沒有什麼高深的技巧，我只是提前把可能遇到的問題思考過了，剩下的都是開卷考試。面試也是如此，不打無準備之仗。

接下來文章從3個方面和大家聊一聊這個問題可以怎麼答，並在文章末位附有實操案例。這是我個人的答題思路，歡迎拍磚交流（本文立足於B端產品的面試場景）。

一、面試官考察的重點是什麼？

大家要認識到一點，在面試現場提出的任何問題，都是有考察成分的。哪怕你們聊得很愉快，聊起了生活與家庭，氛圍很融洽，實際上你說的話都會有意無意被面試官放到審視的位置。

所以提前對面試官的問題做好分類思考，在面試過程中保持思路清晰，是一種有效的策略。

比如此問題，我認為面試官主要考察幾個方面：

1. 考察抽象思維能力

B 端和 C 端在產品設計上，有一些差異點。C 端要求洞悉使用者心智，瞭解使用者畫像，使用者群體相對單一，決策人即為使用人。

而B端的需求提出人和最終使用者很可能不是同一個人，B 端產品在日常工作中更多的是整合各類崗位的訴求、抽象業務場景做標準化的設計，需求的複雜度高於 C 端的單一場景。因此面試官很看重 B 端產品的抽象設計能力。

但是抽象的東西不好表達，所以要從專案立足闡述抽象的思路和結果。個人認為B端的抽象設計能力與 C 端的創新想象力有異曲同工之妙。

2. 考察專案覆盤能力

對比專案實踐，專案覆盤帶來的成長更是倍數級的。經常做覆盤的人應該有這種感受，某個時刻，腦袋豁然開朗，很多業務場景和訴求都串聯起來了，一下子都明白了問題的本質所在。

而沒有覆盤習慣的人，碰到這類問題會當場傻了，也許在心裡嘀咕：我也就憑感覺、憑經驗做的，沒想很多啊。容易在回答時陷入細節，直接講述當時接到了什麼需求，然後做了什麼功能，導致答題的思維高度不夠。

3. 考察方法論的沉澱

而方法論的輸出，說明你的專案沉澱到了足夠的深度，而且把踩過的坑總結成為了一套邏輯自洽的心法，大機率在以後的工作中能幫助你避開很多不必要的麻煩。大家在工作中可以觀察有邏輯做事的人和憑感覺拍腦袋做事的人，在出方案的效率與執行結果上，有非常大的差距。

某運營大神在人才選拔上有一個深刻的見解，他認為識別人才，可以從三個層次去區分。

第一層次的人才是“野生純天然”，這一層強調企業和平臺背書的作用，可能在相同的環境下去做同樣的事情，誰都能拿到不錯的結果；第二層次的人才是“見過好體系”，就是在業界得到了基本的學習和鍛鍊，有系統的方法論；第三層次的人才是“建過好體系”，能因地制宜地做好體系設計。

我們避免成為第一類，離開了平臺你什麼都不是；我們立志成為第三類；但是在面試中大多數的情況，需要有技巧地展現我們屬於第二類人才。讓面試官明白，系統的方法論能幫助企業避開不必要的坑。

一個有抽象思維、有覆盤思考習慣、有能複用的方法論的人才，誰不愛呢？

4. 從這個話題切入，瞭解更多的專案細節，鑑別專案真偽和實踐深度

這個出發點就好比面試開場就要求做自我介紹一樣，初次見面的陌生人，總得找點共同話題交流吧。最好的共同話題就是專案本身了，專案容易造假，加水分，但是細節是很難注水的。一般針對專案連續問 4-5 個問題，有水分的人基本就進行不下去了。

所以在面試中，切記從實際出發，可以從思維高度上去包裝，但不要無中生有。有人就問了，我的專案經驗不足，不注水要怎麼答啊。看下去，下文給你真誠作答的加分思路。

二、解題的思路是什麼？

回到最開始的問題，請你以一個專案為例，談談你是如何抽象功能設計的？4步走解決這個問題。

1. 5why原則深挖業務當前的痛點，並與多方業務人員交談提取需求共性

在開始之前先介紹專案的背景是基本的禮貌，面試官不一定是本行業的從業人員，對你公司的業務模式也沒有深刻的瞭解。先說明專案背景，有利於在共同認知基礎上開展對話。

鑑於B端業務的跨部門，跨角色，一個需求的提出，往往有錯綜複雜的歷史因素。所以抽象需求的要點是透過多方交談，提取需求共性。經典的5why 原則是經證實的有效、簡單、實操性強的“刨根問底”的方式。在答題的時候，可以詳細說明自己推理的思路。

2. 參考行業內的標準化解決方案

王戴明老師在他的《SaaS產品經理：從菜鳥到專家》一書中提出，學習的方式有：向自己學、向他人學、向書本學、向標杆學。

向自己學適用於專案的覆盤與總結，遇到新的問題的時候，我們可以參考向他人和標杆學習。業內領頭羊的實施方案，已經成功驗證了商業邏輯是成立的，告訴我們此路已通。

特別是B端內研系統的產品，不應僅僅侷限於解決眼前的問題，這樣會讓我們只能做到60分及格。而是應該放開視野，看看商業化產品的的解決方案是如何設計的，推敲背後的業務邏輯和市場機會，有利於設計靈活而強大的產品架構，瞭解當前設計方案的侷限性與邊界，從60分做到80分。

例如許可權的設計，在行業內有很成熟的解決方案。無非是使用者、角色、許可權（資料許可權，功能許可權）的關係，根據專案的複雜度還會涉及使用者組、角色組、組織架構關係。

瞭解Oracle、Salesforce等跨國軟體的許可權架構，可以讓我們清晰認識到複雜業務的頂級設計方案，但是不意味著我們的專案就需要用到這麼高階的許可權架構。也許最簡單的使用者 + 許可權在當前的專案階段就已夠用。

3. 解決方案梳理並輸出原型，與相關方溝通、確認

行業內的頂級解決方案可提供思考方向的參考，但方案的設計需要結合自身的專案狀況，考慮實際落地的策略。B端產品在尋找競品解決方案有一定的門檻，並不一定能找到可參考的案例，但是解決問題的底層邏輯都是相通的。

另外在設計原型、輸出解決方案（流程圖、文字描述等）的過程中，我們可以排查將來研發或者上線推廣的障礙點，提前與研發團隊的小夥伴們，業務相關方溝通、確認。和業務方確認原型是比較重要的一步，有條件的情況下可以進行demo演示操作，或者按照場景演示demo，確認方案能否解決他們遇到的問題。

這三步操作中，比較有難度的就是在提取需求共性上，初入門的小夥伴們往往會被業務部門五花八門的需求弄暈，業務要啥就做啥。如果有持續的思考和行業案例積累，輸出適合自身業務的標準化解決方案就是手到擒來的事情了。

三、加分亮點

如果你覺得以上的作答毫無亮點，或者底氣不足，可以從這2個方面補充一下。

1. 上線結果反饋，主動反思是否達到預期，是否有調整空間

其實無論是專案介紹還是功能的抽象設計，都可以用這樣的思路來回答，典型的STAR原則（情形、任務、行動、結果）或者PDCA原則，這也是反映我們專案覆盤能力的一種策略。

大機率上，面試官對你上文的作答感興趣，也會繼續追問當時抽象設計的功能，最終效果怎麼樣？如果再做一遍，你會怎麼做？可以做得更好嗎？

2。 對於沒上線的功能，給出規劃和實施的思路，以及說明方案潛在的風險與難點

如果你深度參與業務並反思了業務的瓶頸，一定會規劃了不少功能，希望幫助公司解決問題。也有可能有些功能做了，因為種種原因沒有上線。

在遇到本文“抽象功能設計”的問題而又沒有更好的案例時，可以選擇這種答題思路。把你對業務的觀察、調研推理思路、產品規劃和落地策略一一剖析給面試官，展示你的產品思維、業務思維亮點。

四、案例實操

面試官：請你以一個專案為例，談談你是如何抽象功能設計的？

作答：

我們公司主營服飾、珠寶私域電商業務，企業私域直播為主要的營銷渠道。

大致的業務流程是：買手和運營部門負責日常商品與直播場次選品，銷售透過微信為客戶1V1提供服飾搭配、直播導購、代下單、售後等一條龍服務，這種服務形式和公司的客戶群體為50歲以上的中老年女性有關。

企業內部的OMS系統支撐著業務的運作，其中商品管理模組連結了買手、銷售這兩個角色：買手推薦給銷售的商品會出現在這個列表，銷售日常會在列表中搜索商品，幫客戶搭配導購或者直接代下單（業務背景介紹）。

在與業務對接的過程中，我發現銷售總是要加一些查詢條件，比如尺寸、顏色、價格，方便他們快速找到某款商品。而買手提出的需求是關於商品排序方面的，比如直播主推標記的商品要排在首頁，新款商品也要排在首頁。

接到需求的時候我準備按照銷售的要求加查詢條件，但直覺這一方案並不能解決實際的問題。於是我開始追問他們具體的業務場景：

1）問銷售：

為什麼要查商品的尺寸資訊？

查詢出來的結果是否滿意？

大多數場景下能快速找到自己想要的商品嗎？

2）問買手：

為什麼要讓主推和新品排在首頁，而不是按照商品的上架時間來排序？

為什麼主推商品權重大於新品？

為什麼關注商品的備註資訊？（深挖業務痛點）

最終根據多方資訊的反饋和交叉對比，我提取出了1個核心觀點：該模組承擔著“根據既定目標快速檢索商品”和“主動推薦合適商品，提升轉化效率”的目標。如果把立即購買理解為 C 端的商城，這個模組要達成的目標就是：

提升【人找貨】以及【貨找人】的效率

（提取業務需求共性）。

於是我將需求規劃為2個階段：

第一階段提升人找貨的效率，具體實施措施包括擴大商品搜尋的範圍，不僅僅侷限於銷售提出的查詢條件；以及商品按照買手的規則和常用的電商商城規則重新排序，讓優質的商品排列在最前面，獲得最大的曝光。

第二階段，可以根據客戶的畫像智慧推薦相關的商品，提升客單價和轉化率。但是介於系統內的歷史因素，要達到這一步有一些難度，需要提前在相關介面中埋點、蒐集資料，再做下一步的迭代（參考行業標準化方案）。

第一階段的規劃落到原型上非常簡單，但是所有業務部門看過後都讚口不絕，催促快速開發上線。至此我認為功能的抽象設計已經達成了階段性的勝利，接下來就是觀察上線結果是否符合預期了（原型、方案確認）。

本文由@RaRa 原創釋出於人人都是產品經理。未經許可，禁止轉載。

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