Product Spec:中、大型公司的PM溝通瓶頸
不要害怕查漏補缺,直到我們成為最好的自己,這會一直持續發生;完美需要時間。
首先我們來定義一下“中、大型互聯網公司”:一般200人以上,各部門配置健全,融資處于B輪或以上。
如果你正在這種公司擔任PM,那么恭喜你,你可能遇見過以下問題:
- 協同辦公平臺上顯示你們的開發人員將某項網頁開發任務標注為“已完成”,這比你的預期提早了不少。但當你測試該功能時發現,手機上適配不了?。悴畔氲侥阃洀娬{移動端需要適配)
- 客服部門發現了一條看不懂的用戶反饋,并找到你,希望調取該用戶的信息(你才想起那是你們沒有刪除的測試數據)
- 設計部門為你做了一個精美的幻燈片,用于會議展示(你意識到你忘記告訴他們你需要的只是一個功能驗證測試,只要前端能看懂就行)
- 經過1周的測試,BI部門終于發現他們沒法完成你需要的數據分析報告,因為他們沒有采集正確的數據指標(史詩般的失敗,重來吧)
……
如果給我1小時來解決一個問題,我會用55分鐘思考問題,然后用5分鐘來思考解決方案。
——愛因斯坦
對于百萬級用戶的產品來說,產品質量、進度風險、開發周期等等都是由無數個細節決定的。這對于大型甚至中型公司來說,就是對團隊的溝通提出了更高的要求:
- 強迫批判性思考,確保溝通細節沒有紕漏
- 多部門的協同與溝通,對時間周期有全局觀念
- 提高問責性,哪個部門、什么工作、做到什么程度、具體負責人是誰……
其實所有這些需要的就是一份Product?Spec.(產品規范)
一、什么是產品規范?為什么要寫產品規范?
產品規范(Product?Spec.)可以看成是一張藍圖,用來描述你們正在設計什么產品,為誰設計,以及各個環節交付和結果應該是什么。
很多人在聽到“規范”這兩個字的時候都會忍不住抱怨,因為他們覺得這東西根本沒有人會讀,卻要浪費好幾個星期來寫。
其實不是這樣的。
- 一個好的產品規范是清晰明確的,它為用戶、業務需求和其他標準提供相關敘述,幫助產品經理在設計和構建解決方案時做出明智的決策。
- 撰寫產品規范根本不是白費功夫,恰恰相反,它能大大幫你節省很多不必要浪費的時間。
- 有效的產品規范是搭建出優秀互聯網產品中至關重要的一部分。它會帶領你的團隊開啟批判性思維,量化所有溝通,并提升你們的可信賴度,由此獲得更高的產品質量、更低的規劃風險和更少的時間浪費。
合格的產品規范應當回答以下問題:
- 我們在開發什么?以及為什么開發?
- 最終的產品是什么樣?
- 成功的標準是什么?
下面我們將為你介紹來自Janna Bastow的5步法完成product Spec.
二、設計過程中如何完善產品規范?
注意,這不是從0開始的教程,而是提供核心思路,以“如何提升溝通力”為出發點的5步。
第一步:從用戶反饋和數據中尋找問題
尋找問題的最佳去處便是——用戶反饋。
用戶反饋有很多種形式:抱怨、提問、產品建議和功能要求。面對各種各樣的用戶反饋,最重要的是不要只看字面意思。
用戶提出的不是一條指令,反饋中的每一件事項都是一個能幫助你深入問題根本的數據點。
一些有助于尋找問題的問題:
- 所有這些反饋的背后是什么?其中隱含的問題是什么?
- 有很多用戶提出這個要求嗎?用戶需求有多大?
- 這個問題有多重要?是否會讓你很難獲得未來的更多用戶?
- 它會否阻礙你獲得更多用戶或訂單?
第二步:把問題拆解成一系列假設
這是強迫你批判性思考的好方法:
用戶反饋的問題到底有多大?在這一步,你將繼續認識你面對的問題范疇。
受到用戶反饋的啟發,你可能會開始徹底地把檢驗流程過一遍,之后你肯定會產生很多各種各樣的想法。但是這些想法不一定都有意義,你可以通過以下三種劃分方式來給它們歸歸類:
- 必不可少的:這是類似MVP的東西。如果沒有它,什么都白搭。
- 值得擁有的:不是必要的,但是可以為用戶帶來所見即所得的價值。
- 讓人高興的:撒在雪頂咖啡最上面的巧克力屑,能讓人會心一笑的小東西。
通過這樣的方式,你依然可以站在完整的視角看待問題,只不過,必不可少的東西才是你的最高優先級,其他所有都要等它完成了再說。
第三步:在你的團隊開展產品討論
“撰寫產品規范是干掉所有惱人的大大小小設計抉擇的最好辦法,即使是最微小的分歧也可以被一份產品規范解決?!盕rog Creek Software的Joel Spolsky如是說。
道理人人都懂。但是,那些微小的決定會累積,而當它已經穩坐在你的積壓待辦當中的時候,就沒有人愿意來挑頭解決掉它了。
屢見不鮮的一個錯誤就是當產品規范已經在制作中了卻還把討論都拖到最后。你必須創造出一個空間,以便你的團隊可以在想法成型的時期就開展討論。
現在就開始邀請你周圍的同事,讓他們幫你把想法潤色好。一個高效產品團隊的關鍵特點是能夠打開話題,圍繞什么需要完成以及怎樣完成進行產品討論。
第四步:和你最親近的顧客做用戶測試
目前為止,你做的所有事在紙上看起來都挺像回事的,但實際怎樣就不得而知了。現在就是檢驗你的假設是否成立、你的用戶是否會按照你想像的方式做出反應的時刻了。
用戶能完成你給出的任務嗎?他們能輕松找到那些按鈕嗎?他們清楚自己看到的都是什么嗎?
之后你通常會發現有些假設是錯誤的,按鈕沒有那么好找,或者操作流程沒有你想的那么直觀。
不過你也可能發現一些驚喜:
- 極端案例
- 意外要求
- 被誤讀的功能
- 被拓寬或改變的視角
第五步:如果一切就緒,發送給開發
即便開發過程中一切都進行得完美無缺,到了質檢環節就又是另一回事了。一旦你開始到處隨便點擊,你很可能就會發現一些被遺漏掉的細小問題。
不要害怕查漏補缺。直到我們成為最好的自己,這會一直持續發生。完美需要時間。
當你自信地認為你實現了想要的效果,再加上最后一筆:最終原型、技術信息、關鍵情景等等。
搞定!
作者:七日輯(微信公眾號:七日輯),在線項目式學習課程平臺,幫助你七天完成一個小目標
本文由 @七日輯 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自 Unsplash ,基于 CC0 協議
我比較關心最前面的4個問題怎么解決????