對講機的產品原則:我們如何專注於交付成果
已發表: 2022-05-06在 Intercom,運輸只是開始。
我們迭代,爭取採用,並不斷推動對我們的客戶和我們的業務產生最大的影響。 我們努力提供成果和產出,為我們的客戶帶來真正的成果。
在我們的 Intercom on Product 播客的一集中,我們的聯合創始人 Des 以這種方式總結了產出與結果的關係:“這是您交付的內容與因您交付的內容而發生的事情。” 我們努力確保由於我們運送的東西而發生的事情為我們的客戶帶來有形的價值。
“在忽視業務成果的同時推動出色的客戶成果並不能使公司成功”
但歸根結底,在忽視業務成果的情況下推動出色的客戶成果並不能成就一家成功的公司。 我們努力平衡兩者,為我們的客戶和我們的業務提供高影響力的成果。 我們是這樣做的:
我們制定了我們旨在預先推動的結果
我們從一開始就考慮我們要爭取什麼樣的客戶和業務成果,特別是在整理我們的問題陳述時。 在整個過程中,我們會問自己:“成功解決問題會導致客戶行為發生哪些可衡量的變化?”,並且通常將這種行為衡量為產品活動或使用情況。
我們使用特定的研發成果指標模板來幫助我們思考和闡明我們的目標。 在其中,我們將我們希望看到的客戶利益與我們擁有的任何指標、目標和支持理由相結合。 我們對我們想要推動的商業利益做同樣的事情。
“我們發布了一項功能來解決客戶問題; 推動某些客戶行為,進而影響業務成果”
我們發布了一項功能來解決客戶問題; 推動某些客戶行為,進而影響業務成果。 也許我們運送的東西會為客戶節省時間、提高效率或降低成本。 然後我們考慮業務成果或業務成果。 如果我們解決客戶問題並推動客戶行為,我們期望在我們的業務中看到什麼影響? 我們使用以下類別來構建業務影響:
- 獲取:它會幫助我們獲取新客戶嗎?
- 擴展:它會幫助我們加深或擴大現有客戶的使用嗎?
- 保留:它會在保留客戶或防止流失方面發揮作用嗎?
- 收入:我們可以直接將其與商業影響聯繫起來嗎? 例如,像附加組件這樣的東西可以很容易地用收入來衡量。
“衡量每個產品功能的商業影響並不總是可能的”
有時,交付產品和推動業務成果之間的界限似乎是天壤之別——而且衡量每個產品功能的商業影響並不總是可能的。 我們不會為此煩惱,我們當然也不想硬塞每一個功能以適應收入目標——但我們會盡可能多地將其映射回來。
我們檢測我們的產品,以便我們可以衡量我們的結果
我們需要確保我們擁有正確的數據來衡量我們正在努力爭取的結果。 我們通過跟踪感興趣的特定事件以及有關這些事件的其他上下文來檢測我們的產品。 我們使用內部分析框架進行檢測,跟踪每個事件的動作、對象、地點和元數據。 對講機的每個用戶都可以在特定地點對特定對象執行操作,其中:
- 動作:描述用戶採取的動作,例如打開、點擊。
- 對象:描述被操作執行或受操作影響的對象,例如對話細節、消息。
- 地點:描述觸發動作的位置。 這通常代表用戶所在應用程序的頁面,例如收件箱。
- 元數據:提供有關每個特定事件發生的附加信息,例如 URL、ID、狀態。
這是衡量和推動成果的關鍵一步。 如果該功能尚未進行檢測,則它還沒有準備好發貨。

我們總是假設我們需要迭代我們的產品
我們知道,我們不會總是為我們的客戶或我們的業務提供完全正確的產品,因此我們計劃並留出時間迭代我們的產品,直到我們這樣做。
這並不容易——一旦發布了一個功能,很自然地就會感覺到對路線圖上的下一個事物的拉動。 我們都對“運送,繼續,運送,繼續”的心態感到內疚,但在 Intercom,我們知道我們的工作並沒有在我們運送時完成。 所以我們計劃迭代。
發貨後,我們爭取採用和使用
我們知道這不僅僅是“建造它,他們就會來”的情況——我們必須爭取採用和使用。 這意味著定義、衡量和理解核心指標,如意識、意圖、激活、採用和參與。 我們在發布後跟踪和審查這些指標,解釋結果,並在需要時採取行動改進。
我們審查結果並分享我們的經驗
為了整理我們的學習成果,我們有一個嚴格的流程來審查結果並在整個公司範圍內廣泛分享我們的結論。 這不僅針對 PM、數據科學家或研究人員,還針對整個團隊。 我們為此使用的主要工具之一是結果報告。
在我們發布一項功能大約一個月後,我們會完成一份結果報告,以反映我們是否看到了我們預期的結果。 我們查看定量和定性反饋來評估我們的表現,並討論我們因此需要做出的行動或決定。
對於更大的項目或大型發布,我們可能會確定多個檢查點,在三個月、六個月或十二個月時評估結果。 團隊將他們的成果報告分享到一個專門的 Slack 渠道,以便在團隊內部和整個公司範圍內盡可能多地接觸到更多人。
“我們總是假設需要一些發布後的迭代,並且通常認為這是原始項目的擴展”
我們總是假設需要一些發布後的迭代,並且通常認為這是原始項目的擴展。 也就是說,有時我們需要重新確定路線圖的優先級,以便為更大的變化騰出空間。 一個好的指導原則是問自己:“我們是否為大多數目標客戶充分解決了已識別的問題? 我們是否實現了我們的目標客戶和業務成果?”
注意反模式
這些做法可能會在一段時間後潛入,而不會引起任何人的注意。 這些可能看起來像:
- 在項目開始時未能決定我們期望的結果。
- 未能為產品、功能或結果定義合適的指標和正確的工具。
- 運送並繼續前進。
- 把我們不打算造成的結果歸功於自己。
- 匆忙完成結果報告流程只是為了檢查一個框。
與這些反模式作鬥爭需要真正理解“交付成果”原則以及它對我們的客戶和業務的重要性的團隊的大量工作。 我們需要繼續將這一原則應用於我們構建的所有東西,以確保它融入我們的文化和我們解決客戶問題的方式中。 這樣做有助於我們為客戶和公司大規模提供有形價值。
這是我們的 Intercom on Product 系列的第二篇文章,Intercom 研發團隊的專家在其中談論指導他們日常工作的原則。 在此處閱讀該系列中的其他博客文章。