重組 Braze 產品團隊

任何軟件產品背後最重要的驅動力是構建它的一群人——以及他們之間的關係。 因此，重要的是要以一種允許他們擁有盡可能多的影響力和影響力的方式來安排團隊。

在 Braze，我們對我們的產品和工程組織的設計方式進行了廣泛的思考，並希望分享我們從重大部門重組中獲得的經驗，這幫助我們極大地改進了我們如何優先考慮功能、開發團隊專業知識並更有效地構建我們的產品。

早期結構：產品/市場契合度及其他

尋找產品/市場契合度——並利用它來發展業務——是所有初創公司都必須經過的考驗。 在初創公司發展的整個階段，實驗速度和快速利用機會的能力至關重要。 為此，我們最初的產品團隊結構是這樣的：

這種根據職能專業劃分我們團隊的結構之所以運作良好，有幾個原因。

首先，它使我們能夠在產品/市場契合的過程中有效地應對產品轉型變化——專家可以擁有我們的大量代碼庫，並使用他們最熟悉的語言、框架和設計決策。 在大量咖啡因的推動下，一體式項目“團隊”經常處理巨大的努力。 其中包括構建我們面向客戶的公共 API 和徹底改造我們的整個消息發送基礎設施，通常擔任唯一工程師、產品經理和設計師的角色。 這些極端措施對大公司來說是瘋狂的，但在早期成長過程中是必要的，而且幾乎是例行公事。

此外，這種結構幫助我們在只有 10 到 15 人的團隊中深入掌握了某些技術領域。 我們核心產品的許多元素——例如我們前端的模型-視圖-控制器層、API 和高吞吐量的消息發送代碼——只有少數人完全理解。

當時，這很簡單，而且我們所需要的一切。 當速度就是一切時，基於簡單指導的組織有助於減少認知開銷，並使我們能夠將注意力集中在可以發揮最大作用的地方。

後期結構：增長和擴展

然而，隨著我們的團隊超過 30 或 40 人，這種結構開始瓦解。 我們最終確定重組產品團隊是解決我們面臨的一些最大挑戰的方法。 我們正在花費不可持續的努力來兼顧技能和時間表來為戰略項目組建團隊。 我們還花費了過多的時間來確定優先級，並且經常發現自己在整個業務中強制對所有產品優先級進行排序，因為我們基於技術的團隊結構沒有直接映射到最重要的產品需求。 最後，我們幾乎沒有機會讓團隊成員在特定客戶用例方面積累深厚的經驗。

我們最終轉向了一個圍繞敏捷跨職能團隊構建的組織，類似於 Spotify 推廣的 Squad/Tribe 模型。 我們的新組織結構如下所示：

我們團隊的大多數人都在“產品垂直領域”工作，對應於我們產品或業務的關鍵領域。 例如：

• 我們的電子郵件和企業團隊從上到下運行電子郵件，以及某些產品領域，例如對我們許多最大客戶至關重要的權限管理。
• 我們的消息傳遞和自動化團隊擁有與用戶細分、消息傳遞和我們的旗艦編排產品 Canvas 相關的多個產品領域。

在一個垂直領域，我們希望優先級（相對）簡單，因為每個垂直領域都對應一組特定的客戶需求。 視覺設計、DevOps 和我們的基礎設施工程團隊等特定團隊跨越整個平台，在關鍵領域建立一致性。

影響

我們的重組顯著減少了跨團隊的依賴。 以前，我們一直在努力解決類似於數獨的調度問題，即在給定時間將專業技能組合（工程、設計、產品管理等）的適當平衡分配到給定項目中。 它還調整了短期激勵措施——在過渡之前，團隊經常發現自己依賴於目標不相關的對手。 借助我們的新結構，產品團隊變得獨立，對時間線有更多的控制權，並且在目標上完全一致，從而提高了生產力和士氣。

新的組織設計還改進了優先級。 例如，我們的電子郵件和企業團隊可能需要在升級我們的電子郵件基礎設施、構建核心電子郵件功能或修復企業可用性問題之間做出決定——這是一個簡單且易於量化的決定，因為這三者都以類似的方式與我們客戶的需求相關.

一個為太多高優先級需求而苦苦掙扎的團隊也表明他們的產品領域需要更多資源。 這使我們能夠將困難的優先級問題重新定義為人員需求，這些問題仍然具有挑戰性，但在概念上很容易解決。

最後，將大多數團隊專注於特定產品領域，可以讓個人隨著時間的推移建立深厚的專業知識和高效的工作關係。 最初，在構建的最初幾年，個人基本上可以將整個產品和代碼庫放在腦海中，但隨著我們的發展，這變得不可能。 產品問題是分形的：每次你仔細觀察，你會發現更多的細微差別和深度。 因此，在產品或代碼庫的特定領域花費大量時間並深入了解其業務需求是實現真正產品突破的最佳方式之一。 此外，創建專注的長期團隊可以建立所有權和融洽的關係，並允許一組一致的合作者之間不言而喻的工作關係凝聚在一起。

當然，沒有一個系統是完美的。 通過專注於以產品為導向的支柱，我們增加了團隊優化本地化需求的潛力，而犧牲了整體優先級。 例如，人們可能會關注本地化的技術債務（“這個控制器很麻煩”）而不是全球性問題（“改變我們的前端框架將提高整體工程速度”）。 出於對這一需求的預期，我們採取措施建立了上述跨領域團隊，並為其他廣泛的項目使用了專門的委員會——例如，建立一個由前端組件和設計模式組成的整體產品/設計系統的委員會.

我們的新結構還為整體的、變革性的產品變化帶來了更高的活化能。 我們產品的某些領域，例如我們的後端 API，由多個團隊共同擁有。 對我們代碼庫的廣泛、交叉領域進行全面更改的門檻更高，因此一旦您的產品骨架基本形成，這種類型的結構效果最好。

外賣

總體而言，我們對重新設計的產品組織結構感到滿意：我們已經解決或大大改善了圍繞團隊依賴性、優先級和建立長期產品專業知識的挑戰，並且還為我們如何擴展制定了有用的路線圖。 特別是，我們了解到：

• 消除依賴和調整激勵措施會帶來巨大的效率提升。
• 蘋果對蘋果的優先排序既簡單又有效。
• 在特定客戶或業務需求方面的深厚專業知識可以帶來更好的產品成果。
• 長時間與相同的團隊成員合作對於建立良好的工作關係至關重要。

我會向任何具有某些關鍵特徵的團隊推薦這種結構：一個跨職能的組織，其中產品經理、設計師和工程師等職能專家是平等的利益相關者； 合併後的產品開發團隊大約有 15-20 人以上； 最重要的是，牢固的產品與市場契合度。 如果這種類型的團隊結構聽起來對您有吸引力，我們正在招聘！