PM 工作流程解析與怎麼寫 PRD

胡立推薦的是原作者的第九篇文章，【產品經理 PM｜需求文檔 PRD】優惠券發放的產品設計，需求文檔怎麼寫？ 原作一系列的九篇好文：產品經理 PM 必備技能方法論系列文｜作品集目錄、課程學習、工作內容

這九篇文章是以產品經理的角度在說明他們的工作流程，但我這裡嘗試以一個「未來可能會與 PM 一起工作，理解 PM 的角度」閱讀文章，以下為略讀筆記：

一、如何分析產品：

【產品經理 PM｜視角分析】如何分析「得到 App」？

1. 基本功：

a. 認知：分析產品、開拓視野，以獲取更多經驗值

b. 還原：拆解產品，模仿產品工作流程已達到對產品的理解

c. 創造：根據上述兩者，結合自身經驗進行創新設計

2. 用戶是資源；付費的才是客戶

3. 怎麼判斷產品好不好？

a. 用戶場景：什麼樣的用戶，什麼情況下會用，滿足了哪些問題需求？

b. 用戶流向：用戶從哪裡來，到哪裡去，流向是否清晰？

c. 信息流向：內容（信息）從哪裡來，到哪裡去？

d. 產品長短線：產品驅動/技術驅動/運營驅動/銷售驅動？

e. 未來的判斷：產品節奏、運營節奏、商業變現節奏的表現？

二、需求分析

【產品經理 PM｜需求分析】收集「foodie」用戶反饋，制定行動計畫

收集用戶反饋可以「感知用戶需求」、「把需求分析排序」，並且「學習用戶語言」、「理解用戶期待是否被滿足」、「最困擾用戶的問題是什麼」

寫到這裡，感受到跟用戶建立連結是很重要的，這樣用戶對你有信任感，才會願意給你更多反饋。

三、優先級排序

【產品經理 PM｜優先級排序】好豆APP 希望加入「直播」功能，透過用戶調研，分析是否靠譜？

需求排序的四個維度：頻率、難度、價值、用戶輪廓（對目標用戶的熟悉度）

這裡有功能開發優先順序的排序以及方法介紹。

四、功能點分析

【產品經理 PM｜功能點分析】分析三款社交產品在內容發佈上的差異

PM 其實很難從零到一體驗開發流程，大部分都是「對既有產品進行優化」，基本上可以從「用戶需求」、「使用流程」與「業務邏輯」，三個層面去作分析

五、流程圖製作

【產品經理 PM｜流程圖製作】網易雲音樂登錄流程還原

本篇重點在如何繪製流程圖？在產品設計中的作用？推薦的流程圖工具？

原文作者推薦以下三種流程工具：

Axure：一套挺完整的原型與流程圖設計工具

Visio：Windows 系統下的工具

ProcessOn：基於瀏覽器的線上流程圖，方便團隊協作

或者可以參考這篇 10款最好用的流程圖軟體推薦(2021更新)

個人想嘗試的有 Creately、Draw.io 來體驗一下流程圖怎麼畫

Draw.io 中文線上製作流程圖首選！專業水準完全免費

也可以參考這篇文章 產品PM必懂！「流程圖」的畫法及變形應用

基本上，一個流程包括六大部分：角色、任務、順序、輸入、輸出、標準化。

裡面一個很棒的例子為把流程圖的繪制想像成「要蓋一個辦公大樓」的「設計藍圖」。

流程圖裡面的長方形、菱形還可以有不同規範作用，符合某種標準的格式。

a. 圓角矩形：開始或結束

b. 矩形：要執行的動作

c. 菱形：判斷

d. 箭頭：有文字可增加說明（Y or N），沒有文字代表方向

e. 方形括弧：註解與說明

f. 矩形中包著另一個矩形：子流程

文中以「網易雲音樂App」舉例流程圖，非常值得一看

六、頁面原型圖製作

【產品經理 PM｜頁面原型圖製作】AppSo 頁面原型圖還原與設計

這篇文章透過問答來解釋怎麼畫、為什麼畫、給誰看原型圖，設計常用工具第一個居然是紙筆！我以為一開始就會進軟體畫...其實也是，開會討論一定是紙筆跟白板比較快。

七、產品調研

【產品經理 PM｜產品調研】網易蝸牛讀書「寫書評」功能點調研報告

本篇重點在如何結構化表達產品調研報告？

簡單說就是當競品或自家產品有新功能時，怎麼做產品調查分析。

這裡以「網易蝸牛讀書」作為範例

八、產品調研

【產品經理 PM｜產品調研】網易蝸牛讀書 v.s 多看閱讀分析報告

本篇重點在如何結構化表達獨立的產品調研分析報告？

跟上一篇相比，可以看成第七篇給了大方向，第八篇則是深入探討單個產品研調。

九、如何寫需求文檔 PRD

【產品經理 PM｜需求文檔 PRD】優惠券發放的產品設計，需求文檔怎麼寫？

PRD 怎麼做？

1. 項目背景與需求分析
2. 本次需求的目的，以及功能列表
3. 產品模塊以及所有交互流程
4. 簡要的用例介紹（前台與後台原型圖）
5. 考核指標與計算方法

需求文檔的內容包含產品背景、定義需求、流程與邏輯、原型和交互等。

小結：

這篇文章以「跟 PM 一起工作，嘗試了解他們的工作流程以建立更好的合作關係」的角度來閱讀，理解了一個產品從零開始可能會怎麼製作，裡面其中有哪些細節。

對應到我現在開發的網站上，我想應該不用「真正寫一份 PRD」，畢竟開發規模不大，最重要的概念就是「找對問題及解決問題」，因此我可以下面兩個方向實作：

1. 簡單紀錄文件變化

2. 畫出流程圖給客戶看