從 Netflix 傳奇看，結果導向的產品路線圖如何制定？

寫在前面： 本文譯自 Jason Doherty、Kelsey Stevenson 和 Thomas Vela 於「2019 年丹佛創業周」發表的題為「 Outcome Based Roadmaps 」的演講實錄；原文作者為 Jason Doherty。

01 避免成為「功能工廠」

許多軟體研發團隊在交付使用者價值時總覺得十分困難——這通常是因為產研團隊沒有與使用者保持持續溝通，或者團隊沒有評估功能交付後是否如期發揮了作用。 團隊陷入「功能工廠」困境，一味地開發和上線新功能，並期盼有人會使用它們。

使用者是否喜歡剛上線的新功能？它們還有哪些可優化或待改進的空間？使用者是否從功能中獲得了真正的價值？如果產研團隊不評估這些，也不與使用者交流，那就幾乎無法構建任何產品影響力。

要知道，「上線功能」不意味著「產品成功」；取得成功的關鍵在於，要以可量化的方式，為使用者帶去積極的行為改變。

02 路線圖 VS 發版計劃

眾所周知，發版計劃（Release Plan）是關於功能和日期的列表。

而路線圖（Roadmap）是一份旨在傳達公司戰略方向的檔案，它闡明瞭「目標是什麼？」「預期結果是什麼？」以及「產品將如何贏得市場？」

Netflix 的創業故事被大家奉為經典，我們來看看 2007 年（左右）的 Netflix 路線圖。

事實上，很多公司可能只有發版計劃。他們總是試圖提前幾個月，預測多個功能在規模和時間上的發展和可能的影響。

企業高管們很喜歡這種 「可控的確定性」，哪怕研發團隊很少按路線圖計劃的那般交付，功能也很少能達到預期。寫滿功能和日期的列表被貼上「路線圖」的標籤，但你我都知道，這不過是彌天大謊。

大多數情況下，這類公司不評估戰略目標的實現情況（儘管它們曾被正式地記錄下來），也不考量某個功能是否對使用者總量或 ARR 等業績跟蹤指標產生了直接影響。他們只是盲目地在發版當天，上線功能，然後期待會有效果。

03 關注產出，衡量結果

開發團隊、產品負責人、UX 專家和運維人員等資源（Resource）通力合作，在軟體開發這項活動（Activity）中，創造並交付市場和使用者期待的功能（即產出，Output）。大多數團隊做到這一步，便會高呼「成功」。

而今天，優秀的產研團隊更加在意：剛交付的功能是否取得了預期的結果（Outcome）。

An Outcome is a measurable change in customer behavior.

結果是可量化的客戶行為的變化。

所有向用戶交付的功能都應該為使用者行為帶來可量化的、積極的改變。通常情況下，我們不認為釋出一個毫無效用的功能，能夠代表成功。

功能無法實現預期效果的原因有很多，例如：

• 最初的方向可能有問題。
• 首發版本需要迭代優化，才能達到預期。
• 功能沒有解決使用者的問題，不能給使用者帶來好處，或者不能完成使用者想實現的需求。

04 在迭代中評估結果，才能取得成功

想了解一個功能是否真的奏效，就必須：

• 知道每個功能真正奏效是什麼樣？
• 瞭解如何判斷和評估功能的效用？
• 並在每次釋出後評估每個功能的結果。

結果（即使用者行為的變化）是產品功能所產生的影響。它應該是可測量的、與公司目標保持一致的，並以使用者為中心的。

想要實現產品願景並在市場上產生影響，就必須知道目標（Goal）是什麼。而作為組織顧問和產品負責人，我發現大多數團隊在工作時，沒有明確的產品願景或目標。

05 產品策略從產品願景和目標開始

產品策略與計劃不同，它是一個決策框架。產研團隊依據框架指導做出決策，以實現產品願景。

第 1 步：確定一個清晰且令人信服的產品願景。 明確產品存在的意義，以及 5 年後產品的形態。產品願景是不受時間影響、能持續為研發團隊提供北極星般引路之光的存在。

產品願景示例： 成為歐美地區酒店維護行業的第一大移動人力管理軟體。

第 2 步：設立 2 - 3 個公司未來 1 - 2 年（內）要實現的目標。 目標是具體的、可衡量的、與產品願景相關的；如果目標全部達成，就能實現一部分的產品願景。

目標要足夠具體，例如：

到 2021 年 7 月 30 日，要讓歐洲目標市場上 4% 的酒店維修人員每天使用。

第 3 步：考慮要改變哪些使用者行為（即結果）以實現目標。 它可能是註冊率、轉化率、使用者滿意度、建立的專案數量等等。

同時，結果的設定應遵循 SMART 原則，即具體的（Specific）、可衡量的（Measurable）、可實現的（Achievable）、切合實際的（Realistic）和有時限性的（Time-bound）。

結果示例一： 到 2019 年 12 月 31 日，使用者在下載應用後 5 分鐘內能以其母語建立工作訂單。

結果示例二： 至少 80% 的使用者每週至少管理 5 個工單（現在他們每週管理 2 個工單）。

設立結果時，建議像示例二一樣，說明資料指標的起止變化範圍，即採用形如「使用者行為 <A> 在時間範圍 <T> 內，從 <x> 變為 <y>」的格式。 這要求團隊能夠量化當前的產品狀態，指標量化同樣也是結果導向型管理的重要組成部分。

如果使用 OKR 工具管理工作，那麼 Objectives 就是產品目標，Key Results 為結果。

第 4 步：確定改變使用者行為的機會點。 它可以是使用者痛點/問題、能從產品獲得的好處，以及想要完成的需求（Jobs To Be Done）。如果能抓住機會，提供良好的解決方案，就能達成預期的結果。

Marty Cagan 通過觀察指出，團隊需要對使用者、資料和市場有深入的瞭解，才能解決使用者的問題，並創造出有價值的、可用的、可行的和有長久生命力的產品。

SUMMARY | 未完待續

緊跟上述四個步驟，我們便擁有了

• 一個清晰且令人信服的產品願景；
• 一組可以幫助實現願景的目標；
• 一些圍繞使用者展開的可量化的結果；
• 一系列可能產生使用者價值的機會，比如使用者痛點、獲利或者待完成的需求等。

制定產品策略是一個不斷務實、逐漸具象的過程。產品研發不能脫離業務目標而存在，那麼技術團隊如何在產研實踐中，交付正確的使用者價值？

結果導向的產品路線圖應該如何落實？又會以怎樣的形態，與發版計劃結合在一起？

下篇文章，LigaAI 繼續揭祕。

---

瞭解更多敏捷開發、專案管理、行業動態等訊息，關注我們 LigaAI@oschina 。

歡迎點選 LigaAI - 新一代智慧研發協作平臺，線上申請體驗我們的產品，開啟智慧提效！