從 Web2 進入 Web3 的產品經理
組織的溝通架構 Communication Stack
身為產品經理的你，對於以下這些情境是否感到熟悉：
- 團隊成員時常覺得不清楚公司或部門的方向或目標？
- 團隊成員不了解其他部門在做什麼？
- 團隊成員不確定目前做的事情是在整個公司藍圖的哪一個部分？
- 老闆也不太確定你們團隊在做什麼？目標達成的狀況
你並不孤單，其實不管是新創或是成熟的大企業，不管是 Web2 還是 Web3，只要人多了，只要有不同部門與團隊分工，資訊傳遞就會有落差與阻礙，而這些落差就會造成以上的問題，久而久之，大家不知道為何而戰，動機就會變低，不知道如何戰，混亂度就會變高，進入惡性循環。
要解決這個問題，就需要制定組織的溝通架構（Communication Stack），把要溝通的項目分類，用適合的媒介，用合適的節奏來進行溝通。
今天我們就來聊聊產品公司可以如何建立溝通架構，可分三步驟：
- 步驟一. 將溝通的項目分類
- 步驟二.依序建構內容
- 步驟三.訂出溝通的節奏
步驟一. 將溝通的項目分類
很多時候溝通不順或沒效率，其實是討論的層級不太一致，例如在策略會議討論 UX 的細節規格，或是在規格討論時講太上層的目標。所以，制定溝通系統的第一步是將溝通的內容分級。
分類的方法很多，我參考知名電子報 Lenny Newsletter 的分類，將產品的資訊分成：Mission & Vision、Strategy、Goals、Roadmap 以及 Task，如下圖所示：
步驟二.依序建構內容
有了分類之後，接著，就是依照上圖金字塔由底層到頂端的順序（Mission & Vision → Strategy → Goals → Roadmap → Task）建構出不同分類的內容。
然而每個組織的狀況不同。
常見的狀況是，組織並沒有 Mission & Vision、Strategy、Goals、Roadmap 等內容，只有一堆待執行的 Tasks，團隊時常忙著這些 Tasks，進行很多不知為何的作業，儼然是 Feature factory。這樣的組織需要依序建立起 Mission & Vision、Strategy、Goals、Roadmap，這會是一個組織從新定義公司與產品的過程，這會是個不算短的過程，常常要歷時好幾個月。
也有些組織有很棒的 Mission & Vision，管理層也有很棒的 Strategy 與 Goals，只是沒有能夠將策略轉換成執行計畫的 Roadmap 與 Task。這樣的組織就需要訂出能夠落地的 Roadmap，並找出方法讓團隊能夠執行相對應的 Tasks。
關於如何建立 Strategy、Roadmap 與 Goals，可以參考以下這些文章：
步驟三.訂出溝通的節奏
有了分類與內容，接下來就是訂出組織間溝通的方式與頻率。
一般來說，金字塔底端的內容，愈不容易改動，改動的頻率也較低，例如 Mission & Vision 可能好幾年才會修改一次。而如果是遇到大幅度的修改時，那個狀況叫做 Pivot。
而金字塔頂端的內容，則較容易動態調整，例如 Roadmap 通常是每季或是每月的頻率來檢視與調整。
各位可以參考不同分類資訊的溝通重點、時間維度、適合的工具與方法，以及常見的溝通節奏。
在過往的經驗中，我覺得有些溝通的實踐很棒，跟大家分享：
1.錄影！錄影！錄影！
大概沒有什麼形式可以比影片更能重現內容的完整性的。我待過一些知識管理做得很棒的公司，他們都會把重要的內容（例如：接下來的策略、公司重大方向轉變、年度或季度的 OKR 等）錄下來，存放在知識管理文件中，方便大家後續查閱。我曾經有個經驗是，在新人 Onboarding 時看了數個月前公司錄製的年度策略影片，而深刻地了解到公司如何決定方向改變的脈絡，這個影片對我的幫助非常大。
2.以文字方式呈現的 Mission & Vision 與 Strategy。
我發現很多極為出色的管理者，不僅是能言善道，而且也擅於透過文字讓團隊理解管理者的思考脈絡，為什麼下了這樣的判斷。很多人會覺得 Mission & Vision 與 Strategy 虛虛的，有點空泛。那是因為很多管理者只是以口頭的方式來表達這些內容，但是口頭的表達，很多時候沒有那麼的結構化，也沒辦法解釋太複雜的資訊。其實，Mission & Vision 與 Strategy 反倒更適合用文字的方式來呈現。下面的案例是 Mark Zuckerberg 在 2015 年時分享了對 VR/AR 的 Vsion 與 Strategy。
3.能促進雙向溝通的 All Hands 與 Ask Me Anything。
上面的兩點都比較是上對下的單向傳達。很多時候，促進雙向的對話對溝通也是非常有幫助，可以釐清管理層與員工夥伴間的認知落差。很多組織會透過 All Hands 或 AMA (Ask Me Anything) 的機會，開放員工夥伴提問，由公司管理階層來回答員工在意的問題，來促進雙向的對話。這可以參考我之前文章中「員工大會」的部分。
4.連結 Goals 與 Tasks 的 Outcome-based Roadmap。
實務上策略面的溝通通常不會太過頻繁，至少不會每天每週都在提。有時候團隊工作一忙起來，專注在手頭的工作一久，有時候的確會不確定任務與目標間的關聯。這個時候 Outcome-based Roadmap 就能夠派上用場。Outcome-based Roadmap 有別於 Feature-based Roadmap，它最主要就是希望能夠呈現「目標與期待成果」和「任務」之間的關聯。它對於讓團隊知道為何而戰非常有幫助。
關於 Outcome-based Roadmap，可以參考以下文章：
How to build an outcome-driven product roadmap | Productboard
小結
身為產品主管或產品經理，當你聽到團隊開始有「時常覺得不清楚公司或部門的方向或目標」、「不了解其他部門在做什麼」，或是「不確定目前做的事情是在整個公司藍圖的哪一個部分」。很有可能是你們的溝通架構 Communication Stack 出了問題，不妨盤點一下組織內的溝通內容，透過文章介紹的三步驟，提升溝通的品質，減少資訊傳遞的落差吧！
喜欢我的文章吗？
别忘了给点支持与赞赏，让我知道创作的路上有你陪伴。
发布评论…