根據需求的類型，你面臨的需求可能來自以下幾個方面，本文從五個部分講述了需求從產生到上線的過程。

產品的第一優先級永遠是有用。?一個好的產品是能解決問題的，也就是我們常說的需求。是需求決定了流程和頁面，流程和頁面決定了交互。

而對于一些剛入門的產品經理，通常上來就會沉浸在頁面實現中，而沒有理清楚需求，本末倒置。還有一些產品經理，是面向老板設計產品，老板說我要這個我要那個，就忙不及的去按照老板的想法做，而不顧自己手中所有的開發資源和用戶端的需求。

這樣做出來的產品往往是沒有人會使用的。 產品在日常的工作中所有的核心都是圍繞需求展開的，而需求往往來自于各個方面，一個好的產品應該是各個方面需求綜合作用的產物。

根據需求的類型，你面臨的需求可能來自以下幾個方面，本文從五個部分講述了需求從產生到上線的過程。

A 戰略層需求（一般來自老板）

一個公司的方向性需求，一般不是產品經理所能決策的，這個層面的需求一般來自于決策層。老板一般會根據自己擁有的資源優勢，以及對市場的分析，決定產品的戰略方向。

比如為什么微信是做熟人社交，陌陌是做陌生人社交，360是做殺毒。對于這個層面的需求，一般不會有太具體的需求。通常產品經理會聽到的需求會是，產品大概要面向什么樣的用戶，幫助用戶解決什么樣的問題，這種類型的需求可能在初期的創業公司會聽的更多，例如餓了么的誕生是來自于他的創始人想要解決校園里叫外賣不便的現狀 。

在相對成熟的公司孵化新項目時，你聽到的需求可能會變成：公司有哪些資源優勢，我們利用這樣的優勢能切入哪個行業，解決什么問題。比如小程序的誕生，一定是（wo cai de） 微信的決策層在思考自己擁有這個體量的用戶后 ，產品能做更多的事情。在這個思路下，逐漸衍生出了小程序的概念。利用小程序，微信實現了流量的轉化，實現了自己平臺化、系統化的想法。

在這個階段產品經理更多的事情應該是去了解老板提出的方向?；谶@樣的需求，可以確定人群，確定要需求范圍（就是要做啥事），以及手里面可用的一些資源。（比如流量資源，內容資源，算法資源等）。

簡單的來說，如果把做產品比作開店，那么這個階段差不多菜系（要解決問題）和大廚（資源）應該是選好了，以及賣給什么樣的人。但是開在什么地方，面積選擇，店面裝潢，詳細的菜品和定價都還沒有確認。

B 用戶需求調研

在接到了戰略層的需求，接下來要做的事情是分解和完善需求，將需求細化。這個時候你要做的事情包括：找到目標人群、了解目標人群的使用習慣。

比如你要做一個外賣平臺，你的用戶群里可能包含了兩個人群，商家和用戶。針對這兩個人群，又會派生出很多需求。你需要考慮商家的使用環境，普通的小店很可能收銀、送貨、點餐全部加起來只有一到兩個人。他們可能就沒有辦法專職的關注下單情況，這種情況下你的推送機制，語音提醒可能就要保證時效性。同樣的因為生產環境的原因，訂單管理需要人工來確認，保證不會過載，影響用戶的體驗。商品的上架和下架就要盡可能簡單、清晰，在商家沒有貨的時需要及時下架。（不同于客戶端的豐富、種類繁多）。

用戶端則面對學生群體，不同于在食堂購買，在PC或者手機上，如何展示有哪些商家，每個商家又有什么樣的特色，如何幫助用戶去挑選商家，怎么評判商家的口味，價格如何展示。需求和商家端有很大的不同。

文章中舉例的外賣軟件，在我們日常生活中比較常見。很多需求依托常識就可以做出判斷。但是如果遇到小眾的需求，例如二次元社區、情趣用品等，如果產品經理沒有這些產品經驗，則需要去找到用戶群體，比較常見的做法有聯系公司內部的工作人員，例如運營和客服，這些經常需要和用戶去打交道的職位，能給夠你一些最真實的意見。還可以維護種子用戶微信群，做調研問卷等。

但是小公司一般不太會采用這些方式，因為這些方式成本高，耗時長。最好的辦法還是產品經理能變成產品的忠實用戶，去真實的使用產品。而不是假想自己是產品。

在這個環節，其實產品經理基本上可以將方向性的需求轉變為更詳細的功能范圍，以及對應的優先級。還是拿開飯店的那個例子，在這里其實我們根據老板給的菜系和大廚以及開店預算。

我們基本上確認了我們的菜是要賣給什么人，這些人來吃飯的需求是工作餐還是周末聚會，還是情侶約會，以及他們大概的預算會在什么范圍（目標人群及核心需求） 。在這些條件的支撐下，我們基本可以確定菜譜上的內容，要設置涼菜、熱菜、招牌菜、主食（需求轉化為對應的功能列表）。根據這些人的性格特點，店面的裝潢也可以確定了（頁面風格，排版）

C 協作部門的需求

確定了用戶的需求之后，我們要繼續確認內部的工作流程。產品不僅是用于服務用戶，同時還要服務自己內部體系的其他部門。例如：

• 運營部門日常的內容和活動維護，那你就會需要一個管理后臺；
• 客服要可以收集和解答用戶的問題，那我們的頁面上就會需要客服的展示位以及后臺給客服回復的頁面；
• 像餓了么這個例子，它的協作部門還包括了外賣配送人員，這個時候就需要給配送員一個可以快速查看和管理訂單的頁面（體量足夠，可以變成app）；
• 網站類的產品可能收到來自seo部門的需求，他會要求的你的頁面上增加很多的內鏈、會要求一些搜索詞要有落地頁面。（這個可能會直接影響你的網站結構，seo會讓你做很多專門給爬蟲抓取的頁面）。
• 可能還會有一些頁面上看不到的需求:比如財務可能有做賬的需求，BI有數據統計的需求。

確定了你可能需要協作的部門之后，有的時候你還需要繼續確認他們的人員配置和工作流程是什么樣的，這些會影響到前后端的設計。

以我所在的公司為例，產品是垂直領域的內容類產品，在我規劃內容展示的時候，首先需要明確我們內容的生產的范圍和內容數量、以及內容的展示形式（音頻、視頻？），這些東西決定了你的頁面如何展示。

如果說內容是自己產生，每天大概有幾篇？如果只有十幾篇，可能就不適合信息流的展現形式，包裝成為欄目做深度閱讀或許更好（例如每日精選）。

如果你的產品定位又是內容服務，主要服務場景是提供多而全的內容，而運營每天的內容生產上限就是十幾篇，那么這個時候內容從哪里來呢？是去利用爬蟲抓取內容，還是做PGC平臺？ 抓內容是哪里抓，中文還是英文，是英文是否需要機器翻譯。內容抓取過來，運營是否需要二次處理。如果是做PGC平臺，運營是否去做第一批種子用戶，去用各種馬甲活躍社區氣氛。

延續我們開飯店的那個例子，在這個階段，你可能需要根據后廚的人員配備和菜系（用戶需求和內容生產能力）決定廚房添置的什么道具，是否需要購置燒烤架（內容生產的類型），原材料是使用半成品還是自己制作（內容生產的流程）。

D產品配套需求

一個在客戶端呈現的需求，往往伴隨著的很多你看不到的功能需求。以一個社區類評論功能為例，用戶只能看到普通的回帖評論，但是背后可能伴隨著一套超級管理員系統。管理員可能需要有禁言、刪、拉黑。

拉黑的人是否可以被解除黑名單，黑名單在哪里管理，由于前端頁面展示有限工作效率低的問題，就需要做一個后臺來管理。禁言多久后可以發言，在別的帖子是否可以發言。規則都需要設置清楚。還有評論中如果有敏感詞匯，需要如何處理。這里有一個很有趣的例子，在某二次元論壇對一些敏感詞匯進行了替換，例如“你他媽”會被他替換為“你他喵”，想象一下兩個對罵的人，說出來都是你他喵，這還怎么罵的起來。在我們的社區中還發現了有人利用接口，在帖子里面刷廣告怎么辦，我們就需要設置回復間隔。這些都需要產品去設計周邊的系統。

再比如社區有一個競彩功能，配套的就要有出題，結算功能。結算有可能會錯，是否需要二次確認。競猜是否給予用戶獎勵，獎勵是否可以兌換獎品？獎品是否需要商城系統？或者獎勵不可以兌換，那是否可以提現，提現就需要一套給用戶提現系統，要有提現記錄，要可以添加提現的轉賬賬戶，是支付寶還是銀行卡。這些又需要配置API接口。

因此在需求分析的時候，往往不能只看到表面上的功能，背后的完整流程，產品經理都要清晰。并對實現成本有個大概的估計，從而決定是否要拓展周邊功能。比如說你的競猜功能初衷只是想提升社區的活躍，但是你卻花很大的精力做了一套競猜系統，可能就極大的浪費了開發資源。

在我們開飯店的那個例子里，再上一個環節里面我們確認了我們要做燒烤店，以及整個燒烤的流程如何開展。在這個環節里面，我們就需要確認我們是用鋼簽還是用竹簽，簽子應該怎么整理，飯桌上是否需要設置專門盛放簽子的容器（評論體系中的管理員），如果是鋼簽，如何回收清洗，如何降低簽子的丟失率，簽子如何消毒（帖子后臺管理系統）

E數據側需求

以上的這些需求理清楚之后，差不多產品的需求也算完整了。1.0的版本基本做完之后，我們還需要進行持續的線上數據觀察。這里我們跳過你產品的冷啟動時期，假設你的產品已經擁有了自己的用戶群體。

在這個階段產品需要通過數據來驗證之前產品經理推理（拍腦袋）定的需求是否合理。帖子的評論功能是否使用，你給帖子提供的快捷回復，和表情包是否有人使用。設置的收藏和分享點擊率怎么樣。分享是放在評論旁邊，讓用戶方便觸達。還是放在帖子結束時，讓閱讀完帖子的可以第一眼看到并觸發分享。

我們籌劃了好久的飯店，在這個環節也進入了正常的營業節奏了。你需要通過數據來檢驗這個店是否符合你最初的預期，例如你的是面向白領的中午餐，你需要驗證客單價、平均上菜時間，以及翻臺率等關鍵數據，來優化你后臺的生產流程，菜單的設置。

來保證用戶在短時間完成用餐，并且消費在白領的工資可承受范圍內。還要確定這樣的定價和人員配置和生產成本下，你的飯店是可以盈利的。我們還希望我們的大廚們，能看到自己的菜被用戶所喜歡，干的有動力。我們的服務員可以很高效的完成用戶的要求，從而得到用戶的稱贊。這些東西的實現和飯店整體（產品）的設計密不可分。

本文由 @Polar 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Pixabay，基于CC0協議