谷歌和亞馬遜如何作產品歸總(二)

贏在產品定義

撰寫新聞稿

新聞稿是指一篇向市場宣佈將要推出新產品的預告，簡單明瞭地傳達關於產品的關鍵信息。它天生就更簡潔，可讀性更強且更關注真實的產品能給真實的用戶帶來什麼價值

好的新聞稿包含如下六大要素:

• 產品命名
• 發佈時間
• 目標客戶
• 解決了什麼問題
• 如何解決(務必簡明扼要)
• CEO的公開讚辭

建立並不斷更新FAQ文檔

建立並維護FAQ文檔有兩大好處。

1. 它能節約你大量回復郵件回覆消息的時間，在產品研發過程的諸多關鍵時候它也能節約時間，還能抵禦一些內部責難。
2. 當你的客戶支持團隊和科技寫做團隊開始整理全部面向公衆的內容時，FAQ將是一個頗有價值的資源。

繪製線框圖和流程圖

流程圖能夠幫助你準確地解釋工做流和系統交互相關問題，簡要線框圖則能夠幫助你具象化產品各環節的用戶體驗，並在以後的彙報中發揮難以想象的做用

撰寫產品單頁和製做10分鐘的演示文稿

這兩份文檔所需包含的五個要素:

1. 產品名稱
2. 目標客戶 + 數量有多少
3. 解決了什麼問題 + 這個問題對於目標客戶來講有多大價值
4. 解決方案 + 這個解決方案相似線上那個產品，爲何你的方案能讓競爭對手在長時間內都沒法模仿
5. 什麼時候交付 + 主要的里程碑有那些？
6. 團隊背景(僅針對VC 風險投資人)

增長API文檔

API文檔能夠說明你的團隊如何與其餘團隊協做，外部開發者如何使用這套系統以及你須要存儲什麼數據。預先定義清楚API還有個好處，它能夠幫助你搭建由這些API構成的面向服務體系結構

撰寫功能和規格文檔

1. 簡介
   它說明了爲何要作這個產品以及作些什麼，每一個新進入項目的成員均可以從中瞭解到必要的背景信息。同時它還說明了文檔中一些術語的含義，你可能由於使用習慣了這些術語而忘記了別人其實並不理解
2. 目標與非目標
   簡介中雖已大體描述了產品的方向，但你須要將其細化成不一樣目標，每一個目標都應保持清晰簡介並將它們按優先級排列，這樣工程團隊就能夠合理地進行設計與開發。
   
   若是設定的某個目標表面上與產品沒有多大關聯，你須要解釋清楚爲何將它設爲目標，不然工程師會認爲這些目標以及後面的功能需求都是你拍拍腦殼定下來的。他們不喜歡這種隨意的需求，就像他們不喜歡隨意定下的交付日期同樣。你要慎重對待這件事情。
   
   若是說目標是別人你要作什麼，那麼非目標則是告訴你不要作什麼。因此設定非目標很是有用。那些持不一樣意見的人能經過非目標來理解你爲何會這樣規劃產品。
3. 用例或用戶場景
   用例是指用簡要的語句來描述那些用戶必須執行的操做，用戶場景則是指用敘述故事的方式來描述用戶是如何提要產品的。用例描述很是精細，你不加思考便能讀懂，工程師也能根據用例準確地判斷該作那些工做。所以用例在敏捷開發中發揮着巨大做用，每一個核心任務都會描述成一個用例。
4. 原型圖或線框圖
   因爲正在遵循一個行之有效的產品定義過程，所以你已經繪製了一些粗糙的原型圖或者線框圖，將這些圖粘貼到功能說明中，它們是用戶場景的重要補充。
5. API
   如何尚未API文檔，那就如今寫
6. 負載規劃
   負載規劃是指對將來一段時間用戶的使用量進行粗略估計並制訂應對計劃，這對工程團隊來講很是重要。他們會根據你預估的使用量來肯定哪些地方須要添加緩存，那種類型的服務器和存儲須要準備，哪些受權問題可能產生，等等。
   關於負載規劃你要作的就是進行合理的預估，你的工程主管負責根據預估值來構建一個穩定運行的系統。不要花太長時間在預估上面，只須要花幾個小時寫個初稿，再找幾個團隊成員討論一下並將討論出來的數值翻倍就大功告成了。
7. 依賴
   你須要將所有依賴方及其負責人列出來，若是有應急方案也一併列出來。功能規格定稿後你也應該發給各依賴方的負責人，讓他們知道你須要他們的支持。他們可能只會閱讀你的簡介部分，不過這就夠了，由於這部分已經清楚闡釋了你要作些什麼。
8. FAQ和開放問題
   你能夠直接將FQA和開放問題的連接地址放入功能文檔中，也能夠把內容複製過來，不過建議最好保持FQA的獨立性，這樣就不須要維護多個版本的FAQ了。
9. 關鍵事件
   你可能有一些硬性時間要求，這些時間都須要放入文檔。你最好能列出主要事件的達成時間，如特性完成時間，可信測試者版發佈時間，若是具體的工程量還沒有評估出來，那預計的時間應該保守一些。

找出邊界狀況並獲得團隊承認

你的團隊將開始尋找邊界狀況或者極端狀況，即極少出現的產品行爲或場景。若是不找出全部邊界和極端狀況，你就沒法採起應對措施，它們就早晚給你帶來傷害，現實世界中尤其如此。

客戶測試