前幾天我在11月后臺產(chǎn)品經(jīng)理訓(xùn)練營。

有個同學(xué)問我：“為什么后臺產(chǎn)品經(jīng)理要單獨去講需求調(diào)研，有這么重要嗎？”

我的回答：在實際工作里，后臺產(chǎn)品經(jīng)理和需求調(diào)研的關(guān)系，就像魚和水，誰也不能離開誰，魚有了水才能活、而水有了魚才會有生機。

今天以回答這位同學(xué)的問題開篇，用我們現(xiàn)在的后臺案例，來聊聊，后臺產(chǎn)品經(jīng)理需求調(diào)研的方法。

后臺產(chǎn)品經(jīng)理的需求調(diào)研產(chǎn)物是什么？

很多時候，需求調(diào)研會被產(chǎn)品經(jīng)理認(rèn)為是虛頭巴腦的東西，總是腦子里有一個概念，但從來不花時間在這一步驟上。

主要原因是，畫原型、寫文檔的時間都沒了，我還哪里有精力搞需求調(diào)研？

可是在需求調(diào)研里，我們可以拆分為3個步驟分別是：調(diào)研前、調(diào)研中，每個步驟所對應(yīng)的工作輸出內(nèi)容是不一樣的。你會發(fā)現(xiàn)即使你沒有刻意做需求調(diào)研，但你要開始后臺產(chǎn)品設(shè)計，你一定會產(chǎn)出相關(guān)內(nèi)容，而這些內(nèi)容就是需求調(diào)研的產(chǎn)物，證明你確確實實有需求調(diào)研過，只是沒有總結(jié)罷了。

1.需求調(diào)研前

在這個步驟，我在后臺產(chǎn)品經(jīng)理訓(xùn)練營里教同學(xué)們：一定要要構(gòu)造目的和問題才去做需求調(diào)研，這是非常重要的準(zhǔn)備工作。

問題來自于經(jīng)過我們使用后臺的情況，再來總結(jié)出問題。比如客服系統(tǒng)里有用戶信息推送的功能模塊，后臺產(chǎn)品經(jīng)理就可以自己試用一遍推送，看一看推送的流程，同時做競品調(diào)研來橫向?qū)Ρ认庐a(chǎn)品當(dāng)前的使用情況。

我們使用產(chǎn)品的過程是可視化界面的，但后臺產(chǎn)品經(jīng)理則要看界面背后的本質(zhì)流程，和功能的邊界。

通過上面的測試，有沒有發(fā)現(xiàn)使用上感覺奇怪、流程不通暢、操作行為無法滿足的頁面或某些按鈕。

后臺產(chǎn)品經(jīng)理此時針對上面的種種問題，用頭腦風(fēng)暴的方式快速構(gòu)想理想的客服系統(tǒng)短信推送應(yīng)該是什么樣的，為什么現(xiàn)狀是這樣，而不能成為自己構(gòu)想的產(chǎn)品設(shè)計方案，這就是我們需求調(diào)研前要產(chǎn)生出的矛盾問題。

再舉一個案例，比如我們在做廣告配置的管理后臺，功能里是否存在不能支持的文件類型、還要那一些配置的類型是業(yè)務(wù)方最常用的，實際上我們是不知道的，這些就是需求調(diào)研前的問題。

如下是PMTalk廣告配置的管理后臺，可以看到我們將廣告配置分為廣告位配置、和廣告配置，運營要使用首先得要有廣告位，才可以進行下一步內(nèi)容上傳。

后臺產(chǎn)品經(jīng)理看到這個管理，其實反饋出來的是下面流程，是后臺產(chǎn)品需求調(diào)研前一定要構(gòu)建出來的，因為接下來就會發(fā)現(xiàn)矛盾點，我們才能進行下一步優(yōu)化和產(chǎn)品設(shè)計。

可視化的操作界面所見背后是實際的業(yè)務(wù)流轉(zhuǎn)流程、和對應(yīng)的系統(tǒng)操作角色。上圖的PMTalk的廣告管理后臺，在需求調(diào)研前會產(chǎn)生下面問題：

是否可以減少廣告位、以及運營人員到底怎么更新廣告、和數(shù)據(jù)監(jiān)控所關(guān)注的核心數(shù)據(jù)指標(biāo)（用戶的點擊還是廣告轉(zhuǎn)化）是什么？

2.需求調(diào)研中

必須要承認(rèn)，需求調(diào)研是一個非常花費時間成本的事情。

可是我們沒有需求就沒辦法進行下一步產(chǎn)品設(shè)計，所以很多后臺產(chǎn)品經(jīng)理都喜歡在工作期間，老板給具體的任務(wù)，或者業(yè)務(wù)方給具體的功能需求，這個我在《后臺產(chǎn)品經(jīng)理訓(xùn)練營》里有舉過一些案例，比如醫(yī)院門店管理者需要預(yù)約問診、線下門店店長需要商品管理，這些都是非常具體的需求，產(chǎn)品經(jīng)理可以直接開始做產(chǎn)品設(shè)計。

而也存在沒有這類具體需求的情況，所以在需求調(diào)研前的問題和目標(biāo)準(zhǔn)備好了，我們就要開始調(diào)研，可是調(diào)研的范圍和深度一定要控制好，和問題、目標(biāo)相關(guān)。

帶著在需求調(diào)研前準(zhǔn)備好的問題和目標(biāo)，我們要把握需求調(diào)研的范圍和深度，因為這會大大影響我們做后臺產(chǎn)品需求調(diào)研周期的時間，減少無效溝通。

因為后臺產(chǎn)品也可以稱之為平臺型產(chǎn)品，需求是業(yè)務(wù)方來定，有的業(yè)務(wù)方有自己的產(chǎn)研團隊，則需要先確定業(yè)務(wù)有沒有需求，再說技術(shù)實現(xiàn)的問題（接口有沒有、接口的參數(shù)、接口的網(wǎng)絡(luò)策略）

后臺產(chǎn)品也會對一些緊急需求做優(yōu)化，比如安全升級、比如熱點活動（發(fā)布會）等等，后臺產(chǎn)品經(jīng)理在這個事情就一定要找這類內(nèi)容的牽頭人，我們也叫做接口人。對其安全達標(biāo)的要求、需要的功能list明細進行匹配上

普通需求調(diào)研還要注意調(diào)研下，一個對象不同層次的調(diào)研，比如做CRM系統(tǒng)的運營管理，應(yīng)該挑選調(diào)研銷售成績好、銷售一般、和銷售成績不太好的同學(xué)來做調(diào)研，看看CRM系統(tǒng)的使用后臺產(chǎn)品的時候?qū)δ承┕δ苡幸恍┎蛔慊虿粷M，比如針對線索、商機的分配機制、和鎖定操作等，或者還有沒有缺失的功能。

3.在需求調(diào)研后，我建議輸出下面三部分內(nèi)容

第一建立：需求收集表

需求收集表并不是產(chǎn)品經(jīng)理的需求池，僅代表在在第二步需求調(diào)研期間，收集到的種種產(chǎn)品使用問題、業(yè)務(wù)流程問題、產(chǎn)品使用人員的問題，有的需求是可以進行產(chǎn)品設(shè)計的，有的則無法進行排期，具體原因你懂的（每個公司都有江湖）

需求收集表可以是會議記錄或工作筆記任何形式，如果產(chǎn)品話語權(quán)足夠多還可以建立線上協(xié)同文檔，讓調(diào)研對象填寫

第二建立：產(chǎn)品框架圖

后臺產(chǎn)品并不是一個獨立的產(chǎn)品，會和其他第三方或自家的其他系統(tǒng)進行連接。比如前面提到的廣告配置功能，其數(shù)據(jù)就在PMTalk獨有的數(shù)據(jù)平臺進行查看，運營后臺只有廣告內(nèi)容配置的權(quán)限，開發(fā)有廣告位創(chuàng)建的權(quán)限。

系統(tǒng)框架圖是整個后臺產(chǎn)品的全局視角，尤其是在做產(chǎn)品后期迭代和維護的時候，我們?nèi)绻麤]有搞清楚牽連的相關(guān)系統(tǒng)就可能造成其他平臺出現(xiàn)錯誤。

比如很多app的搜索能力其實是和后臺相通的，如果因為后臺產(chǎn)品設(shè)計的需求原因，要做搜索的分類和搜索結(jié)果限制，就會影響app的用戶。

第三建立：業(yè)務(wù)流程圖

業(yè)務(wù)流程圖需要包含使用對象、系統(tǒng)名字、流程名字，隨著后臺產(chǎn)品逐步迭代，涉及到的業(yè)務(wù)會越來越多，流程有沒有交集造成功能耦合是后臺產(chǎn)品經(jīng)理要注意的。

比如PMTalk的活動管理和視頻管理，就是共同使用了一個活動創(chuàng)建，創(chuàng)建活動后可以將活動選擇位視頻填充的對象，避免運營人員再次創(chuàng)建一個活動，提升效率。

后臺產(chǎn)品經(jīng)理，不像C端產(chǎn)品經(jīng)理，一定要有感性的價值，對于系統(tǒng)的穩(wěn)定、安全、以及業(yè)務(wù)支撐是最重要的，正因為如此，后臺產(chǎn)品設(shè)計會非常理性，嚴(yán)格遵循技術(shù)實現(xiàn)和業(yè)務(wù)流程，才能有可能用后臺產(chǎn)品來完成公司效益的提升、團隊的效率、甚至還能用來做績效考核的重要指標(biāo)。

以上就是今天的分享。