產品需求分析:從用戶到需求文檔的歷練

  • 文/Aaron毛
  • 發佈於剛剛
  • 閱讀9645
  • 評論0
  • 喜歡0
  • 閱讀9645

    標籤:

  • 產品經理
  • 用戶需求
  • 用戶分析
  • 產品定位

    這是產品設計的方向,也是需求文檔和設計產出的判斷標準。

    此外,產品定位也是團隊成員形成統一的目標和對產品的認識,提高團隊的凝聚力和工作效率,可以這麼說,產品定位是需求中的需求。

    那什麼是產品定位呢?

    一些產品經理和設計師溝通時候,往往會把功能、業務邏輯梳理得很清楚,但卻忘記了把產品主要面向對象、他們的使用場景如何,還有產品的功能、特色等也說清楚,這就會導致設計師很難做決策。

    這裡可以看出,產品定位實際上就是關於產品的目標,範圍、特徵等約束條件,主要包括兩個方面的內容:產品定義和用戶需求。

    產品定義由PM得出,用戶需求由UED得出,但這一般只出現在大型項目or有充足團隊配置的情況中,實戰案例更多是PM一手操辦,Orz,三頭六臂的哪(P)吒(M)啊。

    其中產品定義中的主要功能、產品特色和用戶需求中的目標用戶形成了產品定位中最核心的內容,是產品設計最主要的依據和方向。

    產品定義

    產品定義就是用一句話概括某個產品,一般可以這麼說:

    該產品主要面向XX用戶提供XX功能,具有XX特色。

    這裡可能會有疑問,對於一些全用戶的產品例如微信、淘寶怎樣準確描述呢?這其實有個小小的誤區,對於這些發展歷程已久,業務迭代升級變化較大的產品,現在的意識形態早已不是當初的樣子。微信當初不就是想取代手機簡訊的功能嗎。所以產品定義也是會升級迭代的。

    如果你的產品很難用一句話描述清楚,要麼就是定位不清晰、方向不明確,要麼你正在做的是類似微信一樣的超級產品,企圖連接一切。而對於創業者來說,連自己都無法流利簡潔描述你的產品,那麼跟著混的兄弟似乎就要對這個leader多一點存疑了。

    舉個栗子:陌陌

    主要功能:發展基於地理位置的陌生關係

    產品特色:LBS搜索用戶和群組

    有了產品定義之後,可以迫使產品經理努力思考產品的方向和機會,在競爭中尋找差異化,也限定大致的範圍,讓團隊不至於茫然。

    用戶需求

    用戶需求就是在具體場景中,目標用戶的目標事件。根據一定方法(頭腦風暴、調研訪談等),可以得出用戶需求示意列表。

    值得注意的是,用戶類型不是絕對的互斥和獨立,更多是以主要取向為區分標準,這不影響後面的篩選和匹配。

    其中目標用戶是最為關鍵的,明確目標人群可以使你更專註於服務某一類特定人群,這樣更容易提升這類人群的滿意度,也更容易使產品做到差異化和成功。

    產品是給用戶用的,錢也是用戶掏的。選擇哪種類型的用戶作為目標用戶,需要綜合權衡用戶對公司的價值和潛在用戶量。

    通常會優先考慮最右上角的用戶(潛在量大,價值高)。

    確定目標用戶類型後,就可以篩選匹配出相應的場景和需求。整個過程包含大量思考和決策,因此產品經理需要做足準備工作,包括:了解市場調研結果(趨勢、相關聯行業或者產品的態勢)、了解市場上同類產品的情況(競品分析)、了解潛在用戶的基本情況、了解公司、團隊的優勢和劣勢等等。

    需求來源

    確定產品定位之後,然後通過不同的方式來收集大量的需求,然後根據這些需求的有效性和真實性、產品定位和項目資源情況進行篩選和匹配,提煉出產品需求,定義出優先順序。從產品定位到需求優先順序,整個過程不僅涉及對用戶的分析和理解,還包括了對產品定位、項目資源的考慮。

    需求來源可以大致分為以下幾種,其中競品分析、產品數據、用研是從產品層提出,老闆敏銳的眼光則是「人為」思考的結果。

    通過五花八門的渠道收集到一堆需求之後,不可能全部都能做,需要按照一定規則和流程,篩選出來最有價值的需求,將有限的投入產出最大化。

    其中有一個較重要的環節,也是考驗PM能力的地方,透過現象看本質,挖掘用戶的真實需求(有個經典的故事:汽車之父亨利·福特曾有一個經典的句子:「如果我問客戶他們想要什麼,他們總是說想要更快的馬。

    這裡謹記兩條:

    傾聽用戶不等於聽從用戶

    用戶想要什麼不等於真實需求

    需求文檔

    經歷完需求篩選和優先順序定義之後,通常可以得到需求列表,負責各個功能的產品經理就可以領任務去寫PRD了(對於一般更新迭代的需求,可能篩選完之後只有一兩條需求,優先順序都不需要定義,就可以直接開寫了)。

    下面是標準需求文檔的內容示例:

    1. 文檔備案:包括文檔日期、版本號、修改人、修改內容和審核人等信息,一般以表格形式位於文檔開頭。

    2. 目錄:方便閱讀

    3. 背景描述:為什麼要做這個產品/模塊,市場行情,業務目標,產品定位等

    4. 用戶類型:簡單地描述目標用戶的情況

    5. 項目時間安排:啟動、結束等時間節點

    6. 信息結構:簡單理解為內容和頁面的層級

    7. 業務流程說明:以流程圖形式說明業務各個狀態間的切換邏輯(例如:遊戲伺服器滿人時候需要切換到排隊登錄狀態)

    8. 需求說明:每一條需求的詳細說明(包括:使用場景、UI描述、功能描述、優先順序、輸入/輸出條件、處理流程、補充說明等)

    9. 涉及關聯業務部門的支持,還需要特別備忘。

    如同設計稿,代碼一樣,需求文檔很難一次成型,需要不斷修改,在評審中發現問題是很正常的。

    需求分析廣義上看包括了需求獲取和分析篩選兩個方面。產品定位是確定產品需求的根本依據,而目標用戶則是產品定位的標尺。要想得到正確的需求,PM需要全程參與,充分準備,深入到各個關節中,並且充分聽取不同成員的意見。

    上述方法論是標準化流程,實戰運用,不同公司不同項目會有更接地氣的一套過程,本文謹對新人作分享和啟發之用。需求文檔的撰寫同理,引用在京東實習時候,曾經就PRD模版和導師有關一些討論,最後導師給出的意見是:根據需求和進度來靈活變通,切勿迷戀所謂模版。尤其移動互聯網時代。僅以此話與諸君分享。

    文章內容提煉於劉津老師和李月老師的《用戶體驗設計師的成長之路》,力薦閱讀原作,之後會出系列讀書筆記,圍繞用戶體驗設計相關話題而談。

    本文為頭條號作者發布,不代表今日頭條立場。


    推薦閱讀:

    iPhone用戶在使用手機時經常犯的8個錯誤,你是否有這些習慣?
    用戶模塊設計
    分期樂案例分析:用戶視角的兩個核心?
    Keep創始人:20個月突破6000萬用戶,Keep靠這三句話
    17個讓安卓用戶嫉妒不已的iPhone專屬應用程序

    TAG:產品 | 需求 | 用戶 | 文檔 | 產品需求 | 需求文檔 | 分析 |