PM要盡快擺脫對產(chǎn)品文檔的依賴才能走向成熟
![](http://image.woshipm.com/wp-files/img/77.jpg)
十年前,沒有人告訴他產(chǎn)品原型和文檔應(yīng)該怎么寫;十年后,他想與你分享產(chǎn)品文檔的經(jīng)驗心得。enjoy~
最近面試產(chǎn)品經(jīng)理時最苦惱的就是大多數(shù)PM拿畫原型當自己的看家本領(lǐng)。絕大多數(shù)PM對于原型的使用都是錯誤的,直接導(dǎo)致無效的團隊推動力。造成這個現(xiàn)象的最根本原因是自己本身缺少目標感——不去深思產(chǎn)品成功后應(yīng)有的模樣,而過于追求過程中的自我認可,尋求自嗨。
關(guān)于產(chǎn)品原型,你要記住兩點真相:
- 產(chǎn)品原型只是產(chǎn)品成功路上的墊腳石,就是要吸引大家來踩,踩過去了團隊才能往前走。
- 通過一份文檔來解決問題的想法是幼稚的,文檔最大的價值是信息沉淀以方便日后回顧。但更多時候是因為大多數(shù)人都不愿承擔責任,才抬升了它的重要性。
所以,你在設(shè)計和使用這塊“墊腳石”時,一定要首先注意:
- 當前團隊處于什么階段?目標是什么?接收對象是誰?
- 不要拿產(chǎn)品原型或文檔去說事兒,要開放,要就事兒論事兒!
- 千萬不要愛上自己的原型和文檔,你愛的是用戶,而且要讓團隊知道。
分享一下我作為產(chǎn)品新人時自己的一些技巧吧。
應(yīng)該是十年前的樣子,我第一次加入到一個人數(shù)不多的互聯(lián)創(chuàng)業(yè)團隊中,沒有人告訴我產(chǎn)品原型和文檔應(yīng)該怎么寫,在實際的推進中我產(chǎn)生了這幾方面的困惑:
- 不知道要寫多細。到現(xiàn)在都清晰記得我問身邊的技術(shù)大牛要不要標清字號時他甩來到白眼。
- 無法用一份原型來統(tǒng)一回答技術(shù)與設(shè)計伙伴的問題。比如Axure很適合做頁面邏輯的表達,但無法表達出數(shù)據(jù)以及接口結(jié)構(gòu)。現(xiàn)在很多原型工具也有這個問題,雖然能讓你低成本拿到demo,但無法對數(shù)據(jù)結(jié)構(gòu)進行討論,影響PM對于成本以及未來可能性的把控。
- 總會有人產(chǎn)生疑問。會上定會下改,今天定明天改。
那是一個黑暗的時期,不僅工作量大還非常沒有效率——所有的改動都好像很急很重要,但并沒有對產(chǎn)品最終的效果起到明顯的推進作用。感覺自己就像一個整天到處救火隊的消防員,成天被點火的人愚弄。那時真的很討厭那些點火的人,可又不知道這些人是誰。是同事?老板?難道在可以刁難我?但我們私下還真的挺開心的。而且大家還給了我很多建議,最多的一句就是“再多想想”。
當時我有一個習(xí)慣,就是回復(fù)完所有當天郵箱里的產(chǎn)品反饋再下班。記得有天晚上,公司剩我一個人,很疲憊地看著反饋列表時,發(fā)現(xiàn)了一條夸我們產(chǎn)品好用的評價。我不知道那條評價被我反復(fù)看了多少遍,一個原因是確實激動,另一個原因是用戶并沒有寫出到底是哪個功能做的好,他只說目前只有我們能夠幫助他隨時找到身邊的商家。我突然明白了眼下最重要的事情是什么——回復(fù)郵件表示感謝之后,繼續(xù)問他還有什么不方便之處。
那晚上,我的腦海里出現(xiàn)了一幅圖:左邊是一個用戶,右邊是他想要的蘋果,中間是一個迷宮。我要最快地帶他走出迷宮,拿到他渴望的那個蘋果。
我突然發(fā)現(xiàn)之前我的做法都是錯的。我把團隊伙伴和老板當成了我的服務(wù)目標——他們本應(yīng)是站在我身邊一同為用戶服務(wù)的人。我們?nèi)绾尾拍芤黄鹦袆幽??其實很簡單,我們要一起面對用戶的問題。換句話說,我們面對的問題必須是來自用戶的。
后來我主動找公司進行如下改動——
- 搭建redmine, 建立用戶問題庫(現(xiàn)在的工具很多,推薦confluence)
- 僅針對問題進行討論。如果建議來自同事或老板,我也當做用戶一樣對待
- 針對每個問題進行原型提案,大家直接拋磚,甚至工程師也可以一起提原型
- 最終由我來主持會議確定優(yōu)先級,并按順序打包成版本計劃——路線圖出來了
這個帶來的直接效果是,團隊與我站在同一戰(zhàn)壕,都對如何更高效地解決問題產(chǎn)生興趣。除此之外還有幾個非常棒的效果:
- 我不用再寫繁冗的產(chǎn)品文檔,僅根據(jù)問題進行提案,組織討論。
- 我開始使用手繪來表達原型,因為足夠了,更多的細節(jié)設(shè)計師會跟進?;蛘咚闹饕飧?。
- 團隊非常清楚眼下的重點,知道要做什么,大家關(guān)系更加融洽了。
我終于品嘗到了作為一名產(chǎn)品經(jīng)理的成就和愉悅感。
在多年之后,我才從《每個偉大的產(chǎn)品背后》這篇文章中再次確認產(chǎn)品經(jīng)理無授權(quán)管理的深意:
- 不要追求成為團隊最厲害的人,要做最會發(fā)現(xiàn)問題的人。
- 不要在意文檔的質(zhì)量,要關(guān)注團隊使用文檔的動機。
- 產(chǎn)品經(jīng)理是管理崗,要讓團隊中的專業(yè)成員得到參與感,并發(fā)揮長處。
確實,完美的文檔并不存在!從此之后,我永遠只是最快拋磚的人。拋得越快,團隊跑得越快!
產(chǎn)品經(jīng)理要盡快擺脫對產(chǎn)品文檔的依賴才能走向成熟,越快越好:)
作者:王玨,WETOUCH互聯(lián)咨詢Founder,十一年互聯(lián)老牛,前聯(lián)想、騰訊資深PM
本文由 @王玨 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
其實我是來尋求一份固定的產(chǎn)品文檔要領(lǐng),當然我感覺你說的都是有一定基礎(chǔ)功以后的蛻變,在沒有任何概念的情況下我無法進行進一步蛻化,從而加入自己的想法和自己的觀察,這一切的一切都是來源于基本功,其實我還是對你剛成為產(chǎn)品那段路感興趣因為我現(xiàn)在急需的是這段經(jīng)驗。
產(chǎn)品需求不止來自于用戶啊,還有來自于老板、競品、運營或者戰(zhàn)略需求等等,比如微信的紅包功能,這個就明顯不來自于用戶問題。所以用戶問題庫也只是需求管理里的一部分,不能以偏概全
你把“用戶”這兩個字搞窄了。
任何人都能是“用戶”吧,只是分了不同的群體。
我們現(xiàn)在就是使用worktile使用管理需求(點)和問題的,可能和作者說的效果接近,但是目前需求質(zhì)量、歷史追溯上覺得有點問題。作者大大在執(zhí)行的過程中,最新的、完整的一份文檔或者原型還是有的嗎?
需求質(zhì)量和追溯效果來自于兩個方面:1. 對于問題本質(zhì)的深挖;2.量化指標的對應(yīng)設(shè)計。我們會花更多的時間把這兩件事搞清楚。在這個過程中鼓勵并允許設(shè)計師和工程師同事直接給出方案,并在Dev測試環(huán)境下進行體驗和近一步討論。偶爾會用原型進行輔助,但談不上完整,很多都是手稿。
好奇想問問,何謂冗雜的產(chǎn)品文檔呢?目前在一家較大的公司實習(xí),部門的產(chǎn)品線已經(jīng)比較完善了,我經(jīng)手的文檔都是拆分成一個個需求來進行撰寫然后開會討論的。如樓主說的冗雜或說詳細的產(chǎn)品文檔格式只在一些前幾年的網(wǎng)課上有聽到過。所以是不是說目前行業(yè)內(nèi)較完善的產(chǎn)品基本已經(jīng)不會出現(xiàn)冗雜的產(chǎn)品文檔了?
這個不一定。PM應(yīng)該去考慮如何讓團隊之間的協(xié)作更加高效,能夠快些更快些。推薦一本書《Rework》
最后一句很棒——沒有問題就沒有目標!
不能為了寫文檔而寫文檔,雖說是信息沉淀的產(chǎn)物,但真的無法做到完美解決問題的目的;就算寫完文檔畫完原型,每次溝通之后還是會改改改,效率真的很低。很受益,沒有問題就沒有目標~~
確實,產(chǎn)品經(jīng)理應(yīng)該要很好的理解自己的崗位,
是的,理解自己在團隊中的貢獻。
真實剛需啊,最近跟開發(fā)溝通產(chǎn)品改版的需求方案,每次溝通下來都被反饋“再多想想”,之前已確認的方案會后也會被反饋說“再想想,或者會被建議怎樣是不是更好”,真的是不知道怎么去做產(chǎn)品的需求方案比較好,感謝您的分享,會按照這個思路去嘗試改變:)
加油
值得思考的話題
我遇到的問題是,要么評審的時候沒人提建議,要么抬杠,計較半天毫無用處的細節(jié)??,這突如其來的心塞是怎么一回事?
從來不會有完美的方案,你需要把目標問題單獨拿出來和團隊分享和討論。方案可以輔助你把問題談得更清楚一些,并獲得更多意見。
原型是和技術(shù)、運營介紹你想法的demo,文檔是作為記錄為后來人了解產(chǎn)品迭代軌跡的
它們都是用來定位和追溯用戶問題的。沒有問題就沒有目標,單純的迭代軌跡沒有任何意義。