這篇文章從作者自身經歷出發，復盤了寫一份優秀的PRD的方法和流程。由於公司組織結構調整，筆者換崗成為了一名產品經理，並開始接觸到了寫PRD文檔的部分，那麼結構化PRD怎麼寫？又有什麼要點呢？
01 為什麼會寫這個主題？
由於公司組織結構調整，我換到了另一個部門，並且承擔新部門官網設計的產品工作，到這裡，我成為了一名正式的PM，從Project Manager，到Product Manager。
作為PM，需要設計產品，寫PRD文檔。
優秀的產品經理，一定會寫一份優秀的PRD。
本文主題，圍繞我寫的第一份PRD文檔。我會將V1版本，和最終交付版本進行對比，從而闡明主題，如何寫出一份結構化的PRD文檔。
對V1和最終交付版本PRD的比較，會從下面兩個維度展開比對：
格式產品邏輯在回顧的過程中，也會順帶對評審會時候大家討論的一些產品細節，進行復盤思考。
介紹一下背景：
部門官網有待優化，因此，我需要給出產品優化文檔。
我首先參考了網上的一個官網註冊登錄需求文檔，寫了第一版的PRD。寫完後，發給了組長，組長給了反饋：覺得我寫的比較像流水帳，像是意識流，不夠結構化。接著，他給了一份PRD文稿模版。
關於「結構化」這裡比較有意思，蝦寶給了如下建議：
什麼是結構化？結構化是拆分組塊業務邏輯文字是腦子的表現，寫得不清晰，不是文檔的問題，是對業務輯的理解不夠同時，蝦寶建議：
可以先找研發對一下需求，連接上下遊的關係。然後再寫，把層次關係梳理出現，再用圖表或流程圖表現
蝦寶的建議，對我非常有啟發。如果說PRD模版給我的是一個框架，框架可以讓我有地方填東西。蝦寶給的反饋，讓我懂得了如何思考。通過思考，將經過梳理的內容正確地填進框架之中。單有框架是遠遠不夠的，還需要，知道思考如何把內容填進框架中。
拆分組塊業務邏輯，梳理業務上下遊。這是思考的方式。
於此時，我終於開始知道了如何正確地用PRD文檔來表達我的需求。下面，我會仔細描述一下修改後的PRD文檔以及在評審會時候大家的討論，通過這個描述，梳理總結出正確的思考表達邏輯。
02 開始寫PRD
目錄
產品背景名詞解釋產品綜述用戶故事需求詳述評審記錄其他問題描述對於每一個小模塊，我都會分別從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.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：
我們官網To B，受眾小，其實是沒有什麼用戶來註冊的。如果用戶已有帳號，網站支持登錄狀態保持，那麼其實不需要重新登錄因此，我將判斷未登陸的用戶，下一個頁面是註冊頁面。
顯然，我的解釋，並不能讓小A滿意，他補充到：
我們目前官網邏輯的都是跳轉到登錄頁網站支持的登錄保持狀態，其實也是有時效性的當這裡，我其實有點不知道怎麼解釋我的觀點了。同事小B幫我解釋：
目前我們官網的註冊用戶比較少，絕大部分來到官網的用戶，都是新用戶，大家都需要註冊，我理解這個設計邏輯是以優化新用戶註冊流程為導向的
聽到同事小B的解釋，我都要淚流滿面了。他準確地表達出了，我沒有表達出的意思。
我講第一點，我們官網目前沒有什麼用戶是已註冊的，表達的意思就是，目前來官網的用戶，大部分都是新用戶，新用戶需要經過註冊、登錄，才能申請試用我們的產品，因此我們的目標是降低新用戶試用我們產品的門檻。
暫停一下，我再放慢速度，重新回顧一下這裡的思考邏輯。
為什麼我要設計這樣的產品，我是設計給誰使用的，來到我們網站的用戶，他們是誰？他們為什麼來？按照這個思考方式，我重新來闡述一下我的思路。
我們的網站To B，目前存量用戶少。我們的需求是，通過運營活動，或者自然流量，來到官網的用戶，能夠在最快時間內完成申請試用，只有試用了我們的產品，才有可能推進下一步。同時，每增加一個步驟，用戶就會減少一些。因此，我的設計原則是，通過減少註冊環節，來儘可能得提高註冊成功率。
分解一下：
目標： 縮短註冊流程，儘可能地讓來到官網的用戶都註冊。邏輯：每多一個環節，用戶就大量流失我的操作 ：將用戶連結到註冊頁面對上一個爭論點復盤完畢，我們來看下一個爭論點。
用戶完成註冊後自動登錄，是否會跳轉會產品試用頁面。
在這個產品設計實現的前提是，用戶註冊之後，會自動登錄。我先去看看，這個自動登錄的功能是如何實現的[註冊成功後自動登錄 – ThinkPHP5.1 – php中文網博客](https://www.php.cn/blog/detail/7587.html)
註冊後自動登錄這個功能技術上是完全可以實現。但是，自動登錄後是否需要跳回申請試用頁面？
這是我們討論的重點，另一位同事提出，不需要，這個對開發的工作量要求比較大。並且，不跳轉回試用頁面，用戶自己回去點擊試用，其實也沒有很大區別。
這裡哦，其實是因為我在設計產品流程的時候，沒有考慮工作量。這從側面確實是說明我在這一塊知識積累不充足。需要有一定改進。（產品經理也需要站在研發的角度考慮問題奧！）
5.2 需求二
講述優化後的產品試用申請，我的邏輯是，先給大家展示原來的申請試用頁面，然後講述修改版本後的申請試用頁面。
通過最近的工作，我發現，對比在產品經理的工作中是非常重要的一部分。因此，產品經理的工作，很多時候都是在對原有流程，做完善和優化。
既然是完善和優化，那麼產品經理就需要向運營、向研發證明，為什麼這樣的修改，相較於原來的流程，更好。
因此，對比是與研發和運營溝通中，非常重要的一點。產品經理要讓運營知道，修改後的產品邏輯，可以更好的支持業務運轉；產品經理也要讓研發知道，修改後的產品邏輯，是更有價值的，並沒有浪費研發的工作，並沒有讓他們的汗白流（在被組長說了幾次之後，終於有的領悟，心酸）
我總的講述邏輯是沒有問題的，但一個小問題在於，在講解修改版本後的申請試用頁面的時候，沒有邏輯。重溫一下，《金字塔原理》裡面的講述邏輯，在我們寫文章或者講述業務時候，我們的思想必須符合以下原則：
畫重點，我們必須有明確的理由說明，為什麼要把第二個原因放在第二個，而不是放在第一個或者第三個。為什麼說這個呢？因為在講述申請試用頁面的修改時候，我的講述是沒有邏輯的，讓我們來看看我在會上的講述是多麼沒有邏輯：
對聯繫電話進行了刪除添加了身份屬性，企業用戶和個人用戶接下來對企業用戶身份屬性和個人用戶身份屬性進行了分別描述
更好的講述邏輯示例是什麼？
我將從增刪兩個角度來說明，我們對該申請試頁面的修改。
在增加部分，我們添加了身份屬性，企業用戶和個人用戶。
在刪除部分，我們將聯繫電話進行了刪除。
接下來，分別說一下增加和刪除的背後邏輯。增加身份屬性，是為了方便運營開展工作，刪除聯繫方式是因為在註冊環節，用戶已經填寫過聯繫電話，並且通過驗證。
總分的方式，首先讓大家知道我描述的總體內容是什麼，界定範圍，給聽眾安全感，然後分點描述，這才是更好的描述方式。
接下來示例如下：
用戶可以在身份屬性這裡，對個人的身份屬性做選擇。當選擇企業用戶時候，當前默認頁面不做變化；當選擇個人用戶時候，當前默認頁面做變化；相對應的最下方的三個輸入框會進行變化，分別變成：
研究方向身份您期待產品為您解決什麼樣的問題？在研究方向這裡的講述沒有什麼好復盤的，重點來看看身份這裡。
身份選項這裡我在評審會上的講述，堪稱災難，毫無邏輯。會後反思，我應該首先介紹，身份這裡的產品設計是什麼，接著再描述為什麼要有身份這個設計。
示例如下：
在身份設計，我們通過下拉框的方式，提供給個人用戶兩個選項「 在校/在職」。
個人用戶的身份屬性欄位，是為了方便運營工作的開展，在校和在職身份，可以輔助後續的用戶畫像分析，對兩個維度有幫助：
用戶付費能力分析拉新渠道質量分析注釋：如果我的講述邏輯是，產品功能設計是什麼，設計這樣產品功能的背後邏輯，那麼我的講述就會更簡潔明了，提高同事的體驗。
03 總結
本來還想繼續寫，但是涉及業務層面的知識太多了，講解起來非常費力，就寫到這裡吧～以後有時間再繼續更新。
所以，如何寫一份結構化的PRD？
思考原則：拆分組塊業務邏輯，梳理業務上下遊。
最後，感謝可愛組長、蝦寶對我的指導～
本文由 @一顆西蘭花 原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議