本人阿里產(chǎn)品狗一枚，在摸爬滾打的發(fā)現(xiàn)需求，寫PRD，評審，開發(fā)上線的無盡輪回中反思，并結(jié)合一些相關(guān)的產(chǎn)品書籍，整理了自己的方法論和各位分享。

文章將依次介紹：需求和需求文檔、怎么寫需求文檔、怎么寫好需求。前兩趴已有很多前人栽樹，在此只做簡單說明；第三趴將結(jié)合自身思考，介紹怎么寫一個好需求，如有不準確之處，歡迎拍磚探討。

01 需求和需求文檔

結(jié)合對應(yīng)的單詞的英文描述來理解這兩個詞：

產(chǎn)品需求（Product Requirement）

使用該產(chǎn)品用戶的各方面需要。

做產(chǎn)品都知道一句心經(jīng)-“用戶即上帝”。但實際上產(chǎn)品經(jīng)理接收到的需求是來自各方各面的：用戶反饋、線上數(shù)據(jù)反哺、內(nèi)部腦暴結(jié)果、甚至是老板親令直達……如何從這萬花叢中過，做到片葉不沾身且讓各方滿意，是門藝術(shù)，后續(xù)會詳細探討。

產(chǎn)品需求文檔（Product Requirement Document， PRD）

結(jié)合對應(yīng)需求進行產(chǎn)品規(guī)劃和設(shè)計，落地而成的內(nèi)部文檔。

產(chǎn)品需求文檔面向的對象是除產(chǎn)品之外的所有團隊成員。一份需求文檔清晰與否，直接關(guān)系到功能開發(fā)上線的質(zhì)量和KPI的達成，對產(chǎn)品經(jīng)理的文檔功力有很高的要求。

02 怎么寫需求文檔

話不多說，相關(guān)框架結(jié)構(gòu)直接甩表：

上面的表格包含了需求文檔所需要的對應(yīng)模塊，相關(guān)子項及說明。

看過很多需求文檔，整體模塊大都能match，主要差距則體現(xiàn)在文檔描述上能否做到邏輯清晰、模塊拆分明確，讓相關(guān)研發(fā)、測試、運營、商務(wù)、老板等，通過看文檔就明白你想做什么，想怎么做，以及需要他們怎么配合。

這十分考驗產(chǎn)品經(jīng)理的文檔撰寫能力，剛?cè)腴T的產(chǎn)品經(jīng)理可以基于以上的框架結(jié)構(gòu)，先嘗試表述清楚自己的需求，然后在需求評審review和各方challenge的過程不斷的提升自己的文檔功力。

03 怎么寫個好需求

本文段探討的并不是怎么寫好一個需求，而是是怎么寫一個好需求，這涉及產(chǎn)品邏輯梳理、需求挖掘和增長優(yōu)化等等，旨在通過梳理功能路徑去發(fā)現(xiàn)其中的用戶痛點/爽點，寫出一個個有用的“好需求”。

本人在Review了萬千套路之后，將其抽象總結(jié)為了比較簡單的輸入輸出模型：

但凡涉及用戶行為動線和功能梳理相關(guān)，都可按照以上方法進行拆解，下面將分場景講述如何應(yīng)用。

3.1 需求邏輯梳理：“全”

“沒有這個邏輯，需求文檔上沒寫?！?、“現(xiàn)在才補邏輯，過兩天就要上線了，寫需求的時候怎么沒想到，下一期再帶吧?！?、“這個看起來像個bug，后面的處理需求文檔也沒寫……”

當(dāng)需求文檔寫的不夠清晰時，以上的對話就會瘋狂支配你的搬磚日常。

縱然通過PRD評審、Sprint會、測試用例評審，這些流程去盡可能保證需求考慮全面，溝通到位；但在開發(fā)過程中總會發(fā)現(xiàn)邏輯缺失的問題，這是無法避免的事情，對應(yīng)問題可輕可重，輕的話可能只是改一個限制條件，嚴重的話整個項目無法按期上線。

產(chǎn)品經(jīng)理雖說一個人不可能想全所有邏輯，但在時間允許的范圍下，要盡可能去思考路徑中是否有邏輯遺漏，依照輸入輸出的模型，把產(chǎn)品功能想象一個輸入輸出器，以首頁一個簡單的連續(xù)記錄三天生成專屬運動報告為例，按模型梳理流程，涉及方面如下：

輸入特性：

• 什么時候觸發(fā)輸入，頻率如何（進入首頁展示記錄入口，只彈出一次）
• 輸入門檻：依賴特定版本或平臺，其他功能、用戶身份或特定行為等（登錄用戶展示記錄入口，1.6.5以上版本才支持對應(yīng)功能）
• 輸入是否有持續(xù)性：輸出是否和連續(xù)的輸入是強依賴（連續(xù)記錄三天才能有報告）
• 輸入格式和內(nèi)容（需要記錄的選項和格式限制）
• 如何完成輸入（點擊右上角save，展示進度條，保存記錄選項）
• 是否有其他輸入來源（在健身訓(xùn)練完成后，也會展示記錄入口）
• ……

輸出特性：

• 什么時候觸發(fā)輸出，頻率如何（3天后打開app首頁報告入口提示報告已生成，只彈出一次）
• 輸出門檻：依賴特定版本或平臺，功能模塊、用戶身份或特定行為等（登錄用戶展示報告，1.6.5以上版本才支持對應(yīng)功能）
• 輸出是否有持續(xù)性：輸入是否需要連續(xù)的輸出（無）
• 輸出格式和內(nèi)容（報告展示運動類型、運動時長等）
• 如何結(jié)束輸出（數(shù)據(jù)拉取完成）
• 輸出的影響范圍（在個人中心的報告入口，也展示對應(yīng)報告）
• ……

從輸入到輸出的過程：

• 是否需要用戶等待？
• 如果需要等待，如何給用戶反饋？
• 是否會和其他場景沖突？如果有沖突要怎么解決

異常情況：

• 輸入/輸出時機沖突
• 輸入/輸出有誤
• 輸入和輸出門檻的需做對應(yīng)兼容
• 輸入/輸出持續(xù)性的中斷等
• 輸入輸出過程的中斷
• ……

基于這個模型，再結(jié)合總項拆分子項的方法review流程，保證需求在撰寫階段盡可能全。

3.2 需求挖掘&增長點探索優(yōu)化：“準”

除了需求撰寫之外，產(chǎn)品經(jīng)理的另一個工作日常就是分析用戶行為數(shù)據(jù)，找到增長點落地成需求；或者通過用戶反饋定位需求落地執(zhí)行。針對以上場景，這套模型同樣適用。

需求挖掘和增長優(yōu)化需要結(jié)合具體的用戶行為動線和KPI指標，進行功能路徑轉(zhuǎn)化的review發(fā)現(xiàn)新的需求優(yōu)化和產(chǎn)品增長點。

那么除了用戶需求之外還有什么增長點可以挖掘優(yōu)化呢？我們可以根據(jù)輸入輸出的方法，可以從觸發(fā)輸入開始，結(jié)合流程看轉(zhuǎn)化和留存：

• 觸發(fā)輸入/輸出的條件有哪些？
• 哪種條件下的觸發(fā)帶來的入口點擊率最高？哪種條件雖然目前點擊率不高，但是有優(yōu)化輸入/輸出特性的可能，且優(yōu)化效果明顯？
• 從觸發(fā)輸入到輸入完成的轉(zhuǎn)化路徑如何？用戶流失在哪塊？是否有優(yōu)化空間？
• 輸入完成和輸出結(jié)束的用戶留存數(shù)據(jù)如何？是否有明顯差距？如果輸出結(jié)束的用戶留存更高，是否應(yīng)該先優(yōu)化從輸入到輸出的轉(zhuǎn)化路徑？
• ……

可以看出其實就是總括性的把大模塊抽出來，再分路徑拆細評估數(shù)據(jù)指標，發(fā)現(xiàn)可優(yōu)化的點。按該模型梳理不容易有遺漏，并便于發(fā)現(xiàn)細分流程的弱項找到對應(yīng)功能的增長點。

此模型僅針對拆解功能的增長點探索，及對應(yīng)需求范圍的評估，可以從細分模塊入手梳理。

如果是從產(chǎn)品本身出發(fā)大方向上的增長，需要另一套結(jié)合指標拆解方法去落地增長模型，找到對應(yīng)的增長套路，待梳理后會和大家分享。

小感慨一句，產(chǎn)品經(jīng)理是一個需要不斷積累總結(jié)、思考沉淀的崗位，沒有任何一門大學(xué)課程會教你如何做一個產(chǎn)品經(jīng)理。唯有自己多思考學(xué)習(xí)，keep staying hungry，找到自己適合的工作和學(xué)習(xí)方式，向一個優(yōu)秀的產(chǎn)品經(jīng)理不斷邁進。以此共勉~

本文由 @菜鳥愛打怪 授權(quán)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

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