導讀這篇文章從作者自身經歷出發，復盤了寫一份優秀的PRD的方法和流程。由于公司組織結構調整，筆者換崗成為了一名產品經理，并開始接觸到了寫PRD文檔的部分，那么結....

這篇文章從作者自身經歷出發，復盤了寫一份優秀的PRD的方法和流程。由于公司組織結構調整，筆者換崗成為了一名產品經理，并開始接觸到了寫PRD文檔的部分，那么結構化PRD怎么寫？又有什么要點呢？

01 為什么會寫這個主題？

由于公司組織結構調整，我換到了另一個部門，并且承擔新部門官網設計的產品工作，到這里，我成為了一名正式的PM，從Project Manager，到Product Manager。

作為PM，需要設計產品，寫PRD文檔。

優秀的產品經理，一定會寫一份優秀的PRD。

本文主題，圍繞我寫的第一份PRD文檔。我會將V1版本，和最終交付版本進行對比，從而闡明主題，如何寫出一份結構化的PRD文檔。

對V1和最終交付版本PRD的比較，會從下面兩個維度展開比對：

1. 格式
2. 產品邏輯

在回顧的過程中，也會順帶對評審會時候大家討論的一些產品細節，進行復盤思考。

介紹一下背景：

部門官網有待優化，因此，我需要給出產品優化文檔。

我首先參考了網上的一個官網注冊登錄需求文檔，寫了第一版的PRD。寫完后，發給了組長，組長給了反饋：覺得我寫的比較像流水賬，像是意識流，不夠結構化。接著，他給了一份PRD文稿模版。

關于“結構化”這里比較有意思，蝦寶給了如下建議：

1. 什么是結構化？結構化是拆分組塊業務邏輯
2. 文字是腦子的表現，寫得不清晰，不是文檔的問題，是對業務輯的理解不夠

同時，蝦寶建議：

可以先找研發對一下需求，連接上下游的關系。然后再寫，把層次關系梳理出現，再用圖表或流程圖表現

蝦寶的建議，對我非常有啟發。如果說PRD模版給我的是一個框架，框架可以讓我有地方填東西。蝦寶給的反饋，讓我懂得了如何思考。通過思考，將經過梳理的內容正確地填進框架之中。單有框架是遠遠不夠的，還需要，知道思考如何把內容填進框架中。

拆分組塊業務邏輯，梳理業務上下游。這是思考的方式。

于此時，我終于開始知道了如何正確地用PRD文檔來表達我的需求。下面，我會仔細描述一下修改后的PRD文檔以及在評審會時候大家的討論，通過這個描述，梳理總結出正確的思考表達邏輯。

02 開始寫PRD

目錄

1. 產品背景
2. 名詞解釋
3. 產品綜述
4. 用戶故事
5. 需求詳述
6. 評審記錄
7. 其他問題描述

對于每一個小模塊，我都會分別從3個方面闡述：含義解釋、PRD描述正文、以及注釋。

含義解釋是從定義上界定該模塊需要描述的內容，PRD描述正文是PRD文檔中我對該模塊的詳細展開，注釋是解釋為什么PRD描述正文會這樣展開，背后的思考邏輯。

1. 產品背景

1.1 背景概述

含義解釋：背景概述是用簡單的語言大概概括一下大的背景，讓人知道我們本次要講的內容大概是什么。

描述正文：官網為用戶提供產品試用，目前，完整的試用流程如下：

用戶在官網進行注冊，填寫申請試用表單。商務（運營）在管理后臺，對用戶的申請進行授權操作（允許/拒絕）。

注釋：這樣的背景描述，是將云官網，本次的產品需求，用業務流程串聯起來，從前端到后端。從業務流程出發，將業務串聯起來，這是一種非常好的方式。用一個事件，將涉及的所有產品功能都串聯起來，讓本次討論有主線。

1.2 問題與機會

含義解釋：問題與機會描述我們希望通過這個產品需要解決的問題，或者是我們正在尋求的機遇。一般來說，這段話的作用在于讓人閱讀后明白我們為什么要花時間做這件事，以及明白了這件事的意義所在。重點在WHY，關于WHY的重要性，大家可以看一個演講叫做How great leaders inspire action。

1.2.1 當前流程存在如下問題

描述正文：

1）用戶端（官網）：

• 試用注冊流程繁瑣
• 試用申請表單無法支持用戶身份區別（企業/ 個人）
• 未申請試用的用戶進入到控制臺，無任何提示

2）運營端（管理后臺）

• 無法查看用戶申請試用的時間
• 不支持運營就試用用戶跟進做記錄
• 需要為每個申請試用的用戶手動開通賬號

注釋：在這里我將問題進行了拆分，將前端與后端做分別描述。

1.2.2 我們的優化目標/機會

描述正文：通過優化，讓來到官網的用戶，可以體驗良好的進行注冊、申請試用產品。

注釋：目標的制定，如果按照管理大師德魯克在《管理實踐》中提出的目標管理方法原則來制定，更好。順便回顧一下，德魯克提出的SMART目標計劃

1. 目標要具體
2. 目標要可衡量
3. 目標要可實現
4. 目標要相關
5. 目標要有實現性

1.3 邊界界定

含義解釋：明確界定產品規劃的界限，列出不在此次版本產品規劃之內的需求。有利于在未來討論時不用反復出現“那我們做不做這個？做不做那個”的討論。

描述正文：暫無

注釋：值得說明的一點，其實有時候，設計資源、研發資源也會左右邊界的界定。

2. 名詞解釋（可選）

含義解釋：名詞解釋表，用于列舉和解釋PRD文檔中產生的新名詞。這一點實在是太重要了，如果在PRD文稿中出現了大家不知道含義的名詞，那就是一份非常糟糕的PRD。

3. 產品綜述

名詞解釋：產品需求指從用戶的視角撰寫的聲明。例如“我希望通過這個產品我可以實現……”它不需要包含具體的實施細節，也不需要寫具體的界面元素。它們只是對于產品成功的一些具體表現。

描述正文：暫無

注釋：在產品需求這里的定義值得細細分析，產品需求是說，從用戶的角度出發，希望通過這個產品可以實現，而不是簡單的功能描述！

4. 用戶故事

名詞解釋：每個用戶故事是描述了一段獨立的end-to-end的使用體驗。它包括：用戶畫像（persona），使用場景（context), 使用意圖（intent)，步驟（flow)，產品價值（value, 產品如何幫助用戶實現價值），以及優先級（priority）一般優先級最高的進入MVP（minimal viable product), 然后依次類推，優先級最低的進入backlog，大家有空有資源再考慮實現。

描述正文：暫無

5. 需求詳述

5.1 需求一

在試用注冊流程簡化，同事小A提出了疑問：“當判斷用戶是否登陸時，如何用戶未登陸，那么應該跳轉到登錄頁面，而不是注冊頁面。”

我對此進行了解釋，但解釋比較糟糕，并沒有很好地defend myself：

1. 我們官網To B，受眾小，其實是沒有什么用戶來注冊的。
2. 如果用戶已有賬號，網站支持登錄狀態保持，那么其實不需要重新登錄

因此，我將判斷未登陸的用戶，下一個頁面是注冊頁面。

顯然，我的解釋，并不能讓小A滿意，他補充到：

1. 我們目前官網邏輯的都是跳轉到登錄頁
2. 網站支持的登錄保持狀態，其實也是有時效性的

當這里，我其實有點不知道怎么解釋我的觀點了。同事小B幫我解釋：

目前我們官網的注冊用戶比較少，絕大部分來到官網的用戶，都是新用戶，大家都需要注冊，我理解這個設計邏輯是以優化新用戶注冊流程為導向的

聽到同事小B的解釋，我都要淚流滿面了。他準確地表達出了，我沒有表達出的意思。

我講第一點，我們官網目前沒有什么用戶是已注冊的，表達的意思就是，目前來官網的用戶，大部分都是新用戶，新用戶需要經過注冊、登錄，才能申請試用我們的產品，因此我們的目標是降低新用戶試用我們產品的門檻。

暫停一下，我再放慢速度，重新回顧一下這里的思考邏輯。

為什么我要設計這樣的產品，我是設計給誰使用的，來到我們網站的用戶，他們是誰？他們為什么來？按照這個思考方式，我重新來闡述一下我的思路。

我們的網站To B，目前存量用戶少。我們的需求是，通過運營活動，或者自然流量，來到官網的用戶，能夠在最快時間內完成申請試用，只有試用了我們的產品，才有可能推進下一步。同時，每增加一個步驟，用戶就會減少一些。因此，我的設計原則是，通過減少注冊環節，來盡可能得提高注冊成功率。

分解一下：

• 目標： 縮短注冊流程，盡可能地讓來到官網的用戶都注冊。
• 邏輯：每多一個環節，用戶就大量流失
• 我的操作 ：將用戶鏈接到注冊頁面

對上一個爭論點復盤完畢，我們來看下一個爭論點。

用戶完成注冊后自動登錄，是否會跳轉會產品試用頁面。

在這個產品設計實現的前提是，用戶注冊之后，會自動登錄。我先去看看，這個自動登錄的功能是如何實現的[注冊成功后自動登錄 – ThinkPHP5.1 – php中文網博客](https://www.php.cn/blog/detail/7587.html)

注冊后自動登錄這個功能技術上是完全可以實現。但是，自動登錄后是否需要跳回申請試用頁面？

這是我們討論的重點，另一位同事提出，不需要，這個對開發的工作量要求比較大。并且，不跳轉回試用頁面，用戶自己回去點擊試用，其實也沒有很大區別。

這里哦，其實是因為我在設計產品流程的時候，沒有考慮工作量。這從側面確實是說明我在這一塊知識積累不充足。需要有一定改進。（產品經理也需要站在研發的角度考慮問題奧！）

5.2 需求二

講述優化后的產品試用申請，我的邏輯是，先給大家展示原來的申請試用頁面，然后講述修改版本后的申請試用頁面。

通過最近的工作，我發現，對比在產品經理的工作中是非常重要的一部分。因此，產品經理的工作，很多時候都是在對原有流程，做完善和優化。

既然是完善和優化，那么產品經理就需要向運營、向研發證明，為什么這樣的修改，相較于原來的流程，更好。

因此，對比是與研發和運營溝通中，非常重要的一點。產品經理要讓運營知道，修改后的產品邏輯，可以更好的支持業務運轉；產品經理也要讓研發知道，修改后的產品邏輯，是更有價值的，并沒有浪費研發的工作，并沒有讓他們的汗白流（在被組長說了幾次之后，終于有的領悟，心酸）

我總的講述邏輯是沒有問題的，但一個小問題在于，在講解修改版本后的申請試用頁面的時候，沒有邏輯。重溫一下，《金字塔原理》里面的講述邏輯，在我們寫文章或者講述業務時候，我們的思想必須符合以下原則：

畫重點，我們必須有明確的理由說明，為什么要把第二個原因放在第二個，而不是放在第一個或者第三個。為什么說這個呢？因為在講述申請試用頁面的修改時候，我的講述是沒有邏輯的，讓我們來看看我在會上的講述是多么沒有邏輯：

1. 對聯系電話進行了刪除
2. 添加了身份屬性，企業用戶和個人用戶

接下來對企業用戶身份屬性和個人用戶身份屬性進行了分別描述

更好的講述邏輯示例是什么？

我將從增刪兩個角度來說明，我們對該申請試頁面的修改。

在增加部分，我們添加了身份屬性，企業用戶和個人用戶。

在刪除部分，我們將聯系電話進行了刪除。

接下來，分別說一下增加和刪除的背后邏輯。增加身份屬性，是為了方便運營開展工作，刪除聯系方式是因為在注冊環節，用戶已經填寫過聯系電話，并且通過驗證。

總分的方式，首先讓大家知道我描述的總體內容是什么，界定范圍，給聽眾安全感，然后分點描述，這才是更好的描述方式。

接下來示例如下：

用戶可以在身份屬性這里，對個人的身份屬性做選擇。當選擇企業用戶時候，當前默認頁面不做變化；當選擇個人用戶時候，當前默認頁面做變化；相對應的最下方的三個輸入框會進行變化，分別變成：

1. 研究方向
2. 身份
3. 您期待產品為您解決什么樣的問題？

在研究方向這里的講述沒有什么好復盤的，重點來看看身份這里。

身份選項這里我在評審會上的講述，堪稱災難，毫無邏輯。會后反思，我應該首先介紹，身份這里的產品設計是什么，接著再描述為什么要有身份這個設計。

示例如下：

在身份設計，我們通過下拉框的方式，提供給個人用戶兩個選項“ 在校/在職”。

個人用戶的身份屬性字段，是為了方便運營工作的開展，在校和在職身份，可以輔助后續的用戶畫像分析，對兩個維度有幫助：

• 用戶付費能力分析
• 拉新渠道質量分析

注釋：如果我的講述邏輯是，產品功能設計是什么，設計這樣產品功能的背后邏輯，那么我的講述就會更簡潔明了，提高同事的體驗。

03 總結

本來還想繼續寫，但是涉及業務層面的知識太多了，講解起來非常費力，就寫到這里吧～以后有時間再繼續更新。

所以，如何寫一份結構化的PRD？

思考原則：拆分組塊業務邏輯，梳理業務上下游。

最后，感謝可愛組長、蝦寶對我的指導～

本文由 @一顆西蘭花 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議