編輯導語：產品經理在日常工作中經常會遇到做產品方案，而且是可落地的產品方案，在這個過程中需要經歷多方的驗證、需求分析等等；本文是作者分享的一個面試問題——如何將一個需要變成一個落地的產品方案，我們一起來看一下。
最近正在面試，面試官問到一些問題，自己做了思考，輸出如下：
作為一個產品經理，拿到這個問題，我的第一想法是：這個需求論證過嗎？
這裡假設公司已經有一定規模用戶，已經建立用戶畫像。
且已經做過需求論證，確定是我們的核心用戶群體的需求。
一、確定關鍵指標——動手之前要先動腦
分析：這個需求的關鍵點是哪些？如何判斷輸出的產品方案是合適的？
所以要在產出之前制定針對結果的評判指標。
要最先擺出來關鍵指標，明確以下幾點：
用戶特徵是什麼？在什麼場景下用戶有這個需求？在該場景下，用戶使用的關注點是什麼？在該場景下，用戶的目標是什麼？關於1，不同公司/產品的用戶群體不同，特徵也不同，則對於產品好壞的評價標準會有差異；比如遊戲公司的用戶多為青少年、學生族、上班族。而古董、房產類電商產品用戶多為中老年。
關於2，用戶在什麼場景中會有這個需求，不同場景下用戶的操作行為和要求也會發生變化；比如打車產品，用戶逛街逛累了、到陌生的地方旅遊場景下會有這個需求；比如短視頻類產品，用戶在坐地鐵、等車的場景下會有這個需求。
關於3，在不同場景，用戶的關注點會有差別，關注點不同則產品設計的重點不同；比如在電商類產品中，用戶在瀏覽商品的場景中，關注點是商品的質量、顏值、價格等信息，而在付款流程中，用戶的關注點是地址信息、優惠信息、資金安全、消費風險等功能。
關於4，不同場景用戶的目標不同（這裡要明確區分用戶目標和產品目標，是用戶的心理預設目標）；比如電商產品中，在瀏覽商品的場景中，用戶的目標是看到自己關注的、好看好玩、性價比高的產品；而在付款流程，用戶的目標是流暢完成購買的操作，並確保資金安全。
在分析並解答這些問題後，對此次功能上線後的數據情況（用戶量、日活、月活 ）會有初步的預測。
二、產品方案設計——不是無腦的抄抄
調研市面上是否已有該滿足該需求的功能，在百度、貼吧等渠道尋找競品。
如果已經有獨角獸產品，則需要看該產品的用戶評論和貼吧口碑。
最終選取口碑較好和獨角獸的產品作為主要分析的競品。
1.競品分析
羅列競品的產品關於該功能的產品結構，對比後梳理出共同的功能和差異的功能，即得到「基礎功能」、「亮點功能」。
作為「基礎功能「，我們的產品必然也要有。並且結合用戶的負面評價進行優化。
而「亮點功能」則是各個產品的亮點，是運營宣傳和吸引、留存用戶的關鍵；所以我們也要想到自家產品的「亮點功能」。亮點功能的設計就要拿出前文的「關鍵績效」，並結合公司已有資源來思考。
完成競品分析後，腦中已經有了產品方案的雛形。
如果市場上沒有該功能的競品，那恭喜你，你可以做MVP，迭代優化後逐漸做大，充分展示產品經理的能力。
2. 輸出業務流程圖
工作中很多領導要求直接輸出原型圖，但是在我的經驗中，這步操作很考驗產品經理的邏輯能力，因為：
1）做原型圖需要在腦中構建出業務流程圖，產品結構圖，還需要考慮互動設計、界面元素排布等事情；而原型圖產出後，就會開會討論，這個時候發現問題，就不只是產品經理復工，還會耽誤大家時間。
2）業務流程圖可以把流程展現出來，需要合併和縮短的流程一目了然，為後續功能模塊的劃分和相同頁面的合併（關鍵頁面）設計提供了便利；防止用戶操作總是進入新頁面，造成研發和設計團隊工作量增大的問題。
3）業務流程圖可以清晰的梳理、補全異常流程；異常流程的處理也很重要，上線初期會影響產品口碑，看微信的初期用戶評價，有很多異常情況的負面反饋，這樣就造成團隊為了挽回用戶快速迭代優化，大量加班。
所以建議產品經理謹慎的輸出業務流程圖，並反覆琢磨；（建議分析競品也採用這個方法，會受益良多）可以按照流程的層級輸出多個業務流程圖，某些自己閉環的功能可以另做一張圖詳細梳理，在主圖中直接用模塊替代。
3. 輸出功能結構圖
業務流程圖梳理後，會很快產出功能結構圖。
功能結構圖的關鍵是各個模塊應用邊界清晰，防止之後迭代產生新功能時功能歸屬混亂，造成用戶理解困難體驗不好。
4. 關鍵數據指標的設計
在產品設計雛形出現後，需要思考：關鍵流程和頁面埋點的設計。
當然需要先想到需要量化的指標，以及指標的計算方法，然後推理出需要埋點的位置和需要統計的欄位。
1）關鍵節點的統計
根據文初的「關鍵點」設計數據指標。比如電商產品的成交量是一個關鍵節點，則該節點的pv、uv、訂單量、付款量等數據是需要採集數據；最後根據採集到的數據進行用戶質量、產品質量、ARPU等指標的計算。
2）關鍵流程的統計
比如學習平臺的登錄註冊流程，是拉新指標的關鍵衡量流程，所以在用戶操作的沒一步都需要採集，之後做衰減圖，分析定位造成用戶流失的行為，來優化該位置。
數據量化是產品後續迭代重要的依據，可以量化的展示劣勢和科學的提高關鍵指標，希望大家在產品設計時就開始規劃。
5. 輸出原型圖
根據結構圖，區分模塊，根據流程圖梳理出的關鍵頁面，重點考慮交互的流暢度和元素排布的合理性；其中用戶會從多條業務線進入關鍵頁面，所以關鍵頁面需要重點關注。
我的經驗是，原型圖設計有動態有靜態，一般給客戶展示（2B）需要做高保真動態原型圖。
給團隊研發同事看的需要具體溝通和公司的規定，有的研發會喜歡靜態+描述的原型圖。
6. 輸出prd
prd的輸出根據公司規定輸出即可，有的公司做原型圖+邏輯說明就可以，但是有的公司後臺的邏輯比較多無法用界面描述，所以會需要prd。
三、產品方案論證——別著急找技術
產品經理拿著方案去找技術，這就走上了一條無法回頭的戰線，所以要慎重。
下面結合自己的經驗，給出此階段的自檢方法。
自檢問題：
設計的功能是否滿足了需求？這個設計是用戶的首選方案嗎？用戶選擇使用這個功能有成本嗎？這個功能會給用戶帶來風險嗎？關於1，反思是否完成了設計的初衷。回頭看最初的「關鍵點」中的需求，若解決了用戶的需求問題，則通過。
關於2，需求是存在的，但是用戶有很多解決辦法，不一定要選擇你提供的方法；如果用戶有更加高效、優惠的方式，則你的用戶量就會低於預期。
關於3，不少的解決方案是要求用戶使用這個功能，但是沒有考慮用戶的成本；比如用戶需要安裝很多軟體、插件等，這對於部分用戶來說是需要考慮的成本。
關於4，對用戶來說，是否有財務、心理、時間、社交的風險，這個時候就需要結合「關鍵點」中的用戶畫像來逐個分析風險的情況；相信大家都理解，這些問題對用戶來說是會有負面的品牌印象。
四、對接研發——別用領導的態度
在工作到這一階段，與研發同事溝通也是很多產品經理頭大的一件事情。我的經驗是：別用領導的態度和研發講需求。
產品經理心裡覺得：我忙乎半天終於搞出來產品方案了，直接輸出給他們，他們趕緊幹不就完了，為啥老是反問我，搞事情？
然鵝，研發的想法是：我們研發是公司的核心，你產品經理憑啥命令我們，我們為什麼聽你的？
這樣就發現，研發同事並不是不認可你的產品方案（排除產品設計的確實很爛的情況），而是覺得產品經理的態度有問題。甚至有一些產品經理用某個領導說了要做什麼來強制要求研發團隊。所以團隊中研發阻力很大的產品經理就要反觀自己在與研發對接時的態度問題。
回到產品經理的初衷：希望產品完美的落地。奔著這個目標，我們可以更加友好的方式輸出給研發。結合我的經驗，方法如下：
1）講故事的方式
通之以情曉之以理的聲淚具下的描述用戶的痛苦、用戶的需求多麼的迫切，讓研發產生同感，由內心產生動力。
2）情商高的給研發展示的平臺
產品經理拿著產品成果和領導匯報，而研發作為幕後人員，很少和大領導接觸，所以如果產品經理在匯報時，增加篇幅表明研發同事的付出，自然而然的一點點建立與研發的友好關係；當然日常的郵件也要表明研發的配合工作並表示感謝。
當然，在開發過程中，異常情況也是產品經理與研發衝突的一個部分，這裡就又要強調業務流程圖的重要性了，請大家查看上文。
五、測試與上線前的把關——不要忽略細節
在研發完成後，需要產品經理在一線測試，除了要注意流程是否走通，還需要注意：
有可能原型圖沒有錯別字，但是設計師工作很多，沒有注意到錯別字；而研發直接用工具生成頁面，則上線後這個錯別字就會出現在用戶面前，當然會影響產品的美譽度。
六、數據搜集——比對預期並反思
數據開始時不好也別著急，與運營部門一同發力，協作拉新、促活；數據特別好也別激動，有可能是運營活動做的好。
產品的數據在半年後才能顯現，之前數據表現多是運營活動的效果，所以產品經理一定要穩住，多搜集用戶評價、維護種子用戶，多與第一批用戶接觸、做用戶調研、搜集問題，快速迭代；等到半年到一年，數據表現的才是產品的優劣。
對比預測的數據，思考數據出現差別的原因，反思：
自己設計的功能是否有漏洞？是否對用戶群體特徵的把握不夠準確？是否出現了強大的競品？到這裡，落地的產品方案完成了，可謂路阻且長，行之將至。
產品方案的落地，並不是指產品經理的職責就完成了，建議大家多基於過程思考、基於結果思考，多提有目標指向的想法，自己發力，找到解決方案和優化方案。
如果大神路過，請過目我的思路，如若有激發您的靈感，歡迎留言評論。
本文由@宇智波冰 原創發布於人人都是產品經理，未經許可，禁止轉載。
題圖來自Unspalsh, 基於CC0協議。