萬字干貨|產品經理知識體系之需求管理(二)

380 評論 59229 瀏覽 847 收藏 42 分鐘

產品經理知識體系根據產品全生命周期共分為五個階段:idea管理、需求管理、精益產品設計、產品研發、產品運營。本文是系列文章的第二篇:需求管理。產品能否被大眾所接受、被市場所接受,取決于產品是否滿足用戶的需求,所以如何獲取需求、管理需求以及對需求做決策就十分重要了。

一、需求獲取方法論

產品是建立在需求之上的,如果需求獲取階段出現問題,那么最終發布的產品也會和最初設想的有很大差別。如何獲取需求,我們在這里分為定性和定量兩種分析方法:

  • 定性分析:明確產品需求的本質
  • 定量分析:通過大體量的數據對需求進行分析以及判斷

根據定性和定量兩種分析方法,在實際工作當中會采用如下幾種常用的實踐方法:

1. 行業調查報告

行業調查報告分析在市場分析的時候就提到過,這是一種投機取巧的方法,通過第三方調查機構對行業或產品已有的調查結果進行加工,從而獲得自己想要的東西,在需求獲取階段也適用,通過對某個行業分析,可以從之發現這一行業用戶群體的需求再進行加工后形成自己產品的需求。但是不建議采用這種方法,畢竟這是別人獲得的需求,并不是第一手獲得,和實際情況難免有所偏差。

2. 用戶訪談

一款新產品的誕生以及對現有產品的更新、改版,都需要對用戶進行用戶訪談,這也是產品經理工作當中經常要做的工作之一。

與目標用戶進行訪談,了解用戶對現有產品的不滿以及通過訪談發現潛在產品的機會,對新產品的設計以及現有產品的迭代升級具有很重要的作用。

(1)用戶訪談的目標

  1. 通過用戶訪談,產品經理往往需要了解如下信息來幫助新產品設計或現有產品的更新:
  2. 用戶為什么要用這個產品,會在什么時間、什么地點以及如何使用產品
  3. 現有產品可以幫助用戶完成哪些任務,不能幫助用戶完成哪些任務
  4. 對產品的期望
  5. 現有產品(或競品)的不足和需要改善的地方

(2)用戶訪談流程

1)訪談前

在訪談前,首先要明確用戶是誰,確定產品的目標用戶才能有針對性的進行訪談,同時得到更為準確的信息。

針對B端產品設計,用戶通常是產品的具體使用人員。比如一款針對于進出口報關的產品,那么要進行用戶訪談的用戶就是具體使用產品進行報關的報關員,通過對報關員的訪談就可以了解產品具體應用場景以及需求等等。

針對于C端產品,用戶群體更為廣泛,這時就需要根據產品立項時的使用場景、目標人群、使用需求來進行用戶定位,根據產品具體目標人群細分成幾大類典型用戶,然后根據細分的用戶進行有針對性的訪談。

2)訪談中

找到訪談對象后,就要開始進行一對一的用戶訪談,訪談效果的好壞往往可以看出一個產品經理的經驗是否充足、能力是否足夠出眾。因為人與人之間交流溝通的不確定性,訪談過程中會遇到各種各樣的情況,在這里針對幾個關鍵點進行介紹,幫助經驗不足的產品經理把握訪談節奏、達到更好的訪談效果:

① 盡量在產品使用場景下訪談

在產品使用場景下進行訪談,可以讓產品經理了解產品具體使用環境,有機會觀察用戶的具體使用過程,從中發現現有產品的不足、用戶的需求以及目標。

② 避免按照設計好的問題提問

用戶訪談并不是調查問卷,不能按照問卷的形式進行提問。因為我們不知道用戶的真實需求以及實際問題,需要在訪談的過程當中了解用戶的問題以及用戶的需求,而不是提前可以明確的,如果提前了解的用戶的問題,那么就不需要再進行用戶訪談了。

在進行用戶訪談過程中,可以從幾個方面對用戶進行提問:

  • 產品功能:使用產品都做些什么
  • 使用頻率:產品哪些功能使用較多
  • 用戶偏好:你喜歡產品的哪些方面,討厭哪些方面
  • 異常情況:在使用過程中遇到問題會如何解決

在實際訪談過程中根據用戶的回答進行引導性提問。

③ 開放式與封閉式問題相結合

開放式問題可以讓用戶更詳盡的回答問題,得到更豐富更有價值的信息。封閉式問題讓用戶簡短回答,通常在訪談過程當中會遇到用戶聊著聊著跑題的情況,在這種情況下不能直接打斷用戶,可以通過封閉式問題提問的方式,如你會……你是……讓用戶回答Yes or No來結束跑題的回答,在下一個問題時將用戶拉回正題。

④ 關注目標而不是任務

如果可以觀察用戶使用產品(競品)完成任務的過程時,不要過分在意用戶完成任務的細節,要找到用戶的目標,有時用戶完成任務的過程是繁瑣的、并非最優的,只有了解了用戶的最終目標才能設計出更好的任務解決方案。

⑤ 用戶不是設計師

在和用戶探討某一訴求或需要解決的問題時,避免讓用戶提出解決方案,大多時候用戶提出的解決方案都帶有主觀色彩,并非最優方案。如果用戶侃侃而談他認為的解決方案是,可以利用用戶提出的解決方案作為跳板,從而繼續了解用戶的解決方案是為了解決哪些問題,從而更深入的發現用戶需要解決的問題與訴求。

⑥ 鼓勵用戶講故事

鼓勵用戶介紹使用產品的具體事例,可以更加形象的了解用戶的使用場景、訴求以及對產品的期望,通過具體的細節發現更多有價值的信息。同時用戶講出的故事更是產品設計階段構建用戶故事最好的素材。

⑦ 避免誘導性提問

在訪談過程中,不要提出誘導性的問題以暗示用戶回答自己想要的答案。如:

“A功能對你有幫助對么?“

“如果可能,你會選擇B功能進行使用對么?”

采用誘導性提問容易讓用戶產生偏見、無法得到精準的信息。

⑧ 真需求&偽需求

需求是從用戶身上獲取的,可是這又會出現一個問題。如果你問一些經常使用陌陌的用戶,“你為什么喜歡用陌陌呢?”可能他們會說因為陌陌可以認識更多朋友,結交下更多友情。但是,陌陌的需求真的是為了滿足用戶認識熟人的需求么?稍微了解一些這個產品的人都知道這并非真實需求,陌陌真正滿足了什么需求,不用我說大家都知道。

陌陌說明了什么,說明我們的用戶有時候表達出來的需求是一種偽需求,也就是他表達出來的和內心想要的是不一致的。這時候就需要產品經理在和用戶進行訪談過程中去判斷用戶提出的需求是真需求還是偽需求。

如何判斷需求的真偽,這就用到上面提到的關注用戶目標而不是任務,在和用戶聊天的過程中,挖掘用戶的目標,根據用戶目標判斷用戶的真實需求是什么,從而提高在用戶訪談過程中挖掘用戶需求的效率。

3)訪談后

在訪談的過程中會記錄下訪談內容和產品經理認為有價值的信息,訪談對象通常不會只有一個。在進行完全部的訪談活動后,對所有訪談用戶的訪談記錄進行整理,通過對比、分析發現其中相似的用戶需求以及問題,對有價值的內容進行提煉為后期產品設計提供決策。

3. 調查問卷

用戶訪談會面對少量目標用戶進行深入訪談,從而獲得更加精確的需求,那么如何驗證少量目標用戶的需求和大量目標用戶的需求是否一致呢?這里就用到了調查問卷方法。調查問卷屬于定量分析,通過面向用戶群進行問卷投遞,回收用戶填寫好的調查問卷,整理問卷結果得到大體量目標用戶的需求信息。

調查問卷流程:

(1)發現問題,明確目標

通過用戶訪談得到的需求結果,根據小體量用戶的需求來測試是否符合更大體量用戶群體的需求。

(2)設計調查問卷

  • 問題難度由易到難
  • 問題數量在10-15之間,讓用戶很快可以完成
  • 封閉式問題為主,選擇或者判斷,適當設計1到2個開放式問題讓用戶回答

(3)投放渠道選取

不同的投放渠道決定了目標用戶群體的質量以及得到結果的好壞。針對目標用戶獲取的渠道進行調查問卷投放會得到較好的結果。

(4)收集與分析數據

對調查問卷進行收集以及問卷答案進行分析,得到更多目標用戶的需求信息。

(5)輸出報告

通過定性、定量的需求獲取與分析,得到產品的需求信息,形成報告展現。

4. 競品分析

(1)競品分析是什么?

孫子兵法中有一個著名的軍事思想叫做:知己知彼,百戰不殆。這個思想在產品經理的日常工作中也是十分有用的。競品分析就是選取市場上與自己產品的定位、用戶群體以及功能相似的產品,通過對這些競品的分析,得到結論并支撐自己產品的設計、優化及運營策略制定。

(2)競品分析的目的

競品分析最終會以競品分析文檔的形式展現到產品團隊、領導等所有和產品利益相關的人面前。如何完成一份合格的競品分析文檔,是一個產品經理需要掌握的基本功。在動手做競品文檔之前,要先明確一個問題,就是為什么要做競品分析文檔?

根據目的的不同,競品分析文檔的側重點也會不一樣,如:

  • 新產品立項,對競品分析確定新產品的設計方案
  • 對產品的某個功能模塊進行優化
  • 改善產品交互設計、視覺設計

明確了競品分析文檔的目的后,就可以有針對性的收集競品資料、數據,如你的目的是為了對現有產品的某個功能模塊進行優化,那么你可以主要收集競品相似功能模塊的資料:模塊的設計架構、模塊用戶使用頻率等。將收集和整理的資料和自己產品的放在一起進行對比、分析,從而找到自己產品的不足,制定優化方案。

(3)兩種常用的競品分析思路

收集好的資料和數據如何整合形成文檔?這里提供兩種常用的競品分析思路,不同的競品分析目的可以從不同的角度進行分析。

1)用戶體驗要素法

用戶體驗要素是一本講用戶體驗的書,作者將用戶體驗要素由下到上分成了戰略層、范圍層、結構層、框架層和表現層五個層次,從抽象到具體。通過對這五層的設計來闡述如何做到更好的用戶體驗。這里采用用戶體驗要素的思維,對競品進行分析。

用戶體驗以及五要素的分析,會在后文著重闡述,這里為了競品分析方法先對用戶體驗五要素概念進行簡單描述:

  1. 戰略層:對產品用戶需求以及產品目標層面的分析。通過對競品在這個層面的分析,給自己的新產品設計以及戰略方向提供指導和建議,同時也可以發現自己與競品的不同或自己的競爭優勢。
  2. 范圍層:對產品功能和特性的分析。通過對競品功能分析,為自己的新產品功能設計或產品現有功能改版提供指導意見。
  3. 結構層:對產品信息架構、交互設計的分析。通過對產品結構層分析,了解產品內容組織結構、交互操作使用方式,利于自己產品的設計和優化。
  4. 框架層:對產品頁面布局、導航設計等界面設計的分析。同樣也是為了新產品的設計或界面改版提供建議及方案。
  5. 表現層:對產品視覺設計的分析,如產品的UI設計、顏色、排版風格等。通過表現層的分析發現用戶群體的行為偏好和使用習慣,為新產品設計提供參考。

可以發現,用戶體驗五要素法對于新產品的設計或者現有產品的優化、改版有很大的參考作用,當你的競品分析目的符合用戶體驗五要素時,可以采用。

2)用戶、功能、數據法

顧名思義,通過用戶、數據、功能三個維度,對競品進行資料收集形成文檔。

  1. 用戶分析:對產品的用戶群體劃分,核心用戶、主流用戶、大眾用戶以及用戶比例構成。
  2. 功能分析:對產品的核心功能以及主要功能進行分析,為新產品的功能設計或優化提供參考。
  3. 數據分析:對產品的整體數據、數據趨勢以及功能數據進行收集對比,用數字說話。

用戶、功能、數據分析法是從產品的維度進行分析,通過對數據的采集、對比,形成鮮明的分析結果,對競品分析目的提供更好的支撐作用。關于數據采集方法,在下面的實戰案例中會進行介紹。

(4)形成競品分析文檔

很多人在接觸到產品經理的時候,都會說產品經理一定要會寫各種各樣的文檔。沒錯,競品分析文檔就是這眾多的文檔中的一種。緊接著肯定會有很多人會想,那競品分析文檔有沒有模板呢?這就是國人思維模式中的一個定式,提到任何文檔的寫作方法時都會先找模板。在這里,筆者也提供一個競品分析的文檔結構,但是這里要說明很重要的一點:具體問題具體分析,沒有任何一個方法是萬能的,模板也一樣,對于產品小白和菜鳥來說,前期模板的學習可以提供參考,為以后形成自己的文檔作為鋪墊。

文檔可以是ppt、word等任何你能表達清楚你的想法的格式,關鍵是要表達清楚你的想法和目的。

(5)實戰案例

在這里提供兩種競品分析方法的競品分析文檔各一份,第一份為基于用戶體驗要素法對 Best Product 進行的競品分析文檔,另一份為基于用戶、功能、數據法對在線英語培訓產品的競品分析文檔。

1)點評類產品競品分析文檔

2)在線英語培訓產品競品分析

需求管理

通過定性和定量的方法獲取到產品需求之后,下一步要對獲取到的需求進行整理并分析,明確哪些需求先做哪些需求后做,同時將需求提交給產品的研發團隊讓產品進行開發階段。

在這里對于需求的整理和管理,介紹三種常用的方式:用戶畫像、需求列表以及PRD需求文檔。

1. 用戶畫像

用戶畫像這個概念在市場分析形成BRD文檔的章節已經出現過,當時并沒有針對用戶畫像進行展開,這里我們先回顧下當時出現的用戶畫像:

用戶畫像是我們將獲取的需求進行整理,將需求與目標用戶相結合從而形成了一個具體的“人物”,為這個人物附加了一定的屬性并且構造了一個“真實”的故事。

用戶畫像可以幫我們更好的明確產品需求點,讓產品團隊以及研發團隊成員在進行產品設計以及開發的過程中可以通過具象化的用戶畫像清晰產品的需求,不至于在設計或開發過程中憑自己的想象來創造一個和實際不相符的產品。

(1)用戶畫像包含的要素

  • 用戶的基本屬性,如:照片、性別、性別、年齡、職業、居住城市、教育背景及和你產品有密切關聯的基本信息
  • 用戶特性,基于產品的用戶介紹,即圍繞產品的用戶描述
  • 用戶目標,即用戶為什么使用你的產品
  • 用戶故事,給用戶一個使用產品的場景,明確用戶在什么情況下會使用這個產品以及用產品做什么

(2)用戶畫像要點

  • 用戶畫像更關注用戶的目標和行為模式,我們將不同目標、行為和觀點的用戶劃分出來,構建了用戶畫像。一個產品的目標用戶群體可能劃分成幾大類,那么針對每一類的用戶群體都要構建一個用戶畫像
  • 用戶畫像并不是某一個具體用戶的縮影,用戶畫像應該代表一類用戶特點

2. 需求列表

需求列表通常是通過表格的形式對需求進行管理,將獲取到的所有需求通過列表進行管理,保證需求完整性確保需求不會被遺漏。

需求列表元素說明:

  • 提交人:記錄需求的提交人,在對需求進行評估的時候可以找到相關的需求提交者方便溝通
  • 提交時間:記錄需求提交的時間
  • 模塊:一個產品通常由多個模塊組成,在這里記錄每個需求所屬模塊,方便需求管理
  • 需求名稱:記錄需求名稱
  • 描述:對提出的需求進行詳細描述
  • 重要性、緊迫性、商業價值、開發量、性價比:這幾個元素用來展現需求的重要程度,通過1-5數字進行表示,數字越大表示重要程度越高
  • 對接人:產品的研發團隊會有多個成員,不同成員負責不同的模塊,這里記錄每個需求對接的負責人
  • 持續時間:需求從開發到實現需要的時間
  • 項目名稱:產品項目名稱
  • 發布時間:需求實現上線或產品整體發布上線時間
  • 備注:其他還需要記錄的信息

注意,不同的公司不同的產品可能對于需求的管理會有所不同,這里只是介紹一個一般框架,大家在實際工作當中還要具體問題具體分析

3. 產品需求文檔(PRD)

產品需求文檔是產品經理需要掌握并且經常用到的文檔之一,在前面章節中我們介紹過了商業需求文檔(BRD)以及競品分析文檔,產品需求文檔是第三個經常會用到的文檔。

(1)需求文檔框架結構

(2)文檔描述

  • 文檔目的:PRD文檔的主要面向群體是研發,是在BRD文檔之后,對產品需求的進一步細化,通過結構化的語言讓研發更容易理解產品需要做的內容是什么
  • 產品目標:產品希望達到什么目標,滿足用戶什么場景下的什么需求
  • 術語縮寫:產品的業務邏輯上有很多術語,也許是技術研發人員不了解的,通過術語縮寫的解釋,讓研發人員對產品的業務邏輯更加明確,不會影響產品研發進度和內容
  • 版本狀態:通過版本狀態,修訂人以及修訂內容,讓以后接觸的人可以快速了解產品情況,同時對于產品需求變更有更明確的認知

(3)產品描述

  • 整體描述:對產品的整體信息架構以及產品的業務流程進行梳理,包含產品的整體架構以及主業務流程
  • 需求描述:針對業務流程,進行具體需求描述,細化業務需求
  • 角色區分:通常產品的使用用戶不止一種類型,在這里對所有使用產品的用戶進行劃分,對不同角色用戶的需求進行分類描述

(4)功能描述

  • 業務流程:通常一個產品會包含多個功能模塊,針對每一個細化的功能模塊,又有具體的業務流程
  • 界面原型:針對于產品設計的線框圖,這里會產出低保真或高保真原型圖,基于目前快速迭代的產品策略,一般都會輸出低保真原型圖以保證快速開發上線

在界面原型的基礎上,需添加邏輯規則和交互規則以讓研發團隊或交互設計團隊理解更多的產品細節,開發出符合產品需求的產品。

  • 邏輯規則:即產品功能點、字段的邏輯要求及限制(如登錄注冊頁面中,手機號字段首位必須為1,手機號必須為11位)
  • 交互規則:即用戶使用功能后給予的反饋是什么,如功能按鈕發生點擊、翻頁等交互動作時會產生什么效果

(5)非功能需求

根據不同產品及公司需要,這部分內容可能會有所不同。本文中實戰案例中非功能需求包括安全性、統一性、實用性等原則。

(6)其他

根據需要,加入你希望加入的內容。

關于產品需求文檔中需要設計的業務流程、原型等內容將在下一個產品經理知識體系:精益產品設計中介紹,所以具體的實戰案例將在下一個模塊中進行詳細展現。本文只介紹一下需求文檔中的框架結構。

(7)案例實戰

關于用戶畫像的實戰案例在BRD文檔中有所體現,在這里就不再過多說明了。產品需求文檔的實戰案例會在產品設計當中進行詳細說明,這里重點介紹下關于采用需求列表進行需求管理。

(8)BestProduct 需求列表

需求決策

需求經過了從目標用戶處獲取,通過用戶畫像、需求列表以及需求文檔對需求進行整理之后,到了對需求做決策的時候了。簡單來說需求決策就是決定哪些需求先滿足哪些需求后滿足,產品經理在這里扮演著皇帝的角色,擁有著無上的權利可以決定每一個需求的生殺大權。那么,這個皇帝是明君還是昏君就取決于對需求優先級的判斷與把握。

需求決策三要素

(1)需求是否可實現

需求的可實現性取決于經濟、技術能力,如果一個需求的滿足需要成本或者技術超出了團隊能力范圍,那么這個需求肯定是不能被考慮的或者說短期內不能被考慮的。所以在對需求做決策的時候,首先要考慮該需求是否能滿足,如果可以滿足再考慮其他方面的因素。

(2)需求是否滿足用戶核心訴求

從一個 idea 誕生開始,我們都在討論一個產品或者一個需求是為了更好的滿足用戶訴求而出現呢?那么在對不同需求進行評估優先級時,要考慮哪個需求是滿足用戶核心訴求的,那么那個需求以及相關的需求就是優先應該考慮實現的。

(3)需求是否滿足產品的戰略目標

產品的戰略目標是什么?歸根到底,任何一款產品的產生都是以盈利為目標的,一款不掙錢的產品不會是一款好產品。在對需求進行優先級排序是,要考慮產品的哪些需求可以幫助產品距離盈利更近一步,那么哪個需求就是需要優先實現或者作為重點關注的。

需求決策方法論

(1)緊急重要四象限法

按照緊急和重要程度分成四個象限,將需求放入到四象限中,根據需求所在象限決定需求的優先級:

  1. 緊急重要,這類需求通常是需要優先考慮和實現的
  2. 重要不緊急,這類需求通常會將需求進行分解,在版本迭代過程中逐步實現
  3. 緊急不重要,這類需求往往是領導拍腦門想出的需求然后叫你立即在產品中實現,這種情況就需要考驗你和領導的溝通了,在這里不進行過多分析
  4. 不緊急不重要,這類需求就可以直接過濾掉了

(2)KANO模型法

KANO 模型是東京理工大學教授狩野紀昭發明的一個需求分析方法,以分析用戶需求對用戶滿意度為基礎,對需求進行優先級決策。

  1. 必備型需求:用戶認為產品必須有的屬性和功能。如果沒有,用戶不滿意。如果有,最多滿意,無法形成驚喜
  2. 期望型需求:不是必須的屬性或服務,但是他們希望得到的功能。在市場調查中,用戶談論的一般都是期望型需求
  3. 魅力型需求:提供給用戶一種完全出乎意料的產品屬性和服務,給用戶以驚喜,提高用戶對產品的忠誠度
  4. 無差異型需求:無論提供與否,用戶的滿意度不會改變,用戶不在乎
  5. 反向型需求:用戶沒有此需求,提供反而會導致用戶滿意度下降,在需求中如果發現反向型可以直接忽略

根據五種需求的定義可以發現需求優先級依次為:必備屬性>期望屬性>魅力屬性>無差異屬性,將需求列表中的需求按照五種類型進行劃分,得出最終需求的優先級排序從而確定哪些需求先做哪些需求后做。

(3)其他

關于需求決策的方法還有很多種,比如專家團隊決策法,將具備產品經驗的專家組成團隊,為每個重點需求進行打分,對需求得分進行排序從而決定需求優先級。在比如A/B測試等等,有興趣的同學可以在網上尋找相關方法介紹。

版本迭代

互聯網產品尤其是基于移動應用的APP產品從登上互聯網歷史舞臺到最終的退出,都是一個迭代的過程,我們日常使用手機上的APP時經常會提示版本更新,這就是一個版本迭代的過程,隨著版本的迭代產品會增加新功能、刪除不好的功能、修復bug等等。

那么在進行需求優先級決策的時候,我們可以發現,緊急重要的需求和必備型需求應該都是產品發布時就應該具備的,而重要不緊急或者魅力型需求都可以是后續版本更新迭代的過程中逐漸滿足的。

在進行需求優先級決策的過程,也是對于版本迭代規劃的過程。需求優先級高的功能會在版本初期實現,而圍繞核心功能的相關需求或者次一級需求則會在后面的版本中持續迭代更新。

案例實戰

在這里,我們先列出 Best Product 產品的功能列表,然后對這些功能進行優先級排序。

根據緊急重要四象限,將所有功能點分為緊急重要和重要不緊急兩種:

功能按照模塊進行了區分,其中產品點評功能為產品的核心功能,所以優先級是最高的,圍繞產品點評功能的相關功能如產品展現、產品點贊、點評評論、產品列表、產品下載都是為了實現產品點評閉環流程不可缺少的功能。

再來看被我放在了重要不緊急中的功能:

(1)產品點評:其他方式

這個功能之所以放在后面版本中加入是因為通過用戶需求場景進行點評的維度比較簡單、用戶學習成本低適合在初期用戶快速適應產品玩法,但是只是單一的方式對于產品的點評又不夠全面,所以考慮在后面版本迭代中完善其他的產品點評方式。

(2)用戶上傳產品

在產品初期產品的每日推薦都是由系統后臺篩選并上傳到產品前臺展現,在產品運營后期可以考慮每日推薦多款產品以及產品可以由用戶發現并上傳到產品首頁被其他用戶點評。

(3)產品搜索

在產品發布初期每日推薦的產品只有一款,產品搜索功能雖然重要但是在前期產品數量較少的情況下搜索體驗并不好,可以放在下一個版本升級時再加入。

(4)我的關注

對其他用戶進行關注的功能也被我放入后續產品迭代中考慮,這個功能其實是為產品打造產品經理社交關系準備的,為后續版本加入社交功能提供參考使用。

在進行產品功能優先級決策上,產品核心功能以及與核心功能閉環流程相關的功能作為優先度最高的功能優先實現,針對于并不需要首先上線單有比較重要的功能則采取在產品迭代升級中逐步加入并完善。

產品迭代計劃路線圖:

版本迭代只是在產品初期的大致規劃,在產品上線后根據用戶使用反饋等各方面原因會產生動態調整,比如刪去用戶反饋不高的功能以及加入新功能等。

總結

在需求管理模塊中,本文按照一個需求的生命周期,從需求獲取,到對需求的管理,再到對需求進行決策,將不同需求按照產品版本一次加入、更新。

好的需求獲取方式保證了產品上線后獲得更多用戶青睞;對需求的高效管理,可以幫助產品經理以及整個開發團隊對產品需求更好的了解;對需求的決策保證產品的迭代、升級節奏,保證產品上線后健康成長。

系列文章

產品經理知識體系之idea管理(一)

 

作者:記小憶(微信公眾號:PM龍門陣)大擺龍門陣,陪你聊產品

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 老師,麻煩發我一份!muxiuying987@163.com

    來自陜西 回復
  2. 啟發很大,謝謝

    來自陜西 回復
    1. ^^

      來自吉林 回復
    2. &&

      來自吉林 回復