你連PRD都要被懟，還叫什么產品經理！

應該算是第一篇文章，我覺得標題起得應該還算不錯，嘿嘿嘿嘿～～

其實我今天就是想和大家聊聊：PRD 「產品需求文檔」以及如何寫好一個PRD。

說得夸張一些，PRD的好壞直接決定了產品經理基本素養(yǎng)。曾經有一段時間，我對所有產品面試者的要求是，帶一份PRD過來。如果面試過了，我會再看看PRD。為什么？因為面試能騙人而PRD很難騙人。因為這個原因，曾經被我槍斃了不少面試過關的童鞋。

我曾經看到過很多產品童鞋在PRD的評審會上，直接被研發(fā)懟得下不來臺，也見過一些產品用一份PRD就把臺下的研發(fā)搞得熱情高漲，恨不得馬上開工把產品做出來。

下面我就和大家說說，一份能夠征服研發(fā)的PRD應該如何完成。

一份合格的PRD，應該至少包括以下五個基本要素：

• 產品背景：講清楚這個產品為了什么而做；
• 可量化目標：產品上線后，奔著什么目標而去；
• 產品的基本運營方案or邏輯：產品上線后，怎么樣保證產品的內容可以快速推廣落地；
• 交互稿：交互邏輯清晰的交互稿；
• 產品邏輯描述：能夠把產品內在邏輯寫清楚的正文；

我看過的RPD里，絕大部分只包含4、5這兩個部分。所以大家明白問題出在那里了嗎？

下面我和大家講解一下各點要怎么寫、注意點是什么。

1. 產品背景

產品背景就是：要給團隊介紹清楚，為什么啟動這款產品或這次迭代；目的就是：為了把團隊的想法統一，這樣研發(fā)、運營也會知道發(fā)力點在哪里。

在產品背景里至少要交代清楚2點：

• 有數據支撐的產品、業(yè)務現狀是什么樣的。舉個例子唄，舉個例子唄，舉個例子唄，舉個例子唄，舉個例子唄，舉個例子唄，舉個例子唄
• 產品要解決什么問題。這個問題描述得越細致就越好，也就是通常說的足夠聚焦，千萬不要大而空洞。比如解決人類吃飯問題，這種看著就沒營養(yǎng)。如果足夠聚焦，那么可以改成解決非洲某個貧困村莊的吃飯問題，這樣就會具體很多，而且看上去也容易下手。

我舉個真實的栗子，這個是在需求評審時，某PM用的產品背景介紹：

按照以上的內容羅列，其實不用說，整個團隊也都知道，我們接下來的產品是為了解決物流速度慢的問題。通過有理有據的說明，被懟的概率直線下降，大家只會覺得這個太應該做了。

2.?可量化目標

可量化目標，這個東西就比較簡單了。就是產品上線及運營一定時間后，預期產品、業(yè)務所產生的可量化變化情況。

這個時候很多童鞋會說，“啊啊啊啊，我做的東西沒法量化呀～”之類的話，這種情況，按我前老板的說法就是：凡事不能量化的事情，一律都是沒想明白的！言下之意就是：不能量化的事情咱們不干，就是那么霸氣！

還是前面的栗子：解決人類吃飯問題，那么解決了多少叫解決，是一千萬還是一個億？吃飯問題怎么定義才叫解決，是一日三餐還是一日兩餐甚至是保證一日一餐？如果這個問題要量化，那么至少要也應該寫成：確?，F在一日一餐的5億人口，能夠變成一日兩餐，且每餐要保證XXX熱量的攝入。所以，不能量化是因為沒有想到問題的本質上去。

當然，還有一種情況，可能可以不要有量化目標，那個就是傳說中的「老板項目」。不過你如果有足夠勇氣，敢于正面剛老板一次，我估計大部分老板一定會給你一個量化目標的。

還是上面的那個若干年前的產品，我把目標曬出來給大家看看：

其實定一個目標并不難，難點在于這個目標的合理性。

除了老板拍腦袋之外，主要的方式有：

• 參考行業(yè)通用標準；
• 參考競對標準；
• 通過邏輯推導；
• ……

以后有機會這塊可以詳細講講。

3. 產品基本策略及運營方案

產品策略：就是產品本身需要覆蓋哪些內容。運營方案：就是上線后，如何推廣運營，保證產品能夠快速落地。

沒人使用的產品肯定不是好產品。產品策略是能夠保證產品不會半途而廢的要點。在很多大公司，產品上線沒人鳥的情況太多了，這時就需要事先準備好靠譜的運營方案。

一般來說，第三點是絕大部分產品所欠缺的。在很多產品眼里，產品上線就完了，剩下好不好，估計要看“運氣”。但事實恰恰相反，一個優(yōu)秀的產品，在設計之初就會有策略和最基本的運營推廣方案。

還是以解決人類吃飯問題為例子：

產品策略就是：貧困地區(qū)一律改種土豆（土豆的畝產高，適應性強），基本運營方案就是：選擇100個貧困村莊開始試點，逐步推廣等等。有了這樣的內容作為依托，能夠讓整個團隊放心跟你走。

還是上面的那個若干年前的產品，我把策略和方案也弄出來給大家看看：

紅框部分就是產品策略，藍框部分就是基本運營方案。大家看看感受一下，實際上的策略和方案比這個詳細很多。如數據產品應用中就包含了搜索權重、活動報名等內容。

4. 交互稿、產品邏輯描述（PRD正文）

這兩個內容，我放在一起說。因為這個是一般產品經理日常最最長用到的東西，也是一個基本功。

所以在這里，我只想提醒大家：交互稿和PRD正文，請做到有多詳細就寫多詳細的地步。盡量不要省略，尤其不要讓后端、前端、測試童鞋去猜你的意圖。

在這里我不想整段的來貼PRD出來給大家，而是想舉幾個日常的例子，讓大家能夠感受一下：

1. 對于日期的描述。我經?？吹絇RD里面寫【N天后，自動關閉】，那么這個天到底是自然日？工作日？節(jié)假日？還是說以事件發(fā)生的時間為起點，增加N * 24小時之后？
2. 對于時間的描述。經常會有RPD里寫【這里顯示完成時間】，那么這個完成時間，到底要不要包含日期？時間精度如何是到分鐘還是到秒？如果是到分鐘，那么秒如何處理，是向上取整，還是舍去？

舉個栗子，我再貼一小段RPD給大家看看：

大家可以看到在這一小段的內容里，包含了：

• 數據處理的細節(jié)；
• 異常情況的考量；
• 產品運營空間的預留；
• ……

這樣的PRD正文，至少能夠表明大家有對產品本身做了深入的思考。

到這里，一份合格的PRD的五個基本要素就說完了。

最后，我還想說：PRD其實表明了大家對于產品的通盤思考的結果，并不是單單的一個產品怎么做的內容。

作者：超級大頭，微信公眾號：產品經理兩三事

本文由 @超級大頭 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議