一份高級產(chǎn)品經(jīng)理的干貨分享整理:終極prd
這世界走的再快,也與你無關(guān),一步一步成長,也挺好。
受公司學(xué)院的邀請,師父出山為廣大同事做了一次含金量超高的分享。打從上周接到邀請,師父就開始緊張兮兮的準(zhǔn)備這次分享,滿腦子都是如何做分享(偷偷告訴你們,他都沒心思工作了)。因?yàn)?,這事情關(guān)乎他的面子,我想這世上可能沒有什么比他的面子更重要的了。
他一直說“我滿腦子的東西,怎么講!” 最開始他打算把整個(gè)產(chǎn)品設(shè)計(jì)流程全部講一遍,然后一個(gè)人在那里神經(jīng)兮兮嗶嗶了一天。
我實(shí)在看不下去了,于是給他講了一下我平時(shí)聽得一些分享的情況。
我說:“大家都是已經(jīng)入門的產(chǎn)品了,其實(shí)早在我還沒做產(chǎn)品工作的時(shí)候就已經(jīng)對流程滾瓜爛熟了,但是知道流程并沒有什么卵用。我們需要的不是大的框架和虛的概念,不如你就抓住流程里面非常細(xì)小的點(diǎn)來講實(shí)際工作中的應(yīng)用”。
好在師父在懵逼的情況下聽取了我的意見。于是就有了下面的分享內(nèi)容,這里我將放出我?guī)煾傅难葜v稿,這比聽分享和看分享后整理的文檔更有參考意義(我在師父分享完之后是整理了一份分享文檔給學(xué)院的)。
主題:如何寫好一份prd(我將草稿只字不改,雖然有點(diǎn)亂,但是這樣完全代表他思考邏輯的稿子可以看出他的思維邏輯多縝密,還有絲絲尷尬和搞笑)
1.
大家好,我是家庭網(wǎng)絡(luò)產(chǎn)品線產(chǎn)品中心的產(chǎn)品經(jīng)理**,在部門主要負(fù)責(zé)路由APP的產(chǎn)品工作,很高興在這里和大家做這個(gè)分享會(huì),由于我之前從事的行業(yè)比較多,根據(jù)之前一些產(chǎn)品經(jīng)驗(yàn),結(jié)合自身的特長,總結(jié)了一套自己產(chǎn)品設(shè)計(jì)的方法,用來跟大家分享,由于時(shí)間關(guān)系,我這里著重分享下我寫需求文檔的一些經(jīng)驗(yàn),希望能拋磚引玉,互相交流學(xué)習(xí)。也希望大家能在今后的過程中能總結(jié)出自己的一套更好的產(chǎn)品需求文檔的編寫方法。
我認(rèn)為,一款產(chǎn)品的上線,產(chǎn)品經(jīng)理需要負(fù)責(zé)其四個(gè)階段:概念階段,設(shè)計(jì)階段,實(shí)施階段和運(yùn)營階段。
概念階段里我們需要提供產(chǎn)品的商業(yè)模式(即BRD)的內(nèi)容以及產(chǎn)品的市場分析(即MRD),公司立項(xiàng)一般會(huì)需要提供這兩個(gè)文檔,特別是商業(yè)模式特別重要,斐訊0元購就是一個(gè)非常好的商業(yè)模式,往往一個(gè)好的商業(yè)模式基本決定了一個(gè)互聯(lián)網(wǎng)產(chǎn)品的成敗。而市場分析會(huì)對市場環(huán)境,競品和商業(yè)對手,市場容量等等進(jìn)行評估。
當(dāng)商業(yè)和市場條件都滿足以后,我們需要確定我們的業(yè)務(wù)流程,這里的業(yè)務(wù)流程是個(gè)廣義的業(yè)務(wù)流程,意思是我們的核心交互是什么。比如商城的業(yè)務(wù)流程就是:查看商品-加入購物車-提交訂單-支付-發(fā)貨-收貨-售后;而我們路由APP的核心業(yè)務(wù)流程就是:路由設(shè)置-路由管理-路由控制。一個(gè)大型的APP往往會(huì)有多條線的業(yè)務(wù)流程。
接下來我們就要開始做競品分析了,一般會(huì)選擇相關(guān)行業(yè)里的排名靠前的,或者是比較有自己特色的產(chǎn)品,比如路由器APP,我們就經(jīng)常會(huì)拿小米,360,TP-LIANK,網(wǎng)件等等來做競品分析,競品分析的維度有:產(chǎn)品定位,功能列表,價(jià)格,市場銷量,目標(biāo)用戶,版本迭代等等。
然后我們就開始做需求分析了,也就是我們會(huì)在很多書本上看到的那些:用戶畫像,用戶場景,需求來源等等,我這里稍微提一下我自己做需求來源的幾個(gè)點(diǎn):
- 關(guān)注行業(yè)趨勢和動(dòng)向
- 根據(jù)友盟數(shù)據(jù)或者是市場數(shù)據(jù)提煉需求
- 用戶痛點(diǎn)和癢點(diǎn)挖掘
- 用戶反饋
- 競品參考
- 自身優(yōu)化。
由于時(shí)間關(guān)系,以上概念階段的要素我就不詳細(xì)展開講了,這里只是順帶提一下,讓大家有個(gè)了解。
2.
我今天要講的主要是產(chǎn)品的設(shè)計(jì)階段,從文檔上來說就是PRD-產(chǎn)品需求文檔。很多人認(rèn)為PRD就是用WORD寫寫我們需要做什么就好,其實(shí)一份完整的PRD不僅僅需要寫一份文檔來說明你要做什么,而是包括多份文檔內(nèi)容,也就是廣義上的PRD。我從文檔上和流程上把它分成四部分:邏輯流程,思維導(dǎo)圖,原型圖,以及狹義的PRD輸出文檔。
3.
首先我們要理清楚產(chǎn)品大的邏輯流程,一般是用VISIO來做這方面的工作,就和畫人像一樣我們需要先確定其三庭五眼,這樣我們的邏輯才不會(huì)走偏。
還是回到我們路由APP上來例舉,由于路由產(chǎn)品的特殊性,我們一般需要用多方交互的泳道圖來表現(xiàn)我們的產(chǎn)品邏輯,一個(gè)路由功能一般會(huì)牽涉到APP端,后臺,設(shè)備端的多方交互。
這里舉個(gè)簡單的功能來作為例子,比如遠(yuǎn)程控制路由器上的指示燈,APP端做出打開的操作,操作命令發(fā)送到云服務(wù)器,云服務(wù)器收到指令后找到對應(yīng)設(shè)備的MAC地址,然后發(fā)送到對應(yīng)路由器上打開路由器指示燈,這就是一個(gè)簡單的多方交互。我們需要用VISIO畫出這個(gè)邏輯,讓別人知道這個(gè)功能大概是什么樣子。
除了多方交互邏輯,我們有時(shí)候也會(huì)用來設(shè)計(jì)業(yè)務(wù)邏輯,業(yè)務(wù)邏輯里有時(shí)候也會(huì)有多方出現(xiàn)的情況,比如B2C的產(chǎn)品就會(huì)牽涉到B端用戶和C端用戶的邏輯流,各端用戶也會(huì)對應(yīng)到其分別的前端和后臺。邏輯流程的種類非常多,我這里就不一一例舉了,分析一個(gè)鍛煉自己熟悉邏輯流程的好辦法,每天在應(yīng)用市場下載一些推薦的APP下來,自己試著用VISIO畫出它們的邏輯流程,同時(shí)也可以學(xué)習(xí)它們的功能設(shè)計(jì)方法,這樣會(huì)讓自己的產(chǎn)品設(shè)計(jì)能力進(jìn)步的非???。
4.
邏輯流程整理清楚以后,我們就可以根據(jù)大模塊開始做思維導(dǎo)圖,我一般會(huì)用XMIND來做這個(gè),很多人會(huì)用思維導(dǎo)圖來做業(yè)務(wù)邏輯,我一般喜歡用思維導(dǎo)圖來做產(chǎn)品結(jié)構(gòu)和邏輯判斷。
一般來說做完這個(gè),整個(gè)產(chǎn)品有些什么頁面基本就都知道了。比如我的提綱,就是在寫我要講的東西的結(jié)構(gòu),不過APP的思維導(dǎo)圖里會(huì)多一些邏輯判斷在里面,舉個(gè)例子,賬號登錄,密碼輸入正確怎么樣,不正確會(huì)怎么樣,各會(huì)顯示或者是到那個(gè)頁面,就是邏輯判斷。如果大家有興趣,會(huì)下可以找我具體看思維導(dǎo)圖該怎么畫。
5.
接下來就要畫產(chǎn)品經(jīng)理最熟悉的原型圖了,我一般用AXURE來畫原型圖,經(jīng)過上面的邏輯流程和產(chǎn)品結(jié)構(gòu)以及邏輯判斷的整理,實(shí)際上到原型圖這一步,我們只需要把邏輯頁面化而已。
實(shí)現(xiàn)我們要弄清楚整個(gè)產(chǎn)品的框架與層級,打個(gè)比方,一般的產(chǎn)品框架有:登錄注冊,首頁,個(gè)人中心,設(shè)置等等,而層級關(guān)系則是登錄頁面下有:用戶名輸入,密碼輸入,已經(jīng)相對應(yīng)的判斷頁面等等。類似于這種,大家可以舉一反三,這樣一層層的去做,你就發(fā)現(xiàn)整個(gè)APP的框架就會(huì)搭建起來了。
然后我們需要設(shè)計(jì)好頁面,頁面上有什么元素,如何展現(xiàn)。這個(gè)我想大家都會(huì)畫,不過畫的好看不好看,清晰不清晰就另當(dāng)別論了。這個(gè)大家要是有興趣,平時(shí)我們可以私下探討。
不過我個(gè)人認(rèn)為原型圖的頁面一定要簡潔清晰,不要加過多的設(shè)計(jì)元素在里面,除非你是要搶UI的飯碗。很多小伙伴都喜歡把原型圖畫的特復(fù)雜。接下來就是做交互跳轉(zhuǎn)了,說到這里,肯定有很多小伙伴覺得,這不是UE的事情嗎?其實(shí)UE負(fù)責(zé)的更多的是交互的用戶體驗(yàn),而里面的交互邏輯一般都需要產(chǎn)品來確認(rèn)。而且,交互跳轉(zhuǎn)做的好,你給別人講你的設(shè)計(jì)的時(shí)候也會(huì)更輕松,思路也更清晰。
一般來說,做到這里原型圖基本上已經(jīng)完成了,不過我個(gè)人更喜歡在原型圖上繼續(xù)做標(biāo)注,第一,是為了讓UE或者程序員更清楚你的功能設(shè)計(jì),其實(shí)也為你后面寫需求文檔做了標(biāo)注提示。這里我一般會(huì)做兩種標(biāo)注,一種是邏輯說明,大的頁面之間的關(guān)系或者跳轉(zhuǎn)我會(huì)做邏輯說明的標(biāo)注;一種是功能規(guī)則標(biāo)注,一般標(biāo)注在功能點(diǎn)或者是字段上面,對具體的功能點(diǎn)做說明。
6.
接下來就是狹義上的產(chǎn)品需求文檔的編寫了,實(shí)際上整個(gè)產(chǎn)品邏輯在這個(gè)階段你應(yīng)該已經(jīng)一清二楚了。剩下的就是怎么把它表達(dá)出來,讓別人知道,這個(gè)其實(shí)還蠻難的,導(dǎo)致了很多程序員都不愛看PRD。這里我還是呼吁一下各位程序員大哥,還是給產(chǎn)品一個(gè)機(jī)會(huì),多看看PRD,謝謝。話題偏了,還是讓我們回到需求文檔上來吧!
7.
產(chǎn)品文檔一般的格式我這里就不贅述了,我這里講講幾個(gè)重要的點(diǎn)吧:首先是需求說明,很多產(chǎn)品會(huì)忽略這個(gè)東西,我這里的需求說明是要說清楚,我們?yōu)槭裁匆鲞@個(gè)需求點(diǎn)。舉個(gè)例子,之前路由APP是支持郵箱用戶的,后來因?yàn)闃I(yè)務(wù)需要,需要取消郵箱用用戶登錄,所以我這樣來寫這個(gè)需求說明:
8.
考慮到以后要上線的,比如打賞,藍(lán)汛游戲加速等牽涉到提現(xiàn)和充值的和金錢掛鉤功能,必須有手機(jī)驗(yàn)證才能確保安全。其次,現(xiàn)在斐訊所有平臺只能用手機(jī)注冊,不會(huì)再產(chǎn)生郵箱用戶,如果繼續(xù)支持郵箱用戶則后期開發(fā)需要為這些用戶做多余的適配工作,所以需要禁用郵箱用戶,強(qiáng)制用戶綁定手機(jī)。
9.
這樣大家就清楚知道你為什么要做這個(gè)需求了,這個(gè)對剛剛走上產(chǎn)品崗位的產(chǎn)品經(jīng)理還是特別重要的,你如何說服你的領(lǐng)導(dǎo),或者是其他人,讓他們覺得你做這個(gè)需求是有意義的。有時(shí)候我們也需要對某個(gè)功能寫上需求預(yù)期,也就是說我這個(gè)需求需要達(dá)成什么樣的數(shù)據(jù)指標(biāo),這樣就可以對照后面的數(shù)據(jù)分析做個(gè)對比了。
10.
接下來要寫的就是功能描述了,新入職場的產(chǎn)品經(jīng)理往往會(huì)把這塊寫的特別重,基本上會(huì)占到整個(gè)PRD的八成內(nèi)容,其實(shí)我要說的是,你可以把這塊敘述得更清晰明確,只用說明你這個(gè)需求有哪些功能模塊,模塊之間功能流程是什么樣,用戶是如何操作的。
這里很多人會(huì)有另外的寫法,喜歡把規(guī)則插進(jìn)去寫,我個(gè)人不是很喜歡這樣做,功能說明就直接描述功能是什么,會(huì)讓別人更清晰的了解整個(gè)功能操作,而規(guī)則可以寫在下面另外的模塊里,我一般叫他約束性描述,或者功能規(guī)則。這一塊在產(chǎn)品文檔里特別重要,一般的產(chǎn)品所說的有“坑”,問題就是出在這里。
11.
那我們?nèi)绾蝸肀苊膺@種“坑”的情況發(fā)生呢?
我從兩個(gè)方面來講這個(gè),第一個(gè)就是產(chǎn)品規(guī)則里需要有哪些要素,第二個(gè)就是如何自檢自己的文檔里有沒有紕漏;
首先產(chǎn)品規(guī)則里需要有:約束性描述-即這個(gè)東西只能怎么樣,功能規(guī)則-這個(gè)功能該執(zhí)行什么邏輯,這兩個(gè)東西,基本上都會(huì)有,下面的有些東西可能只會(huì)有些特定的需求才會(huì)有,不過也是特別重要的。
比如數(shù)據(jù)來源,我這里的顯示的東西調(diào)用的是那張表或者是哪個(gè)接口;
儲存方式,我這個(gè)規(guī)則是緩存在本地還是保存到服務(wù)器上;
異常情況,如果發(fā)現(xiàn)異?;蛘咤e(cuò)誤,這個(gè)邏輯該怎么走;
極值,如果在這里出現(xiàn)了999條記錄我該如何處理;
操作提示,用戶使用這個(gè)功能不知道是啥,我改怎么提示用戶或者是用戶做了什么操作,我該告訴用戶什么;
防呆規(guī)則,這里的輸入框是不是只能輸入數(shù)字或者輸入多少個(gè)數(shù)字;顯示內(nèi)容及其格式,某塊地方是顯示的什么東西,或者是可能顯示什么,顯示的是圖片還是視頻還是文字或者支持的是什么格式。
前后臺邏輯關(guān)系,前端操作會(huì)對后臺產(chǎn)生什么影響,后臺的設(shè)置會(huì)讓前端顯示什么;
前置條件和后置條件,發(fā)生這個(gè)用例的前提條件,或者滿足什么條件才能觸發(fā)這個(gè)用例,發(fā)生這個(gè)用例之后的結(jié)果,會(huì)產(chǎn)生什么影響等等。
當(dāng)然,你的產(chǎn)品規(guī)則可能遠(yuǎn)遠(yuǎn)不止以上那些,只要是你覺得有必要特別說明的東西,都可以算作你的產(chǎn)品邏輯,同樣的要求就是,一定要完整,明確并且清晰,不要留“坑”。
12.
那當(dāng)我寫完產(chǎn)品規(guī)則以后,我該如何自檢自己的PRD呢?我這里也總結(jié)了一些我的經(jīng)驗(yàn)用來自檢。主要分三個(gè)角度:1產(chǎn)品角度,2運(yùn)營角度,3,風(fēng)險(xiǎn)評估;
13.
從產(chǎn)品角度,我們需要注意以下的要素:
- 流程是否形成有效的閉環(huán)(什么叫閉環(huán),就是功能走著走著不能走不通了);
- 文案是否易懂,是否存在歧義(你的提示或者描述是否表達(dá)清晰,無文法錯(cuò)誤,你的slogan是否有情懷,吸引人);
- 版本兼容問題(如固件/第三方插件/第三方接口/APP各版本之前是否有沖突,功能之間或者交互之間做了好兼容);
- 與其他系統(tǒng)(后臺系統(tǒng)/服務(wù)器)的調(diào)用是否能相互兼容跑通(這里一般是牽涉多方平臺的處理方案);
- 新功能是否存在其他關(guān)聯(lián)功能點(diǎn)沖突(做一個(gè)新功能的時(shí)候一定要考慮到和其他有關(guān)聯(lián)功能的相互影響);
- 業(yè)務(wù)高峰的系統(tǒng)降級處理邏輯(如果你做的是以為重度業(yè)務(wù)APP,一定要考慮很多用戶同時(shí)涌入的風(fēng)險(xiǎn)以及處理方案,比如某米的商品搶購);
- 后續(xù)新功能或關(guān)聯(lián)產(chǎn)品如果下線的影響點(diǎn)(當(dāng)你要下架某個(gè)功能的時(shí)候,要考慮到下架以后的風(fēng)險(xiǎn)和對其他功能會(huì)產(chǎn)生什么影響,要寫功能下架預(yù)案);
14.
從運(yùn)營角度,我們需要注意以下的要素:
- 是否存在數(shù)據(jù)報(bào)表、埋點(diǎn)需求;
- 是否存在客服查詢需求;新功能的客戶宣傳策略;
- 是否存在運(yùn)營需求;數(shù)據(jù)指標(biāo)和預(yù)期驗(yàn)證;
- 運(yùn)營需求和產(chǎn)品功能是否相互影響;
15.
從風(fēng)險(xiǎn)評估角度,我們需要注意以下的要素:
- 是否會(huì)因?yàn)楣δ茉O(shè)計(jì)而導(dǎo)致平臺審核不通過(特別是蘋果);
- 是否引發(fā)諸如騷擾、欺詐等安全隱患;
- 是否存在用戶資料泄露,財(cái)產(chǎn),數(shù)據(jù)泄露安全隱患;
- 是否存在負(fù)面輿情風(fēng)險(xiǎn);
- 是否存在法律及合規(guī)風(fēng)險(xiǎn);
- 發(fā)布審核風(fēng)險(xiǎn);版本撤回及異常評估(回滾策略);
所以我們經(jīng)常會(huì)設(shè)計(jì)一些條例或者是用戶須知來防范這些風(fēng)險(xiǎn)。
如果時(shí)間充足,接下來我會(huì)將產(chǎn)品的實(shí)施階段和運(yùn)營階段產(chǎn)品需要做些什么。
嘖嘖嘖,半個(gè)小時(shí)的分享時(shí)間,寫了這么多還怕說不夠。最搞笑的是,他最后說了句大家有需要的可以隨時(shí)可以來找他。我跟他說考慮清楚要不要這么說,他說就客套一下啦,沒人會(huì)當(dāng)真的。于是第二天有人來找他,有人加他微信。
嚴(yán)肅點(diǎn)說,這次分享真的是干貨滿滿,只有非常認(rèn)真仔細(xì)的閱讀,理解和實(shí)踐,才能轉(zhuǎn)化成自己的能力。跟了師父快半年了,學(xué)了這么久的我仍在反復(fù)練習(xí),你是否也應(yīng)該放下所謂的“***天成為優(yōu)秀的產(chǎn)品經(jīng)理”,而是踏踏實(shí)實(shí)的練習(xí)呢。
這世界走的再快,也與你無關(guān),一步一步成長,也挺好。
作者:Jelly妮
來源:https://www.jianshu.com/p/e61f7eb59b94
本文由 @Jelly妮 授權(quán)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)作者許可,禁止轉(zhuǎn)載。
題圖來自unsplash,基于CC0協(xié)議
跪求一份完整PRD,cain_943@163.com,十分感謝
求一份完整的PRD,郵箱onnzyjmtd@163.com,非常感謝!
同求一份完整prd例子學(xué)習(xí),謝謝!764820454@qq.com
同求完整prd一份,郵箱reevs@sina.com,謝謝!
小姐姐,同求一份完整的,大而全的PRD例子學(xué)習(xí),619003285@qq.com 謝謝 ??
同求完整PRD文檔學(xué)習(xí),看完文章幫助好大,希望細(xì)致學(xué)習(xí)下,543599127@qq.com 非常感謝!
同求完整prd文檔 ? !產(chǎn)品小白表示沒寫過prd,希望能夠參考學(xué)習(xí)!1152771026@qq.com,非常非常非常感謝! ?
產(chǎn)品小白跪求完整文檔,617536134@qq.com 非常感謝
?? 求完整文檔學(xué)習(xí)4964116433@qq.com 想借鑒參考一下!謝謝
剛?cè)腴T沒多久,你的文章讓我受益無窮,求完整文檔學(xué)習(xí)498161386@qq.com 感激不盡
求大佬一份prd 想借鑒參考一下!謝謝1787866048@qq.com
很干很全面,文中提到了幾個(gè)比較重要的點(diǎn)剛好是我工作中遺漏的,求完整PRD學(xué)習(xí)一下 805124784@qq.com,感謝
產(chǎn)品小白跪求完整文檔,1138182073@qq.com 非常感謝
小姐姐,求一份prd例子學(xué)習(xí)一下 2392879027@qq.com
小姐姐大佬,求一份prd 想借鑒參考一下!謝謝936427806@qq.com
同求完整prd學(xué)習(xí)一下,1453665884@qq.com,謝謝
小姐姐,求一份PRD例子學(xué)習(xí)參考,總擔(dān)心自己的PRD缺少什么東西,1096257918@qq.com 謝謝~
賜一份PRD例子學(xué)習(xí),1164959028@qq.com,感謝~ ??
同求,1095001065@qq.com,感謝~
小姐姐,同求一份PRD例子學(xué)習(xí),jiangjiachang@distrii.com 謝謝 ??
同求一份完整的prd學(xué)習(xí)一下,親353786974@qq.com,萬分感謝呢
您好,請問可以發(fā)一份完整prd學(xué)習(xí)一下嗎?291344461@qq.com,謝謝!
我挺需要完整的文檔的,可否發(fā)送prd,大家一起學(xué)習(xí),共同探討1318029802@qq.com
產(chǎn)品小白跪求完整文檔,2545453527@qq.com 非常感謝
看了之后感覺我寫的需求文檔太過于簡單,麻煩小編改版一下師傅的需求文檔,去掉敏感描述和詞匯能否發(fā)給小弟一份?1419559889@qq.com 這是我的郵箱,非常感謝!
同求完整文檔,409714703@qq.com 非常非常感謝
您好,請好可以發(fā)一份完整prd學(xué)習(xí)一下嗎?389370314@qq.com,謝謝!
邏輯縝密,學(xué)習(xí)了,感謝!面對實(shí)際情況,短時(shí)間迭代很多功能,不夠時(shí)間對每個(gè)問題進(jìn)行全面思考,導(dǎo)致后期留了很多坑,遇到這種情況一般如何處理?
美女小姐姐,求完整prd學(xué)習(xí)一下,790697865@qq.com,謝謝
求完整prd學(xué)習(xí)一下,707160613@qq.com,謝謝
上述獲益良多,希望能收到小姐姐的干貨經(jīng)驗(yàn)分享學(xué)習(xí),萬分感謝。262330521@qq.com