十年前，沒有人告訴他產品原型和文檔應該怎么寫；十年后，他想與你分享產品文檔的經驗心得。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

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