PM要盡快擺脫對產品文檔的依賴才能走向成熟

19 評論 15682 瀏覽 129 收藏 7 分鐘

十年前,沒有人告訴他產品原型和文檔應該怎么寫;十年后,他想與你分享產品文檔的經驗心得。enjoy~

最近面試產品經理時最苦惱的就是大多數PM拿畫原型當自己的看家本領。絕大多數PM對于原型的使用都是錯誤的,直接導致無效的團隊推動力。造成這個現象的最根本原因是自己本身缺少目標感——不去深思產品成功后應有的模樣,而過于追求過程中的自我認可,尋求自嗨。

關于產品原型,你要記住兩點真相:

  1. 產品原型只是產品成功路上的墊腳石,就是要吸引大家來踩,踩過去了團隊才能往前走。
  2. 通過一份文檔來解決問題的想法是幼稚的,文檔最大的價值是信息沉淀以方便日后回顧。但更多時候是因為大多數人都不愿承擔責任,才抬升了它的重要性。

所以,你在設計和使用這塊“墊腳石”時,一定要首先注意:

  1. 當前團隊處于什么階段?目標是什么?接收對象是誰?
  2. 不要拿產品原型或文檔去說事兒,要開放,要就事兒論事兒!
  3. 千萬不要愛上自己的原型和文檔,你愛的是用戶,而且要讓團隊知道。

分享一下我作為產品新人時自己的一些技巧吧。

應該是十年前的樣子,我第一次加入到一個人數不多的互聯創業團隊中,沒有人告訴我產品原型和文檔應該怎么寫,在實際的推進中我產生了這幾方面的困惑:

  1. 不知道要寫多細。到現在都清晰記得我問身邊的技術大牛要不要標清字號時他甩來到白眼。
  2. 無法用一份原型來統一回答技術與設計伙伴的問題。比如Axure很適合做頁面邏輯的表達,但無法表達出數據以及接口結構?,F在很多原型工具也有這個問題,雖然能讓你低成本拿到demo,但無法對數據結構進行討論,影響PM對于成本以及未來可能性的把控。
  3. 總會有人產生疑問。會上定會下改,今天定明天改。

那是一個黑暗的時期,不僅工作量大還非常沒有效率——所有的改動都好像很急很重要,但并沒有對產品最終的效果起到明顯的推進作用。感覺自己就像一個整天到處救火隊的消防員,成天被點火的人愚弄。那時真的很討厭那些點火的人,可又不知道這些人是誰。是同事?老板?難道在可以刁難我?但我們私下還真的挺開心的。而且大家還給了我很多建議,最多的一句就是“再多想想”。

當時我有一個習慣,就是回復完所有當天郵箱里的產品反饋再下班。記得有天晚上,公司剩我一個人,很疲憊地看著反饋列表時,發現了一條夸我們產品好用的評價。我不知道那條評價被我反復看了多少遍,一個原因是確實激動,另一個原因是用戶并沒有寫出到底是哪個功能做的好,他只說目前只有我們能夠幫助他隨時找到身邊的商家。我突然明白了眼下最重要的事情是什么——回復郵件表示感謝之后,繼續問他還有什么不方便之處。

那晚上,我的腦海里出現了一幅圖:左邊是一個用戶,右邊是他想要的蘋果,中間是一個迷宮。我要最快地帶他走出迷宮,拿到他渴望的那個蘋果。

我突然發現之前我的做法都是錯的。我把團隊伙伴和老板當成了我的服務目標——他們本應是站在我身邊一同為用戶服務的人。我們如何才能一起行動呢?其實很簡單,我們要一起面對用戶的問題。換句話說,我們面對的問題必須是來自用戶的。

后來我主動找公司進行如下改動——

  • 搭建redmine, 建立用戶問題庫(現在的工具很多,推薦confluence)
  • 僅針對問題進行討論。如果建議來自同事或老板,我也當做用戶一樣對待
  • 針對每個問題進行原型提案,大家直接拋磚,甚至工程師也可以一起提原型
  • 最終由我來主持會議確定優先級,并按順序打包成版本計劃——路線圖出來了

這個帶來的直接效果是,團隊與我站在同一戰壕,都對如何更高效地解決問題產生興趣。除此之外還有幾個非常棒的效果:

  1. 我不用再寫繁冗的產品文檔,僅根據問題進行提案,組織討論。
  2. 我開始使用手繪來表達原型,因為足夠了,更多的細節設計師會跟進?;蛘咚闹饕飧?。
  3. 團隊非常清楚眼下的重點,知道要做什么,大家關系更加融洽了。

我終于品嘗到了作為一名產品經理的成就和愉悅感。

在多年之后,我才從《每個偉大的產品背后》這篇文章中再次確認產品經理無授權管理的深意:

  1. 不要追求成為團隊最厲害的人,要做最會發現問題的人。
  2. 不要在意文檔的質量,要關注團隊使用文檔的動機。
  3. 產品經理是管理崗,要讓團隊中的專業成員得到參與感,并發揮長處。

確實,完美的文檔并不存在!從此之后,我永遠只是最快拋磚的人。拋得越快,團隊跑得越快!

產品經理要盡快擺脫對產品文檔的依賴才能走向成熟,越快越好:)

 

作者:王玨,WETOUCH互聯咨詢Founder,十一年互聯老牛,前聯想、騰訊資深PM

本文由 @王玨 原創發布于人人都是產品經理。未經許可,禁止轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 其實我是來尋求一份固定的產品文檔要領,當然我感覺你說的都是有一定基礎功以后的蛻變,在沒有任何概念的情況下我無法進行進一步蛻化,從而加入自己的想法和自己的觀察,這一切的一切都是來源于基本功,其實我還是對你剛成為產品那段路感興趣因為我現在急需的是這段經驗。

    來自浙江 回復
  2. 產品需求不止來自于用戶啊,還有來自于老板、競品、運營或者戰略需求等等,比如微信的紅包功能,這個就明顯不來自于用戶問題。所以用戶問題庫也只是需求管理里的一部分,不能以偏概全

    來自廣東 回復
    1. 你把“用戶”這兩個字搞窄了。

      來自北京 回復
    2. 任何人都能是“用戶”吧,只是分了不同的群體。

      來自湖北 回復
  3. 我們現在就是使用worktile使用管理需求(點)和問題的,可能和作者說的效果接近,但是目前需求質量、歷史追溯上覺得有點問題。作者大大在執行的過程中,最新的、完整的一份文檔或者原型還是有的嗎?

    來自江蘇 回復
    1. 需求質量和追溯效果來自于兩個方面:1. 對于問題本質的深挖;2.量化指標的對應設計。我們會花更多的時間把這兩件事搞清楚。在這個過程中鼓勵并允許設計師和工程師同事直接給出方案,并在Dev測試環境下進行體驗和近一步討論。偶爾會用原型進行輔助,但談不上完整,很多都是手稿。

      來自北京 回復
  4. 好奇想問問,何謂冗雜的產品文檔呢?目前在一家較大的公司實習,部門的產品線已經比較完善了,我經手的文檔都是拆分成一個個需求來進行撰寫然后開會討論的。如樓主說的冗雜或說詳細的產品文檔格式只在一些前幾年的網課上有聽到過。所以是不是說目前行業內較完善的產品基本已經不會出現冗雜的產品文檔了?

    來自廣東 回復
    1. 這個不一定。PM應該去考慮如何讓團隊之間的協作更加高效,能夠快些更快些。推薦一本書《Rework》

      來自北京 回復
  5. 最后一句很棒——沒有問題就沒有目標!

    來自北京 回復
  6. 不能為了寫文檔而寫文檔,雖說是信息沉淀的產物,但真的無法做到完美解決問題的目的;就算寫完文檔畫完原型,每次溝通之后還是會改改改,效率真的很低。很受益,沒有問題就沒有目標~~

    來自陜西 回復
  7. 確實,產品經理應該要很好的理解自己的崗位,

    回復
    1. 是的,理解自己在團隊中的貢獻。

      來自北京 回復
  8. 真實剛需啊,最近跟開發溝通產品改版的需求方案,每次溝通下來都被反饋“再多想想”,之前已確認的方案會后也會被反饋說“再想想,或者會被建議怎樣是不是更好”,真的是不知道怎么去做產品的需求方案比較好,感謝您的分享,會按照這個思路去嘗試改變:)

    來自上海 回復
    1. 加油

      來自北京 回復
  9. 值得思考的話題

    來自廣東 回復
  10. 我遇到的問題是,要么評審的時候沒人提建議,要么抬杠,計較半天毫無用處的細節??,這突如其來的心塞是怎么一回事?

    回復
    1. 從來不會有完美的方案,你需要把目標問題單獨拿出來和團隊分享和討論。方案可以輔助你把問題談得更清楚一些,并獲得更多意見。

      來自北京 回復
  11. 原型是和技術、運營介紹你想法的demo,文檔是作為記錄為后來人了解產品迭代軌跡的

    回復
    1. 它們都是用來定位和追溯用戶問題的。沒有問題就沒有目標,單純的迭代軌跡沒有任何意義。

      來自北京 回復