"據不完全統計，筆者在工作中約60%以上的時間用於溝通協調。當團隊中理應提供洞察，為產品指明道路的產品經理們深陷「體力協作」的低效率泥潭時，產品經理在自身價值感變得稀薄的同時，產品的市場表現也將趨向平庸。是否有辦法跳出低效循環？如果你也在被類似問題困擾，歡迎進來聊聊。
據不完全統計，筆者在工作中約60%以上的時間用於溝通協調。當團隊中理應提供洞察，為產品指明道路的產品經理們深陷「體力協作」的低效率泥潭時，產品經理在自身價值感變得稀薄的同時，產品的市場表現也將趨向平庸。是否有辦法跳出低效循環？如果你也在被類似問題困擾，歡迎進來聊聊。
本問的本質是一篇「求助文」，筆者將為大家介紹自身在工作中碰到的問題及問題發生的背景，及原因的剖析，希望在給大家帶來啟發的同時，也可以收集到大家的意見，為解決問題提供新的可能性。
問題發生的背景
筆者在一家K12教育公司做產品（小學業務），主業務是2019年比較熱的在線教育班課，具有重運營，強KPI導向的特徵。筆者從冷啟動階段加入產品團隊，陪伴產品進入成長期，目前在業務上做大量嘗試，產品迭代頻率高，業務拓張速度快，很多問題亦隨之出現。
業務組織背景
每條業務線都是一個敏捷團隊，有著自己的核心指標及迭代節奏。
"據不完全統計，筆者在工作中約60%以上的時間用於溝通協調。當團隊中理應提供洞察，為產品指明道路的產品經理們深陷「體力協作」的低效率泥潭時，產品經理在自身價值感變得稀薄的同時，產品的市場表現也將趨向平庸。是否有辦法跳出低效循環？如果你也在被類似問題困擾，歡迎進來聊聊。
本問的本質是一篇「求助文」，筆者將為大家介紹自身在工作中碰到的問題及問題發生的背景，及原因的剖析，希望在給大家帶來啟發的同時，也可以收集到大家的意見，為解決問題提供新的可能性。
問題發生的背景
筆者在一家K12教育公司做產品（小學業務），主業務是2019年比較熱的在線教育班課，具有重運營，強KPI導向的特徵。筆者從冷啟動階段加入產品團隊，陪伴產品進入成長期，目前在業務上做大量嘗試，產品迭代頻率高，業務拓張速度快，很多問題亦隨之出現。
業務組織背景
每條業務線都是一個敏捷團隊，有著自己的核心指標及迭代節奏。
在公司層面，這種業務架構的優勢是線內效率足夠高，業務響應速度快，靈活度較高；缺點是跨線協作成本極高，各業務線之間訴求不一致，信息孤島效應明顯。
團隊背景
「產品+研發+設計+數據+運營」是敏捷團隊標配；筆者所處的產品團隊3人，產品及研發比例穩定維持在1：6，隨著業務發展，影響效率的明顯變量：
1. 團隊：業務人員數量激增
半年內，業務團隊從30人拓張至150人+，意味著產品需要在業務人員的效能上提供支持。
2. 業務：業務模型尚未調整至最優，需頻繁做嘗試
高頻率的實驗對團隊的整體信息管理提出更高要求，大量的投放AB對照實驗，產品每個迭代此類業務需求佔需求總量的70%。
問題發生的場景
團隊內&外日常協作
場景一：插入需求
Boss：今天戰略組給了最新信息，出臺了新政策XXX，我們需要在這個迭代內上線XX，你別用這種眼神看著我，沒錯，就走插入需求~
我：我手上優先級次高的需求是XXX和XXX，如果是我來推進，大概率會替換掉這兩個需求。但我知道Tony（其他PM）手上的需求這期排的不是很滿（甩鍋+1），不如咱們拉產品組討論下？
Boss：好的，你來拉會，我今天下午4點之後和明天上午10點有時間
我：（拉起產研會議）省略1W字，強行達成共識，確定了插入需求的負責人和置換掉的項目
插入評審會議：開發負責人生無可戀的參會，同步了本迭代項目的推進狀況，和產品明確了項目優先級後，重新分配了開發資源（產品組威信-100）
場景二：內部日常溝通
BI：咱們的這個流量入口，現在是按照什麼判斷條件，什麼流量比例分發流量？總共有幾個實驗組？
我：我上週做了一期，是按XX條件，XX比例分發，總共XX組。不確定實驗組的總量，我印象中上個迭代是呆呆（其他PM）在負責這部分邏輯。
BI：上週是泡泡（其他BI）在負責這個項目，我問過她，她說上週封版後XX（產品老大）走了一個插入需求，加了一個分發邏輯
我：這種不可見的邏輯最頭疼了，我問下老大和呆呆
釘釘拉群：（產品未能達成共識，拉入了負責的開發和BI，最終拼湊出了原需求的全貌）
場景三：跨線協作
我：hey，我們有這樣一個需求blahblah，我們希望的時間點是blahblah
接口人：嗯，這個需求實現需要和我們的開發確認，設計需要和我們的UI確認，有數據預期嗎？最好和BI也說一下。
我：排期目前確認不了嗎？
接口人：最近排期比較滿，我建議先把兩邊的相關人員拉個會吧。
我：（拉起會議）咦，你們的開發負責人呢？
接口人：他今天請假啦，咱們先對接信息吧，明天我幫你你單約下負責人
我：（對接了部分信息，會議結束，由於信息缺失並未達成共識）
-隔天，帶著我線的開發負責人約到了開發負責人
我：您好，想必XXX（接口人）已經給您介紹過背景了
負責人：沒有，你幫我簡單介紹下吧
我：blahblah，您看可以進排期嗎？
負責人：額，這個需要和XXX（另一條線的某研發負責人）確認，確實對他們有依賴，下週咱們找時間開個會吧。
我：（本月第X次燃起離職念頭）
日常協作問題總結
不論項目內外，能看到的共性問題是我們必須先“搞定人”才能獲取我們決策需要的信息；我們需要將搞定的“所有人”加工過的信息拼湊起來，才能勉強窺得信息的全貌。
理想場景和現實場景總是有所出入：
"據不完全統計，筆者在工作中約60%以上的時間用於溝通協調。當團隊中理應提供洞察，為產品指明道路的產品經理們深陷「體力協作」的低效率泥潭時，產品經理在自身價值感變得稀薄的同時，產品的市場表現也將趨向平庸。是否有辦法跳出低效循環？如果你也在被類似問題困擾，歡迎進來聊聊。
本問的本質是一篇「求助文」，筆者將為大家介紹自身在工作中碰到的問題及問題發生的背景，及原因的剖析，希望在給大家帶來啟發的同時，也可以收集到大家的意見，為解決問題提供新的可能性。
問題發生的背景
筆者在一家K12教育公司做產品（小學業務），主業務是2019年比較熱的在線教育班課，具有重運營，強KPI導向的特徵。筆者從冷啟動階段加入產品團隊，陪伴產品進入成長期，目前在業務上做大量嘗試，產品迭代頻率高，業務拓張速度快，很多問題亦隨之出現。
業務組織背景
每條業務線都是一個敏捷團隊，有著自己的核心指標及迭代節奏。
在公司層面，這種業務架構的優勢是線內效率足夠高，業務響應速度快，靈活度較高；缺點是跨線協作成本極高，各業務線之間訴求不一致，信息孤島效應明顯。
團隊背景
「產品+研發+設計+數據+運營」是敏捷團隊標配；筆者所處的產品團隊3人，產品及研發比例穩定維持在1：6，隨著業務發展，影響效率的明顯變量：
1. 團隊：業務人員數量激增
半年內，業務團隊從30人拓張至150人+，意味著產品需要在業務人員的效能上提供支持。
2. 業務：業務模型尚未調整至最優，需頻繁做嘗試
高頻率的實驗對團隊的整體信息管理提出更高要求，大量的投放AB對照實驗，產品每個迭代此類業務需求佔需求總量的70%。
問題發生的場景
團隊內&外日常協作
場景一：插入需求
Boss：今天戰略組給了最新信息，出臺了新政策XXX，我們需要在這個迭代內上線XX，你別用這種眼神看著我，沒錯，就走插入需求~
我：我手上優先級次高的需求是XXX和XXX，如果是我來推進，大概率會替換掉這兩個需求。但我知道Tony（其他PM）手上的需求這期排的不是很滿（甩鍋+1），不如咱們拉產品組討論下？
Boss：好的，你來拉會，我今天下午4點之後和明天上午10點有時間
我：（拉起產研會議）省略1W字，強行達成共識，確定了插入需求的負責人和置換掉的項目
插入評審會議：開發負責人生無可戀的參會，同步了本迭代項目的推進狀況，和產品明確了項目優先級後，重新分配了開發資源（產品組威信-100）
場景二：內部日常溝通
BI：咱們的這個流量入口，現在是按照什麼判斷條件，什麼流量比例分發流量？總共有幾個實驗組？
我：我上週做了一期，是按XX條件，XX比例分發，總共XX組。不確定實驗組的總量，我印象中上個迭代是呆呆（其他PM）在負責這部分邏輯。
BI：上週是泡泡（其他BI）在負責這個項目，我問過她，她說上週封版後XX（產品老大）走了一個插入需求，加了一個分發邏輯
我：這種不可見的邏輯最頭疼了，我問下老大和呆呆
釘釘拉群：（產品未能達成共識，拉入了負責的開發和BI，最終拼湊出了原需求的全貌）
場景三：跨線協作
我：hey，我們有這樣一個需求blahblah，我們希望的時間點是blahblah
接口人：嗯，這個需求實現需要和我們的開發確認，設計需要和我們的UI確認，有數據預期嗎？最好和BI也說一下。
我：排期目前確認不了嗎？
接口人：最近排期比較滿，我建議先把兩邊的相關人員拉個會吧。
我：（拉起會議）咦，你們的開發負責人呢？
接口人：他今天請假啦，咱們先對接信息吧，明天我幫你你單約下負責人
我：（對接了部分信息，會議結束，由於信息缺失並未達成共識）
-隔天，帶著我線的開發負責人約到了開發負責人
我：您好，想必XXX（接口人）已經給您介紹過背景了
負責人：沒有，你幫我簡單介紹下吧
我：blahblah，您看可以進排期嗎？
負責人：額，這個需要和XXX（另一條線的某研發負責人）確認，確實對他們有依賴，下週咱們找時間開個會吧。
我：（本月第X次燃起離職念頭）
日常協作問題總結
不論項目內外，能看到的共性問題是我們必須先“搞定人”才能獲取我們決策需要的信息；我們需要將搞定的“所有人”加工過的信息拼湊起來，才能勉強窺得信息的全貌。
理想場景和現實場景總是有所出入：
項目管理
項目推進流程：
"據不完全統計，筆者在工作中約60%以上的時間用於溝通協調。當團隊中理應提供洞察，為產品指明道路的產品經理們深陷「體力協作」的低效率泥潭時，產品經理在自身價值感變得稀薄的同時，產品的市場表現也將趨向平庸。是否有辦法跳出低效循環？如果你也在被類似問題困擾，歡迎進來聊聊。
本問的本質是一篇「求助文」，筆者將為大家介紹自身在工作中碰到的問題及問題發生的背景，及原因的剖析，希望在給大家帶來啟發的同時，也可以收集到大家的意見，為解決問題提供新的可能性。
問題發生的背景
筆者在一家K12教育公司做產品（小學業務），主業務是2019年比較熱的在線教育班課，具有重運營，強KPI導向的特徵。筆者從冷啟動階段加入產品團隊，陪伴產品進入成長期，目前在業務上做大量嘗試，產品迭代頻率高，業務拓張速度快，很多問題亦隨之出現。
業務組織背景
每條業務線都是一個敏捷團隊，有著自己的核心指標及迭代節奏。
在公司層面，這種業務架構的優勢是線內效率足夠高，業務響應速度快，靈活度較高；缺點是跨線協作成本極高，各業務線之間訴求不一致，信息孤島效應明顯。
團隊背景
「產品+研發+設計+數據+運營」是敏捷團隊標配；筆者所處的產品團隊3人，產品及研發比例穩定維持在1：6，隨著業務發展，影響效率的明顯變量：
1. 團隊：業務人員數量激增
半年內，業務團隊從30人拓張至150人+，意味著產品需要在業務人員的效能上提供支持。
2. 業務：業務模型尚未調整至最優，需頻繁做嘗試
高頻率的實驗對團隊的整體信息管理提出更高要求，大量的投放AB對照實驗，產品每個迭代此類業務需求佔需求總量的70%。
問題發生的場景
團隊內&外日常協作
場景一：插入需求
Boss：今天戰略組給了最新信息，出臺了新政策XXX，我們需要在這個迭代內上線XX，你別用這種眼神看著我，沒錯，就走插入需求~
我：我手上優先級次高的需求是XXX和XXX，如果是我來推進，大概率會替換掉這兩個需求。但我知道Tony（其他PM）手上的需求這期排的不是很滿（甩鍋+1），不如咱們拉產品組討論下？
Boss：好的，你來拉會，我今天下午4點之後和明天上午10點有時間
我：（拉起產研會議）省略1W字，強行達成共識，確定了插入需求的負責人和置換掉的項目
插入評審會議：開發負責人生無可戀的參會，同步了本迭代項目的推進狀況，和產品明確了項目優先級後，重新分配了開發資源（產品組威信-100）
場景二：內部日常溝通
BI：咱們的這個流量入口，現在是按照什麼判斷條件，什麼流量比例分發流量？總共有幾個實驗組？
我：我上週做了一期，是按XX條件，XX比例分發，總共XX組。不確定實驗組的總量，我印象中上個迭代是呆呆（其他PM）在負責這部分邏輯。
BI：上週是泡泡（其他BI）在負責這個項目，我問過她，她說上週封版後XX（產品老大）走了一個插入需求，加了一個分發邏輯
我：這種不可見的邏輯最頭疼了，我問下老大和呆呆
釘釘拉群：（產品未能達成共識，拉入了負責的開發和BI，最終拼湊出了原需求的全貌）
場景三：跨線協作
我：hey，我們有這樣一個需求blahblah，我們希望的時間點是blahblah
接口人：嗯，這個需求實現需要和我們的開發確認，設計需要和我們的UI確認，有數據預期嗎？最好和BI也說一下。
我：排期目前確認不了嗎？
接口人：最近排期比較滿，我建議先把兩邊的相關人員拉個會吧。
我：（拉起會議）咦，你們的開發負責人呢？
接口人：他今天請假啦，咱們先對接信息吧，明天我幫你你單約下負責人
我：（對接了部分信息，會議結束，由於信息缺失並未達成共識）
-隔天，帶著我線的開發負責人約到了開發負責人
我：您好，想必XXX（接口人）已經給您介紹過背景了
負責人：沒有，你幫我簡單介紹下吧
我：blahblah，您看可以進排期嗎？
負責人：額，這個需要和XXX（另一條線的某研發負責人）確認，確實對他們有依賴，下週咱們找時間開個會吧。
我：（本月第X次燃起離職念頭）
日常協作問題總結
不論項目內外，能看到的共性問題是我們必須先“搞定人”才能獲取我們決策需要的信息；我們需要將搞定的“所有人”加工過的信息拼湊起來，才能勉強窺得信息的全貌。
理想場景和現實場景總是有所出入：
項目管理
項目推進流程：
在最理想的狀況下，我們按周推進需求，會有各種不可抗力導致需要插入需求。
"據不完全統計，筆者在工作中約60%以上的時間用於溝通協調。當團隊中理應提供洞察，為產品指明道路的產品經理們深陷「體力協作」的低效率泥潭時，產品經理在自身價值感變得稀薄的同時，產品的市場表現也將趨向平庸。是否有辦法跳出低效循環？如果你也在被類似問題困擾，歡迎進來聊聊。
本問的本質是一篇「求助文」，筆者將為大家介紹自身在工作中碰到的問題及問題發生的背景，及原因的剖析，希望在給大家帶來啟發的同時，也可以收集到大家的意見，為解決問題提供新的可能性。
問題發生的背景
筆者在一家K12教育公司做產品（小學業務），主業務是2019年比較熱的在線教育班課，具有重運營，強KPI導向的特徵。筆者從冷啟動階段加入產品團隊，陪伴產品進入成長期，目前在業務上做大量嘗試，產品迭代頻率高，業務拓張速度快，很多問題亦隨之出現。
業務組織背景
每條業務線都是一個敏捷團隊，有著自己的核心指標及迭代節奏。
在公司層面，這種業務架構的優勢是線內效率足夠高，業務響應速度快，靈活度較高；缺點是跨線協作成本極高，各業務線之間訴求不一致，信息孤島效應明顯。
團隊背景
「產品+研發+設計+數據+運營」是敏捷團隊標配；筆者所處的產品團隊3人，產品及研發比例穩定維持在1：6，隨著業務發展，影響效率的明顯變量：
1. 團隊：業務人員數量激增
半年內，業務團隊從30人拓張至150人+，意味著產品需要在業務人員的效能上提供支持。
2. 業務：業務模型尚未調整至最優，需頻繁做嘗試
高頻率的實驗對團隊的整體信息管理提出更高要求，大量的投放AB對照實驗，產品每個迭代此類業務需求佔需求總量的70%。
問題發生的場景
團隊內&外日常協作
場景一：插入需求
Boss：今天戰略組給了最新信息，出臺了新政策XXX，我們需要在這個迭代內上線XX，你別用這種眼神看著我，沒錯，就走插入需求~
我：我手上優先級次高的需求是XXX和XXX，如果是我來推進，大概率會替換掉這兩個需求。但我知道Tony（其他PM）手上的需求這期排的不是很滿（甩鍋+1），不如咱們拉產品組討論下？
Boss：好的，你來拉會，我今天下午4點之後和明天上午10點有時間
我：（拉起產研會議）省略1W字，強行達成共識，確定了插入需求的負責人和置換掉的項目
插入評審會議：開發負責人生無可戀的參會，同步了本迭代項目的推進狀況，和產品明確了項目優先級後，重新分配了開發資源（產品組威信-100）
場景二：內部日常溝通
BI：咱們的這個流量入口，現在是按照什麼判斷條件，什麼流量比例分發流量？總共有幾個實驗組？
我：我上週做了一期，是按XX條件，XX比例分發，總共XX組。不確定實驗組的總量，我印象中上個迭代是呆呆（其他PM）在負責這部分邏輯。
BI：上週是泡泡（其他BI）在負責這個項目，我問過她，她說上週封版後XX（產品老大）走了一個插入需求，加了一個分發邏輯
我：這種不可見的邏輯最頭疼了，我問下老大和呆呆
釘釘拉群：（產品未能達成共識，拉入了負責的開發和BI，最終拼湊出了原需求的全貌）
場景三：跨線協作
我：hey，我們有這樣一個需求blahblah，我們希望的時間點是blahblah
接口人：嗯，這個需求實現需要和我們的開發確認，設計需要和我們的UI確認，有數據預期嗎？最好和BI也說一下。
我：排期目前確認不了嗎？
接口人：最近排期比較滿，我建議先把兩邊的相關人員拉個會吧。
我：（拉起會議）咦，你們的開發負責人呢？
接口人：他今天請假啦，咱們先對接信息吧，明天我幫你你單約下負責人
我：（對接了部分信息，會議結束，由於信息缺失並未達成共識）
-隔天，帶著我線的開發負責人約到了開發負責人
我：您好，想必XXX（接口人）已經給您介紹過背景了
負責人：沒有，你幫我簡單介紹下吧
我：blahblah，您看可以進排期嗎？
負責人：額，這個需要和XXX（另一條線的某研發負責人）確認，確實對他們有依賴，下週咱們找時間開個會吧。
我：（本月第X次燃起離職念頭）
日常協作問題總結
不論項目內外，能看到的共性問題是我們必須先“搞定人”才能獲取我們決策需要的信息；我們需要將搞定的“所有人”加工過的信息拼湊起來，才能勉強窺得信息的全貌。
理想場景和現實場景總是有所出入：
項目管理
項目推進流程：
在最理想的狀況下，我們按周推進需求，會有各種不可抗力導致需要插入需求。
最理想的項目推進場景，產品團隊規劃好需求後，協調資源推進需求，按時交付。
（實際推進項目時，資源和任務之間的聯繫更加複雜，為了便於對比，予以簡化）
總有多種多樣的原因導致我們的項目無法按時交付：
場景一：項目外部
"據不完全統計，筆者在工作中約60%以上的時間用於溝通協調。當團隊中理應提供洞察，為產品指明道路的產品經理們深陷「體力協作」的低效率泥潭時，產品經理在自身價值感變得稀薄的同時，產品的市場表現也將趨向平庸。是否有辦法跳出低效循環？如果你也在被類似問題困擾，歡迎進來聊聊。
本問的本質是一篇「求助文」，筆者將為大家介紹自身在工作中碰到的問題及問題發生的背景，及原因的剖析，希望在給大家帶來啟發的同時，也可以收集到大家的意見，為解決問題提供新的可能性。
問題發生的背景
筆者在一家K12教育公司做產品（小學業務），主業務是2019年比較熱的在線教育班課，具有重運營，強KPI導向的特徵。筆者從冷啟動階段加入產品團隊，陪伴產品進入成長期，目前在業務上做大量嘗試，產品迭代頻率高，業務拓張速度快，很多問題亦隨之出現。
業務組織背景
每條業務線都是一個敏捷團隊，有著自己的核心指標及迭代節奏。
在公司層面，這種業務架構的優勢是線內效率足夠高，業務響應速度快，靈活度較高；缺點是跨線協作成本極高，各業務線之間訴求不一致，信息孤島效應明顯。
團隊背景
「產品+研發+設計+數據+運營」是敏捷團隊標配；筆者所處的產品團隊3人，產品及研發比例穩定維持在1：6，隨著業務發展，影響效率的明顯變量：
1. 團隊：業務人員數量激增
半年內，業務團隊從30人拓張至150人+，意味著產品需要在業務人員的效能上提供支持。
2. 業務：業務模型尚未調整至最優，需頻繁做嘗試
高頻率的實驗對團隊的整體信息管理提出更高要求，大量的投放AB對照實驗，產品每個迭代此類業務需求佔需求總量的70%。
問題發生的場景
團隊內&外日常協作
場景一：插入需求
Boss：今天戰略組給了最新信息，出臺了新政策XXX，我們需要在這個迭代內上線XX，你別用這種眼神看著我，沒錯，就走插入需求~
我：我手上優先級次高的需求是XXX和XXX，如果是我來推進，大概率會替換掉這兩個需求。但我知道Tony（其他PM）手上的需求這期排的不是很滿（甩鍋+1），不如咱們拉產品組討論下？
Boss：好的，你來拉會，我今天下午4點之後和明天上午10點有時間
我：（拉起產研會議）省略1W字，強行達成共識，確定了插入需求的負責人和置換掉的項目
插入評審會議：開發負責人生無可戀的參會，同步了本迭代項目的推進狀況，和產品明確了項目優先級後，重新分配了開發資源（產品組威信-100）
場景二：內部日常溝通
BI：咱們的這個流量入口，現在是按照什麼判斷條件，什麼流量比例分發流量？總共有幾個實驗組？
我：我上週做了一期，是按XX條件，XX比例分發，總共XX組。不確定實驗組的總量，我印象中上個迭代是呆呆（其他PM）在負責這部分邏輯。
BI：上週是泡泡（其他BI）在負責這個項目，我問過她，她說上週封版後XX（產品老大）走了一個插入需求，加了一個分發邏輯
我：這種不可見的邏輯最頭疼了，我問下老大和呆呆
釘釘拉群：（產品未能達成共識，拉入了負責的開發和BI，最終拼湊出了原需求的全貌）
場景三：跨線協作
我：hey，我們有這樣一個需求blahblah，我們希望的時間點是blahblah
接口人：嗯，這個需求實現需要和我們的開發確認，設計需要和我們的UI確認，有數據預期嗎？最好和BI也說一下。
我：排期目前確認不了嗎？
接口人：最近排期比較滿，我建議先把兩邊的相關人員拉個會吧。
我：（拉起會議）咦，你們的開發負責人呢？
接口人：他今天請假啦，咱們先對接信息吧，明天我幫你你單約下負責人
我：（對接了部分信息，會議結束，由於信息缺失並未達成共識）
-隔天，帶著我線的開發負責人約到了開發負責人
我：您好，想必XXX（接口人）已經給您介紹過背景了
負責人：沒有，你幫我簡單介紹下吧
我：blahblah，您看可以進排期嗎？
負責人：額，這個需要和XXX（另一條線的某研發負責人）確認，確實對他們有依賴，下週咱們找時間開個會吧。
我：（本月第X次燃起離職念頭）
日常協作問題總結
不論項目內外，能看到的共性問題是我們必須先“搞定人”才能獲取我們決策需要的信息；我們需要將搞定的“所有人”加工過的信息拼湊起來，才能勉強窺得信息的全貌。
理想場景和現實場景總是有所出入：
項目管理
項目推進流程：
在最理想的狀況下，我們按周推進需求，會有各種不可抗力導致需要插入需求。
最理想的項目推進場景，產品團隊規劃好需求後，協調資源推進需求，按時交付。
（實際推進項目時，資源和任務之間的聯繫更加複雜，為了便於對比，予以簡化）
總有多種多樣的原因導致我們的項目無法按時交付：
場景一：項目外部
最高頻的場景是因外力（外部政策如ios平臺、TX、政府 or 內部高層行政命令）等原因導致的需求插入&變更，使得原有項目無法按時交付。
場景二：項目內部
"據不完全統計，筆者在工作中約60%以上的時間用於溝通協調。當團隊中理應提供洞察，為產品指明道路的產品經理們深陷「體力協作」的低效率泥潭時，產品經理在自身價值感變得稀薄的同時，產品的市場表現也將趨向平庸。是否有辦法跳出低效循環？如果你也在被類似問題困擾，歡迎進來聊聊。
本問的本質是一篇「求助文」，筆者將為大家介紹自身在工作中碰到的問題及問題發生的背景，及原因的剖析，希望在給大家帶來啟發的同時，也可以收集到大家的意見，為解決問題提供新的可能性。
問題發生的背景
筆者在一家K12教育公司做產品（小學業務），主業務是2019年比較熱的在線教育班課，具有重運營，強KPI導向的特徵。筆者從冷啟動階段加入產品團隊，陪伴產品進入成長期，目前在業務上做大量嘗試，產品迭代頻率高，業務拓張速度快，很多問題亦隨之出現。
業務組織背景
每條業務線都是一個敏捷團隊，有著自己的核心指標及迭代節奏。
在公司層面，這種業務架構的優勢是線內效率足夠高，業務響應速度快，靈活度較高；缺點是跨線協作成本極高，各業務線之間訴求不一致，信息孤島效應明顯。
團隊背景
「產品+研發+設計+數據+運營」是敏捷團隊標配；筆者所處的產品團隊3人，產品及研發比例穩定維持在1：6，隨著業務發展，影響效率的明顯變量：
1. 團隊：業務人員數量激增
半年內，業務團隊從30人拓張至150人+，意味著產品需要在業務人員的效能上提供支持。
2. 業務：業務模型尚未調整至最優，需頻繁做嘗試
高頻率的實驗對團隊的整體信息管理提出更高要求，大量的投放AB對照實驗，產品每個迭代此類業務需求佔需求總量的70%。
問題發生的場景
團隊內&外日常協作
場景一：插入需求
Boss：今天戰略組給了最新信息，出臺了新政策XXX，我們需要在這個迭代內上線XX，你別用這種眼神看著我，沒錯，就走插入需求~
我：我手上優先級次高的需求是XXX和XXX，如果是我來推進，大概率會替換掉這兩個需求。但我知道Tony（其他PM）手上的需求這期排的不是很滿（甩鍋+1），不如咱們拉產品組討論下？
Boss：好的，你來拉會，我今天下午4點之後和明天上午10點有時間
我：（拉起產研會議）省略1W字，強行達成共識，確定了插入需求的負責人和置換掉的項目
插入評審會議：開發負責人生無可戀的參會，同步了本迭代項目的推進狀況，和產品明確了項目優先級後，重新分配了開發資源（產品組威信-100）
場景二：內部日常溝通
BI：咱們的這個流量入口，現在是按照什麼判斷條件，什麼流量比例分發流量？總共有幾個實驗組？
我：我上週做了一期，是按XX條件，XX比例分發，總共XX組。不確定實驗組的總量，我印象中上個迭代是呆呆（其他PM）在負責這部分邏輯。
BI：上週是泡泡（其他BI）在負責這個項目，我問過她，她說上週封版後XX（產品老大）走了一個插入需求，加了一個分發邏輯
我：這種不可見的邏輯最頭疼了，我問下老大和呆呆
釘釘拉群：（產品未能達成共識，拉入了負責的開發和BI，最終拼湊出了原需求的全貌）
場景三：跨線協作
我：hey，我們有這樣一個需求blahblah，我們希望的時間點是blahblah
接口人：嗯，這個需求實現需要和我們的開發確認，設計需要和我們的UI確認，有數據預期嗎？最好和BI也說一下。
我：排期目前確認不了嗎？
接口人：最近排期比較滿，我建議先把兩邊的相關人員拉個會吧。
我：（拉起會議）咦，你們的開發負責人呢？
接口人：他今天請假啦，咱們先對接信息吧，明天我幫你你單約下負責人
我：（對接了部分信息，會議結束，由於信息缺失並未達成共識）
-隔天，帶著我線的開發負責人約到了開發負責人
我：您好，想必XXX（接口人）已經給您介紹過背景了
負責人：沒有，你幫我簡單介紹下吧
我：blahblah，您看可以進排期嗎？
負責人：額，這個需要和XXX（另一條線的某研發負責人）確認，確實對他們有依賴，下週咱們找時間開個會吧。
我：（本月第X次燃起離職念頭）
日常協作問題總結
不論項目內外，能看到的共性問題是我們必須先“搞定人”才能獲取我們決策需要的信息；我們需要將搞定的“所有人”加工過的信息拼湊起來，才能勉強窺得信息的全貌。
理想場景和現實場景總是有所出入：
項目管理
項目推進流程：
在最理想的狀況下，我們按周推進需求，會有各種不可抗力導致需要插入需求。
最理想的項目推進場景，產品團隊規劃好需求後，協調資源推進需求，按時交付。
（實際推進項目時，資源和任務之間的聯繫更加複雜，為了便於對比，予以簡化）
總有多種多樣的原因導致我們的項目無法按時交付：
場景一：項目外部
最高頻的場景是因外力（外部政策如ios平臺、TX、政府 or 內部高層行政命令）等原因導致的需求插入&變更，使得原有項目無法按時交付。
場景二：項目內部
偶發場景是某塊資源的負責人因故（突發生病、離職等）無法按時交付原定的子任務，這時需要重新協調項目資源達成目標。
項目管理問題總結
在真實場景下，需求的變更往往會在資源分配層面構成蝴蝶效應，牽一髮而動全身，現有的手段和工具只能讓我們的項目相對透明，卻沒辦法幫我們管理項目的風險。
團隊現階段使用的信息同步工具：
"據不完全統計，筆者在工作中約60%以上的時間用於溝通協調。當團隊中理應提供洞察，為產品指明道路的產品經理們深陷「體力協作」的低效率泥潭時，產品經理在自身價值感變得稀薄的同時，產品的市場表現也將趨向平庸。是否有辦法跳出低效循環？如果你也在被類似問題困擾，歡迎進來聊聊。
本問的本質是一篇「求助文」，筆者將為大家介紹自身在工作中碰到的問題及問題發生的背景，及原因的剖析，希望在給大家帶來啟發的同時，也可以收集到大家的意見，為解決問題提供新的可能性。
問題發生的背景
筆者在一家K12教育公司做產品（小學業務），主業務是2019年比較熱的在線教育班課，具有重運營，強KPI導向的特徵。筆者從冷啟動階段加入產品團隊，陪伴產品進入成長期，目前在業務上做大量嘗試，產品迭代頻率高，業務拓張速度快，很多問題亦隨之出現。
業務組織背景
每條業務線都是一個敏捷團隊，有著自己的核心指標及迭代節奏。
在公司層面，這種業務架構的優勢是線內效率足夠高，業務響應速度快，靈活度較高；缺點是跨線協作成本極高，各業務線之間訴求不一致，信息孤島效應明顯。
團隊背景
「產品+研發+設計+數據+運營」是敏捷團隊標配；筆者所處的產品團隊3人，產品及研發比例穩定維持在1：6，隨著業務發展，影響效率的明顯變量：
1. 團隊：業務人員數量激增
半年內，業務團隊從30人拓張至150人+，意味著產品需要在業務人員的效能上提供支持。
2. 業務：業務模型尚未調整至最優，需頻繁做嘗試
高頻率的實驗對團隊的整體信息管理提出更高要求，大量的投放AB對照實驗，產品每個迭代此類業務需求佔需求總量的70%。
問題發生的場景
團隊內&外日常協作
場景一：插入需求
Boss：今天戰略組給了最新信息，出臺了新政策XXX，我們需要在這個迭代內上線XX，你別用這種眼神看著我，沒錯，就走插入需求~
我：我手上優先級次高的需求是XXX和XXX，如果是我來推進，大概率會替換掉這兩個需求。但我知道Tony（其他PM）手上的需求這期排的不是很滿（甩鍋+1），不如咱們拉產品組討論下？
Boss：好的，你來拉會，我今天下午4點之後和明天上午10點有時間
我：（拉起產研會議）省略1W字，強行達成共識，確定了插入需求的負責人和置換掉的項目
插入評審會議：開發負責人生無可戀的參會，同步了本迭代項目的推進狀況，和產品明確了項目優先級後，重新分配了開發資源（產品組威信-100）
場景二：內部日常溝通
BI：咱們的這個流量入口，現在是按照什麼判斷條件，什麼流量比例分發流量？總共有幾個實驗組？
我：我上週做了一期，是按XX條件，XX比例分發，總共XX組。不確定實驗組的總量，我印象中上個迭代是呆呆（其他PM）在負責這部分邏輯。
BI：上週是泡泡（其他BI）在負責這個項目，我問過她，她說上週封版後XX（產品老大）走了一個插入需求，加了一個分發邏輯
我：這種不可見的邏輯最頭疼了，我問下老大和呆呆
釘釘拉群：（產品未能達成共識，拉入了負責的開發和BI，最終拼湊出了原需求的全貌）
場景三：跨線協作
我：hey，我們有這樣一個需求blahblah，我們希望的時間點是blahblah
接口人：嗯，這個需求實現需要和我們的開發確認，設計需要和我們的UI確認，有數據預期嗎？最好和BI也說一下。
我：排期目前確認不了嗎？
接口人：最近排期比較滿，我建議先把兩邊的相關人員拉個會吧。
我：（拉起會議）咦，你們的開發負責人呢？
接口人：他今天請假啦，咱們先對接信息吧，明天我幫你你單約下負責人
我：（對接了部分信息，會議結束，由於信息缺失並未達成共識）
-隔天，帶著我線的開發負責人約到了開發負責人
我：您好，想必XXX（接口人）已經給您介紹過背景了
負責人：沒有，你幫我簡單介紹下吧
我：blahblah，您看可以進排期嗎？
負責人：額，這個需要和XXX（另一條線的某研發負責人）確認，確實對他們有依賴，下週咱們找時間開個會吧。
我：（本月第X次燃起離職念頭）
日常協作問題總結
不論項目內外，能看到的共性問題是我們必須先“搞定人”才能獲取我們決策需要的信息；我們需要將搞定的“所有人”加工過的信息拼湊起來，才能勉強窺得信息的全貌。
理想場景和現實場景總是有所出入：
項目管理
項目推進流程：
在最理想的狀況下，我們按周推進需求，會有各種不可抗力導致需要插入需求。
最理想的項目推進場景，產品團隊規劃好需求後，協調資源推進需求，按時交付。
（實際推進項目時，資源和任務之間的聯繫更加複雜，為了便於對比，予以簡化）
總有多種多樣的原因導致我們的項目無法按時交付：
場景一：項目外部
最高頻的場景是因外力（外部政策如ios平臺、TX、政府 or 內部高層行政命令）等原因導致的需求插入&變更，使得原有項目無法按時交付。
場景二：項目內部
偶發場景是某塊資源的負責人因故（突發生病、離職等）無法按時交付原定的子任務，這時需要重新協調項目資源達成目標。
項目管理問題總結
在真實場景下，需求的變更往往會在資源分配層面構成蝴蝶效應，牽一髮而動全身，現有的手段和工具只能讓我們的項目相對透明，卻沒辦法幫我們管理項目的風險。
團隊現階段使用的信息同步工具：
異常流程導致的資源二次分配，成本較高：
二次分配的成本往往比初次分配高，需要全盤權衡正在推進項目的優先級，還要兼顧現有的項目推進情況、資源狀況。
項目風險管理困難：
在做二次決策的場景下，往往要求決策者在極短的時間內，做出一個低容錯率的決策。這要求決策者對業務預期、資源分佈、現有實現邏輯有全面瞭解。但作為項目的執行者，由於信息獲取的成本較高，執行時往往很難在短時間內看到項目的全貌，這為項目的交付時間和質量埋下隱患。（理想場景下應該有高一個層級的人來做這一類型的決策；但現實場景下，項目風險往往都由執行者承擔）
分析問題
抽象問題
無論是團隊內部的信息同步、項目管理，亦或是對外的跨線合作，基於以上背景，筆者認為導致協作效率低的核心原因集中在三方面：
獲取信息的成本高：我們往往先“搞定人”才能“搞定事”。
整合信息的成本高：我們需要將各個職能“加工”過的信息（每個人管理信息的習慣和水平都有所不同）拼湊起來，才能一窺需求全貌。
信息流失的風險高：想想那些離職的前輩們留下的“祖傳代碼”和“祖傳PRD”，咱也不知道，咱也不敢問。
原因分析
獲取信息成本高的原因：
職業分工垂直，不同職能間有信息鴻溝：同理心彌補不了專業上的信息差，和傳統行業相比，互聯網的專業分工縱深更深。
依賴個人的信息管理能力及溝通能力：人非聖賢，人一定會出錯。在中小型團隊中，產品寫PRD、繪製原型的習慣不同；開發寫代碼的習慣也不同；很多公司的設計師沒有統一的設計規範。依賴個人管理的信息一定會流失，這是可預期的。
流程的設置往往具備滯後性：和傳統行業相比，互聯網的拓張速度是無可比擬的，帶來的問題是上升期的互聯網公司往往無暇顧及管理，即使制訂了流程也遠遠趕不上團隊和業務拓張的速度。（見過部分公司將“0管理”和“扁平管理”劃等號）
整合信息成本高的原因：
儲存信息的節點分散（儲存在個人的知識庫中）。
信息總量邊界不明，當做一個決策時，從初步假設到最終決策，往往隨著接觸到的人，獲取到各式各樣被主觀“加工”過的信息，甚至在同一個問題上不同的人會給出完全相反，或模稜兩可的結論。（筆者本身經驗尚淺有關，理論上隨著經驗增加，對信息有效性的判斷會更加客觀）。
"據不完全統計，筆者在工作中約60%以上的時間用於溝通協調。當團隊中理應提供洞察，為產品指明道路的產品經理們深陷「體力協作」的低效率泥潭時，產品經理在自身價值感變得稀薄的同時，產品的市場表現也將趨向平庸。是否有辦法跳出低效循環？如果你也在被類似問題困擾，歡迎進來聊聊。
本問的本質是一篇「求助文」，筆者將為大家介紹自身在工作中碰到的問題及問題發生的背景，及原因的剖析，希望在給大家帶來啟發的同時，也可以收集到大家的意見，為解決問題提供新的可能性。
問題發生的背景
筆者在一家K12教育公司做產品（小學業務），主業務是2019年比較熱的在線教育班課，具有重運營，強KPI導向的特徵。筆者從冷啟動階段加入產品團隊，陪伴產品進入成長期，目前在業務上做大量嘗試，產品迭代頻率高，業務拓張速度快，很多問題亦隨之出現。
業務組織背景
每條業務線都是一個敏捷團隊，有著自己的核心指標及迭代節奏。
在公司層面，這種業務架構的優勢是線內效率足夠高，業務響應速度快，靈活度較高；缺點是跨線協作成本極高，各業務線之間訴求不一致，信息孤島效應明顯。
團隊背景
「產品+研發+設計+數據+運營」是敏捷團隊標配；筆者所處的產品團隊3人，產品及研發比例穩定維持在1：6，隨著業務發展，影響效率的明顯變量：
1. 團隊：業務人員數量激增
半年內，業務團隊從30人拓張至150人+，意味著產品需要在業務人員的效能上提供支持。
2. 業務：業務模型尚未調整至最優，需頻繁做嘗試
高頻率的實驗對團隊的整體信息管理提出更高要求，大量的投放AB對照實驗，產品每個迭代此類業務需求佔需求總量的70%。
問題發生的場景
團隊內&外日常協作
場景一：插入需求
Boss：今天戰略組給了最新信息，出臺了新政策XXX，我們需要在這個迭代內上線XX，你別用這種眼神看著我，沒錯，就走插入需求~
我：我手上優先級次高的需求是XXX和XXX，如果是我來推進，大概率會替換掉這兩個需求。但我知道Tony（其他PM）手上的需求這期排的不是很滿（甩鍋+1），不如咱們拉產品組討論下？
Boss：好的，你來拉會，我今天下午4點之後和明天上午10點有時間
我：（拉起產研會議）省略1W字，強行達成共識，確定了插入需求的負責人和置換掉的項目
插入評審會議：開發負責人生無可戀的參會，同步了本迭代項目的推進狀況，和產品明確了項目優先級後，重新分配了開發資源（產品組威信-100）
場景二：內部日常溝通
BI：咱們的這個流量入口，現在是按照什麼判斷條件，什麼流量比例分發流量？總共有幾個實驗組？
我：我上週做了一期，是按XX條件，XX比例分發，總共XX組。不確定實驗組的總量，我印象中上個迭代是呆呆（其他PM）在負責這部分邏輯。
BI：上週是泡泡（其他BI）在負責這個項目，我問過她，她說上週封版後XX（產品老大）走了一個插入需求，加了一個分發邏輯
我：這種不可見的邏輯最頭疼了，我問下老大和呆呆
釘釘拉群：（產品未能達成共識，拉入了負責的開發和BI，最終拼湊出了原需求的全貌）
場景三：跨線協作
我：hey，我們有這樣一個需求blahblah，我們希望的時間點是blahblah
接口人：嗯，這個需求實現需要和我們的開發確認，設計需要和我們的UI確認，有數據預期嗎？最好和BI也說一下。
我：排期目前確認不了嗎？
接口人：最近排期比較滿，我建議先把兩邊的相關人員拉個會吧。
我：（拉起會議）咦，你們的開發負責人呢？
接口人：他今天請假啦，咱們先對接信息吧，明天我幫你你單約下負責人
我：（對接了部分信息，會議結束，由於信息缺失並未達成共識）
-隔天，帶著我線的開發負責人約到了開發負責人
我：您好，想必XXX（接口人）已經給您介紹過背景了
負責人：沒有，你幫我簡單介紹下吧
我：blahblah，您看可以進排期嗎？
負責人：額，這個需要和XXX（另一條線的某研發負責人）確認，確實對他們有依賴，下週咱們找時間開個會吧。
我：（本月第X次燃起離職念頭）
日常協作問題總結
不論項目內外，能看到的共性問題是我們必須先“搞定人”才能獲取我們決策需要的信息；我們需要將搞定的“所有人”加工過的信息拼湊起來，才能勉強窺得信息的全貌。
理想場景和現實場景總是有所出入：
項目管理
項目推進流程：
在最理想的狀況下，我們按周推進需求，會有各種不可抗力導致需要插入需求。
最理想的項目推進場景，產品團隊規劃好需求後，協調資源推進需求，按時交付。
（實際推進項目時，資源和任務之間的聯繫更加複雜，為了便於對比，予以簡化）
總有多種多樣的原因導致我們的項目無法按時交付：
場景一：項目外部
最高頻的場景是因外力（外部政策如ios平臺、TX、政府 or 內部高層行政命令）等原因導致的需求插入&變更，使得原有項目無法按時交付。
場景二：項目內部
偶發場景是某塊資源的負責人因故（突發生病、離職等）無法按時交付原定的子任務，這時需要重新協調項目資源達成目標。
項目管理問題總結
在真實場景下，需求的變更往往會在資源分配層面構成蝴蝶效應，牽一髮而動全身，現有的手段和工具只能讓我們的項目相對透明，卻沒辦法幫我們管理項目的風險。
團隊現階段使用的信息同步工具：
異常流程導致的資源二次分配，成本較高：
二次分配的成本往往比初次分配高，需要全盤權衡正在推進項目的優先級，還要兼顧現有的項目推進情況、資源狀況。
項目風險管理困難：
在做二次決策的場景下，往往要求決策者在極短的時間內，做出一個低容錯率的決策。這要求決策者對業務預期、資源分佈、現有實現邏輯有全面瞭解。但作為項目的執行者，由於信息獲取的成本較高，執行時往往很難在短時間內看到項目的全貌，這為項目的交付時間和質量埋下隱患。（理想場景下應該有高一個層級的人來做這一類型的決策；但現實場景下，項目風險往往都由執行者承擔）
分析問題
抽象問題
無論是團隊內部的信息同步、項目管理，亦或是對外的跨線合作，基於以上背景，筆者認為導致協作效率低的核心原因集中在三方面：
獲取信息的成本高：我們往往先“搞定人”才能“搞定事”。
整合信息的成本高：我們需要將各個職能“加工”過的信息（每個人管理信息的習慣和水平都有所不同）拼湊起來，才能一窺需求全貌。
信息流失的風險高：想想那些離職的前輩們留下的“祖傳代碼”和“祖傳PRD”，咱也不知道，咱也不敢問。
原因分析
獲取信息成本高的原因：
職業分工垂直，不同職能間有信息鴻溝：同理心彌補不了專業上的信息差，和傳統行業相比，互聯網的專業分工縱深更深。
依賴個人的信息管理能力及溝通能力：人非聖賢，人一定會出錯。在中小型團隊中，產品寫PRD、繪製原型的習慣不同；開發寫代碼的習慣也不同；很多公司的設計師沒有統一的設計規範。依賴個人管理的信息一定會流失，這是可預期的。
流程的設置往往具備滯後性：和傳統行業相比，互聯網的拓張速度是無可比擬的，帶來的問題是上升期的互聯網公司往往無暇顧及管理，即使制訂了流程也遠遠趕不上團隊和業務拓張的速度。（見過部分公司將“0管理”和“扁平管理”劃等號）
整合信息成本高的原因：
儲存信息的節點分散（儲存在個人的知識庫中）。
信息總量邊界不明，當做一個決策時，從初步假設到最終決策，往往隨著接觸到的人，獲取到各式各樣被主觀“加工”過的信息，甚至在同一個問題上不同的人會給出完全相反，或模稜兩可的結論。（筆者本身經驗尚淺有關，理論上隨著經驗增加，對信息有效性的判斷會更加客觀）。
拋磚引玉
基於以上背景，相信你對我在工作的各個場景下碰到的問題已經有所瞭解。“如何降低信息獲取&整合的成本？如何降低信息流失的風險？”截至發文日，仍然沒能找到可落地的解法。
產品經理雖然是理論上的“腦力勞動者”，但“體力協作”卻佔據了我們60%以上的工作時間，我們距離真正的“腦力協作”還有很遠的路要走。
大量瑣碎的項目管理，溝通推進將我們的工作時間和價值感一起碎片化。
每日三省吾身：“項目能否按時交付乎？決策質量是否提高乎？懂用戶乎？”
我能勉強回答第一個問題，但第二個和第三個問題卻日夜煎熬著我，難以安眠。
不論你是和我一樣的小白新人，還是項目經驗豐富的前輩，如果我拋出的問題也同樣困擾著你和你的團隊，那麼請和我坐下聊一聊，相信我們有機會解決這個行業問題。
本文由 @ 大北 原創首發於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議
"