產品死亡原因之「負擔超載」
講成功的太多了，講有用的也太多了，這次，我來講講沒用的，同時也講講失敗。
什麼是負擔超載
萬物皆有其承載上限，即便是無底洞，也不是真正的無底，他的深度無法超過地球的直徑。
這些上限，很清晰的在我們工作生活中，也許並不是那麼的引入矚目。
Android可允許調用的方法上限為65536千年蟲事件（指電腦處理的日期上限，也叫電腦2000年問題，指由於年份使用的是兩位十進位數字來表達，無法處理跨世紀日期處理，進而引發各種各樣的功能紊亂，當我們所做的事情，超過了固定的上限時，便會出現負擔超載，進而引發一系列的問題，在這些問題當中就包含了“死亡”。
這在我們的產品裡是相同的。
當我看到一個1.0的產品異常簡單時，總是會有一種莫名的認同感，1.0真的不需要太多。
實際上，不只是1.0，在我們每次進行版本反覆運算時，都不需要太多的功能。
不是因為我們偷懶，也不是因為開發成本。
同時開放過多的功能，也會造成用戶的負擔超載。
負擔超載導致死亡的原因
這是我寫的第一篇講死亡的，負擔超載大概是最高頻，但卻最隱秘的死亡原因。
很多創業朋友在失敗後，通常會去找團隊，找資金，找市場的原因，但卻很少提到負擔超載。
為什麼負擔超載會導致死亡呢？
有寬度 ，沒深度
我們要堆功能很容易，但要做有深度的功能卻很難， 負擔超載的情況下，我們會盲目的去做許多的功能，可每一個功能的思考深度都是缺少的，甚至我們自己都不清楚為什麼要做某個功能。
負擔超載第一個影響的便是產品經理的思維，太多的需求，以至於我們沒有時間去深思熟慮。
功能都是相同的，但不同的用法卻取決於我們如何應用相同的功能，
1 天的時間，我們可以堆出數十個功能，也可以只輸出 1 個功能，但通過位置，應用方法，文案讓這個功能劇本更有效的深度，更符合人性。
功能不會符合人性，符合人性的只有我們的應用方法。
盲目開發，資源分散
現在許多創業團隊其實都不是在做技術創新，真正的做技術創新，
也就是說，我們的功能是大同小異的，于應用創新而言，我們的開發成本已然降到了最低。1.0階段，其實大部分的功能，2年左右的研發都能夠完成，其實初創團隊並不需要尋找技術大牛，許多的技術大牛，做著普通的事情，唯一不普通的只是事情的數量
我提倡的是“從容不迫”的開發狀態，顯然，這並不那麼容易實現，因為影響研發工作量的，恰恰是我們產品經理。
一旦產品經理產生了負擔超載的現象，研發就會出現功能量超載的問題，再優秀的技術大牛，面對誇張的負擔超載，也只有將大部分的精力分散到完全無關的功能當中。
盲目開發，恰恰是許多產品沒有核心功能的原因，過多的研發資源投入到了極為普通的應用功能當中，無法打造更新的，更具備深度的，更個性化的功能。
匆忙運營，開花不結果
許多創業團隊，不是因為項目不好，而是被自己拖死的，我們已經知道了負擔超載對產品經理，對研發的致死因素，可負擔超載的影響遠遠超過我們的預測，它對我們的運營階段來講，也同樣是一種看不見的致死病毒。
超載負擔的結果往往意味著產品的某個版本 同時上線了多個功能，典型的重災區在我們的1.0階段。
我需要強調，運營和產品是兩條並行的線，彼此合作，彼此借力，而由產品部分引發的負擔超載，會成倍數的增加運營的負擔，以至於開花不結果。
我們在運營時，往往需要借助運營點，這需要產品提供一些可被運營的媒介，然而，當出現多個運營點時，並且每一個點都是一個所謂的亮點所謂的核心時，運營體系便會走向崩潰。
我時常和朋友提到，運營比產品更加刺激，在我們努力開發出一個版本時，運營可能已經做完了三到四個運營事件，儘管我是產品經理，但我非常的尊敬運營體系的朋友，他們的注意力需要非常的專注，才能有效的控制一次運營事件。
我們的市場並沒有留下足夠的時間，讓運營像產品一樣深思熟慮，也正因為如此，運營的多工並行難度遠超過產品，畢竟我們還有相對充足的時間去糾正，去修改，比如需求變更。
當我們交付給運營的產物出現超載時，如果沒有被運營主觀上的減少運營點,那基本可以預測未來的運營階段必然是混亂的。
我已經提到了在運營事件當中，運營朋友對這個事件的專注度要求非常高，一個獨立且完整的運營事件，包括運營策略，前期準備，事件開展，程序控制，轉化策略，資料分析，複盤 等多個環節，而這些都會集中在一個星期以內完成。
在這樣的環境下，同時並行兩個以上的運營點，會直接影響運營的過程，這也是為什麼許多從事運營行業2-3年的朋友，對運營的瞭解尚顯簡陋的原因。
負擔超載的情況下，我們無法專注的做好一件事情，自然無法窺視到一件事情所經歷的各個階段，也自然無法將結果調整到最好。
我們總是在來回切，就像切一些自己不喜歡的歌曲，很多時候，事情剛剛開始，就已經結束了，畢竟還有那麼多的運營點沒有被運營。
當我們的源頭，產品經理出現負擔超載時，我們的運營基本上就可以預判後期的工作節奏以及成果了。
當然，多數情況下，會是只開花，不結果
人多也是一種負擔
我們有時候會近乎偏執的相信自己是正確的，比如，負擔超載的上述 3 個結果，我們都可以歸結到人數上，那我們招人就可以了，增加人手就可以了。
這是對的，但也正因為他是正確的，所以我們離死亡更進一步
1000人以上的企業，與10人的企業，他的複雜度不一樣，他的風險不一樣這個我們是一目了然的，但大部分的時間，我們並沒有意識到 2 個人和 3 個人也是不一樣的。
當我們決定增加團隊時，負擔超載最大的致死因素就開始發生作用了，需求的負擔超載變成了任務超載，現在，他變成了人員超載。
並不是把人放在一起就是一個團隊，不考慮招人成本情況下，我們來看看已經招到人以後產生的致死因素。
新成員融入風險
新成員融入團隊是伴隨著雙向風險的，其中，對團隊而言，新成員的思想會對我們產生衝擊，我們會消耗更多的時間在於新成員的溝通上。
當已經出現負擔超載的情況時，再招人不但不能立即幫我們分擔，降低負擔，反而會為我們增加更多的負擔，讓這種負擔超載的情況變得更為嚴峻。
原本，我們加班能完成的事情，引入新成員以後，不僅僅仍然要加班，而且現在加班也做不完了。
團隊向心力的衝擊
當我們一個人自己做一件事情時，毫無疑問，我們是一心一意的，當我們兩人一起做事時，我們尚且能做到彼此尊重，互相理解。
而這層脆弱的向心力，隨著人數的增加，會逐漸崩壞，我們很難通過人與人的溝通來產生企業文化，更多的需要由規範，原則，無數次的事件來形成企業文化。
而當新成員進入一個團隊時，必然會對團隊向心力產生衝擊，並且，這往往和我們引入的人才能力成正比，越優秀的人才，對我們的向心力衝擊越大。
這是有原因的:
有經驗的人才，往往由於自己所經歷過的環境，形成了自己判斷事情的標準，我們的技能雖然比較專業，但同樣的，我們的可塑性是比較薄弱的。我們很難找到與自己想法完全相同的人， 儘管這樣的人確實存在，但我們所能接觸到的人，相對於所有人來講，實在是太少了。最後的結果是什麼呢？我們找了更多的人，但他們並不是來幫我們解決問題的，這很殘酷，但也很現實。
我相信，不論對於招聘者，還是對於應聘者，我們都希望能很好的協作，我也相信，我們都想要幫對方解決問題，都不是來找茬的。
但我們卻忽略了，人數，也是負擔超載的一種結果。
我們迎來了更多的爭執，我們在討論上花的時間越來越多，我們的需求也越來越多，負擔超載不但沒有被降低，反而越來越多，在結果到來之前，我們便早早預測到了結果，但卻無能為力，除非我們能夠學會控制自己，減少負擔。
建議
我們既然已經提到了負擔超載是死亡原因之一，我想給大家一些建議，但文章中不準備展開描述了。有機會的話我會單獨再寫一篇詳細闡述如何避免負擔超載。
最有效的辦法，減少需求量
產品經理是負擔超載的源頭，如果我們能控制需求量，這將會對規避負擔超載有重大價值。在我的習慣裡，一個大版本是由固定的節奏的，比如 他會包含 1 個運營點，1 個功能模組，諸多的細節調整。
砍需求，比新增需求更專業
砍需求，恰恰是專業的一種表現方式，只有我們充分的認識需求，能夠判斷需求的價值，能夠進行需求對比，和選擇，我們才能砍需求，而不是指隨意任性的砍需求。
你能做的，真的沒有那麼多
其實我們能做的事情，並不多，許多時候，即便是把功能做出來了，並且做的和別人一模一樣了，也不見得我們真的能應用這個功能。支付寶，花了許多時間，許多成本才明白他真的做不了社交。（傳言支付寶經過三個月的討論，決定放棄社交）。
我們真的不那麼強大， 能做的事情，真的很少。
勿以世界為敵，做我們能做的事情，把他做好。
#專欄作家#
本文原創發佈于人人都是產品經理。未經許可，禁止轉載。
恰恰是我們產品經理。一旦產品經理產生了負擔超載的現象，研發就會出現功能量超載的問題，再優秀的技術大牛，面對誇張的負擔超載，也只有將大部分的精力分散到完全無關的功能當中。
盲目開發，恰恰是許多產品沒有核心功能的原因，過多的研發資源投入到了極為普通的應用功能當中，無法打造更新的，更具備深度的，更個性化的功能。
匆忙運營，開花不結果
許多創業團隊，不是因為項目不好，而是被自己拖死的，我們已經知道了負擔超載對產品經理，對研發的致死因素，可負擔超載的影響遠遠超過我們的預測，它對我們的運營階段來講，也同樣是一種看不見的致死病毒。
超載負擔的結果往往意味著產品的某個版本 同時上線了多個功能，典型的重災區在我們的1.0階段。
我需要強調，運營和產品是兩條並行的線，彼此合作，彼此借力，而由產品部分引發的負擔超載，會成倍數的增加運營的負擔，以至於開花不結果。
我們在運營時，往往需要借助運營點，這需要產品提供一些可被運營的媒介，然而，當出現多個運營點時，並且每一個點都是一個所謂的亮點所謂的核心時，運營體系便會走向崩潰。
我時常和朋友提到，運營比產品更加刺激，在我們努力開發出一個版本時，運營可能已經做完了三到四個運營事件，儘管我是產品經理，但我非常的尊敬運營體系的朋友，他們的注意力需要非常的專注，才能有效的控制一次運營事件。
我們的市場並沒有留下足夠的時間，讓運營像產品一樣深思熟慮，也正因為如此，運營的多工並行難度遠超過產品，畢竟我們還有相對充足的時間去糾正，去修改，比如需求變更。
當我們交付給運營的產物出現超載時，如果沒有被運營主觀上的減少運營點,那基本可以預測未來的運營階段必然是混亂的。
我已經提到了在運營事件當中，運營朋友對這個事件的專注度要求非常高，一個獨立且完整的運營事件，包括運營策略，前期準備，事件開展，程序控制，轉化策略，資料分析，複盤 等多個環節，而這些都會集中在一個星期以內完成。
在這樣的環境下，同時並行兩個以上的運營點，會直接影響運營的過程，這也是為什麼許多從事運營行業2-3年的朋友，對運營的瞭解尚顯簡陋的原因。
負擔超載的情況下，我們無法專注的做好一件事情，自然無法窺視到一件事情所經歷的各個階段，也自然無法將結果調整到最好。
我們總是在來回切，就像切一些自己不喜歡的歌曲，很多時候，事情剛剛開始，就已經結束了，畢竟還有那麼多的運營點沒有被運營。
當我們的源頭，產品經理出現負擔超載時，我們的運營基本上就可以預判後期的工作節奏以及成果了。
當然，多數情況下，會是只開花，不結果
人多也是一種負擔
我們有時候會近乎偏執的相信自己是正確的，比如，負擔超載的上述 3 個結果，我們都可以歸結到人數上，那我們招人就可以了，增加人手就可以了。
這是對的，但也正因為他是正確的，所以我們離死亡更進一步
1000人以上的企業，與10人的企業，他的複雜度不一樣，他的風險不一樣這個我們是一目了然的，但大部分的時間，我們並沒有意識到 2 個人和 3 個人也是不一樣的。
當我們決定增加團隊時，負擔超載最大的致死因素就開始發生作用了，需求的負擔超載變成了任務超載，現在，他變成了人員超載。
並不是把人放在一起就是一個團隊，不考慮招人成本情況下，我們來看看已經招到人以後產生的致死因素。
新成員融入風險
新成員融入團隊是伴隨著雙向風險的，其中，對團隊而言，新成員的思想會對我們產生衝擊，我們會消耗更多的時間在於新成員的溝通上。
當已經出現負擔超載的情況時，再招人不但不能立即幫我們分擔，降低負擔，反而會為我們增加更多的負擔，讓這種負擔超載的情況變得更為嚴峻。
原本，我們加班能完成的事情，引入新成員以後，不僅僅仍然要加班，而且現在加班也做不完了。
團隊向心力的衝擊
當我們一個人自己做一件事情時，毫無疑問，我們是一心一意的，當我們兩人一起做事時，我們尚且能做到彼此尊重，互相理解。
而這層脆弱的向心力，隨著人數的增加，會逐漸崩壞，我們很難通過人與人的溝通來產生企業文化，更多的需要由規範，原則，無數次的事件來形成企業文化。
而當新成員進入一個團隊時，必然會對團隊向心力產生衝擊，並且，這往往和我們引入的人才能力成正比，越優秀的人才，對我們的向心力衝擊越大。
這是有原因的:
有經驗的人才，往往由於自己所經歷過的環境，形成了自己判斷事情的標準，我們的技能雖然比較專業，但同樣的，我們的可塑性是比較薄弱的。我們很難找到與自己想法完全相同的人， 儘管這樣的人確實存在，但我們所能接觸到的人，相對於所有人來講，實在是太少了。最後的結果是什麼呢？我們找了更多的人，但他們並不是來幫我們解決問題的，這很殘酷，但也很現實。
我相信，不論對於招聘者，還是對於應聘者，我們都希望能很好的協作，我也相信，我們都想要幫對方解決問題，都不是來找茬的。
但我們卻忽略了，人數，也是負擔超載的一種結果。
我們迎來了更多的爭執，我們在討論上花的時間越來越多，我們的需求也越來越多，負擔超載不但沒有被降低，反而越來越多，在結果到來之前，我們便早早預測到了結果，但卻無能為力，除非我們能夠學會控制自己，減少負擔。
建議
我們既然已經提到了負擔超載是死亡原因之一，我想給大家一些建議，但文章中不準備展開描述了。有機會的話我會單獨再寫一篇詳細闡述如何避免負擔超載。
最有效的辦法，減少需求量
產品經理是負擔超載的源頭，如果我們能控制需求量，這將會對規避負擔超載有重大價值。在我的習慣裡，一個大版本是由固定的節奏的，比如 他會包含 1 個運營點，1 個功能模組，諸多的細節調整。
砍需求，比新增需求更專業
砍需求，恰恰是專業的一種表現方式，只有我們充分的認識需求，能夠判斷需求的價值，能夠進行需求對比，和選擇，我們才能砍需求，而不是指隨意任性的砍需求。
你能做的，真的沒有那麼多
其實我們能做的事情，並不多，許多時候，即便是把功能做出來了，並且做的和別人一模一樣了，也不見得我們真的能應用這個功能。支付寶，花了許多時間，許多成本才明白他真的做不了社交。（傳言支付寶經過三個月的討論，決定放棄社交）。
我們真的不那麼強大， 能做的事情，真的很少。
勿以世界為敵，做我們能做的事情，把他做好。
#專欄作家#
本文原創發佈于人人都是產品經理。未經許可，禁止轉載。