編輯導語：作為産品經理，你是如何抽象功能設計的？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 協議。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部