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

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

而對于一些剛?cè)腴T的產(chǎn)品經(jīng)理，通常上來就會沉浸在頁面實(shí)現(xiàn)中，而沒有理清楚需求，本末倒置。還有一些產(chǎn)品經(jīng)理，是面向老板設(shè)計產(chǎn)品，老板說我要這個我要那個，就忙不及的去按照老板的想法做，而不顧自己手中所有的開發(fā)資源和用戶端的需求。

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

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

A 戰(zhàn)略層需求（一般來自老板）

一個公司的方向性需求，一般不是產(chǎn)品經(jīng)理所能決策的，這個層面的需求一般來自于決策層。老板一般會根據(jù)自己擁有的資源優(yōu)勢，以及對市場的分析，決定產(chǎn)品的戰(zhàn)略方向。

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

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

在這個階段產(chǎn)品經(jīng)理更多的事情應(yīng)該是去了解老板提出的方向。基于這樣的需求，可以確定人群，確定要需求范圍（就是要做啥事），以及手里面可用的一些資源。（比如流量資源，內(nèi)容資源，算法資源等）。

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

B 用戶需求調(diào)研

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

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

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

文章中舉例的外賣軟件，在我們?nèi)粘Ｉ钪斜容^常見。很多需求依托常識就可以做出判斷。但是如果遇到小眾的需求，例如二次元社區(qū)、情趣用品等，如果產(chǎn)品經(jīng)理沒有這些產(chǎn)品經(jīng)驗(yàn)，則需要去找到用戶群體，比較常見的做法有聯(lián)系公司內(nèi)部的工作人員，例如運(yùn)營和客服，這些經(jīng)常需要和用戶去打交道的職位，能給夠你一些最真實(shí)的意見。還可以維護(hù)種子用戶微信群，做調(diào)研問卷等。

但是小公司一般不太會采用這些方式，因?yàn)檫@些方式成本高，耗時長。最好的辦法還是產(chǎn)品經(jīng)理能變成產(chǎn)品的忠實(shí)用戶，去真實(shí)的使用產(chǎn)品。而不是假想自己是產(chǎn)品。

在這個環(huán)節(jié)，其實(shí)產(chǎn)品經(jīng)理基本上可以將方向性的需求轉(zhuǎn)變?yōu)楦敿?xì)的功能范圍，以及對應(yīng)的優(yōu)先級。還是拿開飯店的那個例子，在這里其實(shí)我們根據(jù)老板給的菜系和大廚以及開店預(yù)算。

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

C 協(xié)作部門的需求

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

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

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

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

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

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

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

D產(chǎn)品配套需求

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

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

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

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

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

E數(shù)據(jù)側(cè)需求

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

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

我們籌劃了好久的飯店，在這個環(huán)節(jié)也進(jìn)入了正常的營業(yè)節(jié)奏了。你需要通過數(shù)據(jù)來檢驗(yàn)這個店是否符合你最初的預(yù)期，例如你的是面向白領(lǐng)的中午餐，你需要驗(yàn)證客單價、平均上菜時間，以及翻臺率等關(guān)鍵數(shù)據(jù)，來優(yōu)化你后臺的生產(chǎn)流程，菜單的設(shè)置。

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

本文由 @Polar 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Pixabay，基于CC0協(xié)議