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

語言: CN / TW / HK

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

01 避免成為「功能工廠」

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

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

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

02 路線圖 VS 發版計劃

眾所周知,發版計劃(Release Plan)是關於功能和日期的列表。

而路線圖(Roadmap)是一份旨在傳達公司戰略方向的文件,它闡明瞭「目標是什麼?」「預期結果是什麼?」以及「產品將如何贏得市場?」

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

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 - 新一代智能研發協作平台,在線申請體驗我們的產品,開啟智能提效!