面試產(chǎn)品經(jīng)理的時候需要向面試官展現(xiàn)自己的產(chǎn)品能力，建議提前對應(yīng)聘崗位的產(chǎn)品進(jìn)行分析總結(jié)。

初級產(chǎn)品經(jīng)理的能力往往是設(shè)計(jì)功能，高級產(chǎn)品經(jīng)理的能力往往是設(shè)計(jì)功能和產(chǎn)品架構(gòu)，資深產(chǎn)品經(jīng)理或者產(chǎn)品總監(jiān)更多的是對業(yè)務(wù)的理解以及能夠帶領(lǐng)團(tuán)隊(duì)完成公司既定的業(yè)務(wù)目標(biāo)。

大部分產(chǎn)品經(jīng)理的主要工作就是設(shè)計(jì)功能，那么把應(yīng)聘崗位對應(yīng)產(chǎn)品的功能改進(jìn)寫出來，到時候講給面試官聽，很方便評估你的產(chǎn)品能力高低，以及和他們崗位的匹配程度。

我一般將功能需求分為三大類型：修復(fù)BUG、優(yōu)化已有功能、設(shè)計(jì)新功能。接下來以易果生鮮APP作為案例講解，下面具體闡述：

發(fā)現(xiàn)產(chǎn)品的BUG需要的是細(xì)心，難度并不高?；ù罅繒r間來使用對方產(chǎn)品，研究透徹其核心業(yè)務(wù)的主流程和逆向流程，把玩每一個頁面。

當(dāng)然只要是靠譜的團(tuán)隊(duì)，打磨比較久的產(chǎn)品，BUG其實(shí)很少。

• 分享功能有BUG。

  點(diǎn)擊微信的結(jié)果，是朋友圈，而不是分享給微信好友和群。

• 買家留言看不到。

  用戶在確認(rèn)訂單的時候填寫了買家留言，然后訂單狀態(tài)變更之后，并不能看到。如果訂單狀態(tài)變更為待支付，用戶再去修改訂單，也顯示不了之前填寫的留言內(nèi)容。

• 修改確認(rèn)訂單的子頁面，返回后需重新加載。

  當(dāng)前修改了新城市的收貨地址，依然會有此提示。應(yīng)該在修改地址完畢跳轉(zhuǎn)回到確認(rèn)訂單頁面的時候，重新刷新當(dāng)前頁面。

當(dāng)然需要注意的是不要混淆BUG和優(yōu)化功能，前者會導(dǎo)致使用產(chǎn)品中斷出錯，后者是不優(yōu)化也不影響用戶使用。

發(fā)現(xiàn)產(chǎn)品已有功能哪里需要優(yōu)化，除了需要細(xì)心，更多的是有沒有設(shè)計(jì)過同類功能的經(jīng)驗(yàn)。

如果以前做過這個功能，你就會知道畫原型的時候需要表現(xiàn)什么，寫邏輯的時候需要注意什么，是否復(fù)雜到需要流程圖以方便技術(shù)理解，以及跳過已有的坑。

當(dāng)然最好也做過相似業(yè)務(wù)，這樣你優(yōu)化功能的時候知道該往哪個方向去使勁，不至于叫好不叫座。

• 優(yōu)化首次啟動APP的加載邏輯。

  首次打開app的時候不應(yīng)該立即檢測網(wǎng)絡(luò)并給出網(wǎng)絡(luò)不好的結(jié)果，而是延后到加載首頁的時候去檢測。

• 優(yōu)化商品詳情的圖片加載邏輯。

  當(dāng)前現(xiàn)狀：商品詳情的輪播圖片，當(dāng)下是標(biāo)準(zhǔn)型的jpeg加載方式。優(yōu)化方法：建議改成漸進(jìn)式，體驗(yàn)更好。

• 切換城市的提示應(yīng)該改成切換城市或者更新收貨地址。

  當(dāng)前現(xiàn)狀：當(dāng)已經(jīng)設(shè)置了默認(rèn)地址，再去首頁切換收貨城市，此時進(jìn)入確認(rèn)訂單的提示去首頁切換城市。優(yōu)化方法：應(yīng)該提示請切換城市或者修改收貨地址，同時修改完畢應(yīng)該自刷新頁面。

• 熱區(qū)范圍太小。

  當(dāng)前現(xiàn)狀：首頁輪播商品的可點(diǎn)擊區(qū)域局限于圖片本身。優(yōu)化方法：增大為整個區(qū)域。當(dāng)前現(xiàn)狀：商品詳情的左下角購物車圖標(biāo)，點(diǎn)擊區(qū)域太小。優(yōu)化方法：切圖的時候把周邊的透明區(qū)域包含進(jìn)去，點(diǎn)擊區(qū)域就大了。

• 精簡訂單狀態(tài)。

  當(dāng)前現(xiàn)狀：用戶能看到的是待支付、待收貨、待評價3種狀態(tài)以及全部訂單。以及支付完成、已確認(rèn)、等待配送、正在配送、已完成等狀態(tài)。優(yōu)化方法：剔除物流狀態(tài)，只采用交易流轉(zhuǎn)的狀態(tài)“待支付、待發(fā)貨、待收貨、已完成、已取消”。而物流作為訂單的子狀態(tài)機(jī)存在，即使自建物流也建議這樣操作。另外還考慮到引入第三方物流的不可控因素比如數(shù)據(jù)回傳失敗，所以建議解耦物流和訂單的關(guān)系。比如正在退款的訂單顯示狀態(tài)已取消，那我退款是成功了還是沒有？還是正在退款中？還是等待審核中？不太符合用戶的理解和購物習(xí)慣。

• 統(tǒng)一訂單狀態(tài)名稱。

  當(dāng)前現(xiàn)狀：APP端訂單狀態(tài)和Web端訂單狀態(tài)不一致。Web端訂單狀態(tài)是進(jìn)行中、已確認(rèn)、等待發(fā)貨、等待收貨、已完成、已取消。APP端訂單狀態(tài)如上條。優(yōu)化方法：建議統(tǒng)一降低用戶理解成本。

• 新增/修改收貨地址優(yōu)化鍵盤。

  當(dāng)前現(xiàn)狀：完成“收貨人姓名”文本框，無法自動跳轉(zhuǎn)到“手機(jī)號碼”文本框，完成“手機(jī)號碼”輸入框，無法自動跳轉(zhuǎn)到下一個焦點(diǎn)。優(yōu)化方法：在鍵盤上面新增”<“和”>”，定位到上一個和下一個焦點(diǎn)區(qū)域?；蛘哝I盤右下角的按鈕改成“下一項(xiàng)”。

• 賬戶余額支付。

  當(dāng)前現(xiàn)狀：無賬戶余額可用的時候，依然可以選擇它。優(yōu)化方法：當(dāng)無賬戶余額可用的時候，去掉“單選框”。當(dāng)有賬戶余額可用的時候，顯示余額值。

• 營銷功能的展示不明顯。

  限時秒殺，在商品詳情只有一個標(biāo)簽，視覺上不明顯，更主要的是沒有凸顯“倒計(jì)時”“剩余數(shù)量緊張”“很多人搶購”等價值點(diǎn)。第二件0元購，表意不夠清楚，不符合用戶理解。實(shí)則滿2件5折，限定活動區(qū)域內(nèi)商品。第二件半價，表意不夠清楚，不符合用戶理解。實(shí)則滿2件7.5折，限定活動區(qū)域內(nèi)商品。

• 頁面加載邏輯建議優(yōu)化。

  當(dāng)前現(xiàn)狀：APP中大部分頁面都是采用的先請求頁面數(shù)據(jù)再顯示頁面內(nèi)容。優(yōu)化方法：改成先顯示頁面再分屏/分塊加載，輔以預(yù)加載。

• 所有專題頁面的底部沒有加載完畢提示。

  當(dāng)前現(xiàn)狀：專題頁面的底部沒有加載完畢提示、沒有分頁加載。優(yōu)化方法：建議增加“已加載全部活動商品”的tips，否則用戶以為還沒加載出來或者不停的往下拉。

• 固定購物車圖標(biāo)。

  專題詳情頁面的購物車圖標(biāo)位置應(yīng)該固定，而不是隨著頁面滾動而變化。

• 跳轉(zhuǎn)頁面不太恰當(dāng)。

  訂單支付完成，建議跳轉(zhuǎn)到全部訂單頁面而不是我的易果頁面。而且不太應(yīng)該是待收貨狀態(tài)并顯示支付成功。

• 搜索頁面建議調(diào)整布局。

  一是搜索歷史建議橫向排列，增加展現(xiàn)量。二是搜索歷史功能建議挪到大家都在搜上面。

• 物流信息文字改成訂單跟蹤。

  本身和訂單跟蹤是同一個功能，并且更像是訂單跟蹤。但是用戶提交了退款申請，并不顯示在訂單跟蹤里面，這個不太合理。

發(fā)現(xiàn)對方產(chǎn)品會開發(fā)哪些新功能，需要對業(yè)務(wù)方向有很深入的了解。當(dāng)然對已有功能的了解也是必須的，畢竟觸類旁通。

易果生鮮是B2C自營商城，生鮮類。而我擁有多年的電商產(chǎn)品運(yùn)營經(jīng)驗(yàn)，對B2C商城的發(fā)展脈絡(luò)以及功能演變有比較深的了解。所以推斷如下：

（1）商品模塊

• 到貨提醒。

  功能描述：當(dāng)部分商品缺貨的時候，提供“到貨提醒”功能，通過app推送和手機(jī)短信進(jìn)行通知。滿足場景：佳沛黃心奇異果特別熱銷，經(jīng)常缺貨，那喜歡吃的用戶很想知道啥時候補(bǔ)貨，就立即搶購回去。目前現(xiàn)狀：“加入購物車”按鈕變成“賣光了”，流程中斷，損失訂單。

• 關(guān)聯(lián)商品推薦。

  功能描述：根據(jù)商品之間的相關(guān)性，在商品詳情和購物車頁面推薦其他商品，以商品卡片列表的形式呈現(xiàn)。滿足場景：購買蘋果梨的顧客，經(jīng)常也會購買橙子。購買黃心奇異果的時候缺貨，推薦綠心奇異果。目前現(xiàn)狀：只能去搜索相關(guān)商品進(jìn)行購買。

• 收藏商品。

  功能描述：看到喜歡的商品，收藏SKU商品到我的易果。滿足場景：比如發(fā)現(xiàn)有好吃的阿克蘇，但是家里還有蘋果。先收藏起來，下次再買。目前現(xiàn)狀：買家只能憑自己記憶，或者放棄收藏。

（2）交易模塊

• 修改支付方式。

  功能描述：當(dāng)需要對待支付訂單進(jìn)行付款的時候，重新選擇支付方式并付款。(并且選擇支付方式是單獨(dú)的彈層子頁面，完全支持。)滿足場景：稍微不注意或者手快的時候，直接以默認(rèn)支付渠道去付款了，而沒辦法去改成有優(yōu)惠的某銀行卡去支付。目前現(xiàn)狀：買家只能取消訂單并重新下單。

• 申請部分商品退款。

  功能描述：買家可以在“我的易果”申請對訂單里面的部分商品退款，而不是對整單操作。滿足場景：買了一大堆生鮮，發(fā)現(xiàn)多下單了一種。目前現(xiàn)狀：買家只能整單退款然后重新下單，或者聯(lián)系客服處理。注：經(jīng)過測試已支持。

• 申請部分商品退換貨。

  功能描述：買家可以在“我的易果”申請對訂單里面的部分商品退換貨，而不是對整單操作。滿足場景：買了一大堆水果，發(fā)現(xiàn)其中的蘋果有損壞，此時買家想對蘋果退貨，其他商品不退貨。目前現(xiàn)狀：買家只能聯(lián)系客服，由他們進(jìn)行部分商品的操作。注：經(jīng)過測試已支持。

（3）注冊模塊

• 增加微信登錄。

  功能描述：通過微信授權(quán)進(jìn)行創(chuàng)建賬號，自動獲取用戶注冊信息。并關(guān)聯(lián)到以手機(jī)號作為用戶唯一id的賬號下面。滿足場景：用戶不想進(jìn)行復(fù)雜的注冊步驟，只想快速的購買生鮮。當(dāng)前現(xiàn)狀：要想購買生鮮，只能先用手機(jī)號注冊賬號。

對產(chǎn)品的功能理解，隨著你的產(chǎn)品從業(yè)時間而不斷加深。但是對產(chǎn)品的架構(gòu)理解，更多的需要你有比較科學(xué)的架構(gòu)方法論。

以下是我的產(chǎn)品架構(gòu)方法論，來源于對技術(shù)架構(gòu)的改造，來源于對業(yè)務(wù)流程的理解，來源于個人的總結(jié)思考。

從產(chǎn)品的數(shù)據(jù)層來看架構(gòu)，PM將整個產(chǎn)品的核心實(shí)體以及之間的關(guān)系都畫出來，方便后端工程師搭建整個數(shù)據(jù)庫架構(gòu)，以及理解業(yè)務(wù)和數(shù)據(jù)間的關(guān)系。詳見浪子文章《如何用ER圖繪制業(yè)務(wù)實(shí)體模型》。

從產(chǎn)品的功能層來看架構(gòu)，PM可以將產(chǎn)品的功能流程圖畫出來表現(xiàn)給前后端工程師來理解該產(chǎn)品最終需要做哪些功能？《如何正確的畫出功能流程圖》

你可以表現(xiàn)產(chǎn)品整體的功能流程圖，也可以表現(xiàn)核心功能的功能流程圖。這里我們以易果生鮮核心的下單功能為例畫出狀態(tài)機(jī)。

雖然對產(chǎn)品的功能理解和架構(gòu)理解，也是PM對產(chǎn)品的業(yè)務(wù)理解的表現(xiàn)之一。但是面試官應(yīng)該更希望看到候選人是否契合公司對業(yè)務(wù)方向的規(guī)劃，以及對其業(yè)務(wù)的獨(dú)特理解。

當(dāng)然這一點(diǎn)是對高級產(chǎn)品經(jīng)理的要求，初級產(chǎn)品能夠做好對產(chǎn)品的功能理解即可。中級產(chǎn)品經(jīng)理能夠做好對產(chǎn)品的架構(gòu)理解即可。

根據(jù)已有的經(jīng)驗(yàn)，判斷出面試公司對業(yè)務(wù)方向的大致規(guī)劃。比如說出它接下來會著重于發(fā)力于物流還是倉儲，還是補(bǔ)貼推廣用戶。大到連接人和人，還是人和物。小到產(chǎn)品功能和架構(gòu)上需要做哪些改變以適應(yīng)業(yè)務(wù)規(guī)劃。

業(yè)務(wù)方向通常由老板來指定，而PM作為產(chǎn)品的靈魂人物，必須對業(yè)務(wù)有獨(dú)到的。

理解并能夠落地到產(chǎn)品層面。

所以，PM一定要很懂業(yè)務(wù)，以及有創(chuàng)新能力。

以上是我對產(chǎn)品經(jīng)理崗位的理解，希望這些方法論能夠給看到本文的PM一些啟發(fā)，面試的時候多一點(diǎn)成功的概率。