產品死亡原因：負擔過載

01-27

講成功的太多了，講有用的也太多了，這次，我來講講沒用的，同時也講講失敗。

什麼是負擔過載

萬物皆有其承載上限，即便是無底洞，也不是真正的無底，他的深度無法超過地球的直徑。

這些上限，很清晰的在我們工作生活中，也許並不是那麼的引入矚目。

Android可允許調用的方法上限為65536
千年蟲事件（指計算機處理的日期上限，也叫計算機2000年問題，指由於年份使用的是兩位十進位數來表達，無法處理跨世紀日期處理，進而引發各種各樣的功能紊亂，系統故障）
1970起始年事件（與千年蟲類似，指一些程序日期在1970之前，會導致系統紊亂。PS：現在你知道為什麼許多產品，生日都會在1970年以上了吧）

當我們所做的事情，超過了固定的上限時，便會出現負擔過載，進而引發一系列的問題，在這些問題當中就包含了「死亡」。

這在我們的產品里是相同的。

當我看到一個1.0的產品異常簡單時，總是會有一種莫名的認同感，1.0真的不需要太多。

實際上，不只是1.0，在我們每次進行版本迭代時，都不需要太多的功能。

不是因為我們偷懶，也不是因為開發成本。

同時開放過多的功能，也會造成用戶的負擔過載。

負擔過載導致死亡的原因

這是我寫的第一篇講死亡的，負擔過載大概是最高頻，但卻最隱秘的死亡原因。

很多創業朋友在失敗後，通常會去找團隊，找資金，找市場的原因，但卻很少提到負擔過載。

為什麼負擔過載會導致死亡呢？

有寬度，沒深度

我們要堆功能很容易，但要做有深度的功能卻很難，負擔過載的情況下，我們會盲目的去做許多的功能，可每一個功能的思考深度都是缺少的，甚至我們自己都不清楚為什麼要做某個功能。

負擔過載第一個影響的便是產品經理的思維，太多的需求，以至於我們沒有時間去深思熟慮。

功能都是相同的，但不同的用法卻取決於我們如何應用相同的功能，寬度是指我們的功能量多，深度卻是指我們的應用方法巧妙且有效。

1 天的時間，我們可以堆出數十個功能，也可以只輸出 1 個功能，但通過位置，應用方法，文案讓這個功能劇本更有效的深度，更符合人性。

功能不會符合人性，符合人性的只有我們的應用方法。

盲目開發，資源分散

現在許多創業團隊其實都不是在做技術創新，真正的做技術創新，技術創業的團隊非常的少，我們已經進入了應用創新時代。

也就是說，我們的功能是大同小異的，於應用創新而言，我們的開發成本已然降到了最低。1.0階段，其實大部分的功能，2年左右的研發都能夠完成，其實初創團隊並不需要尋找技術大牛，許多的技術大牛，做著普通的事情，唯一不普通的只是事情的數量

我提倡的是「從容不迫」的開發狀態，顯然，這並不那麼容易實現，因為影響研發工作量的，恰恰是我們產品經理。

一旦產品經理產生了負擔過載的現象，研發就會出現功能量過載的問題，再優秀的技術大牛，面對誇張的負擔過載，也只有將大部分的精力分散到完全無關的功能當中。

盲目開發，恰恰是許多產品沒有核心功能的原因，過多的研發資源投入到了極為普通的應用功能當中，無法打造更新的，更具備深度的，更個性化的功能。

匆忙運營，開花不結果

許多創業團隊，不是因為項目不好，而是被自己拖死的，我們已經知道了負擔過載對產品經理，對研發的致死因素，可負擔過載的影響遠遠超過我們的預測，它對我們的運營階段來講，也同樣是一種看不見的致死病毒。

過載負擔的結果往往意味著產品的某個版本同時上線了多個功能，典型的重災區在我們的1.0階段。

我需要強調，運營和產品是兩條並行的線，彼此合作，彼此借力，而由產品部分引發的負擔過載，會成倍數的增加運營的負擔，以至於開花不結果。

我們在運營時，往往需要藉助運營點，這需要產品提供一些可被運營的媒介，然而，當出現多個運營點時，並且每一個點都是一個所謂的亮點所謂的核心時，運營體系便會走向崩潰。

我時常和朋友提到，運營比產品更加刺激，在我們努力開發出一個版本時，運營可能已經做完了三到四個運營事件，儘管我是產品經理，但我非常的尊敬運營體系的朋友，他們的注意力需要非常的專註，才能有效的控制一次運營事件。

我們的市場並沒有留下足夠的時間，讓運營像產品一樣深思熟慮，也正因為如此，運營的多任務並行難度遠超過產品，畢竟我們還有相對充足的時間去糾正，去修改，比如需求變更。

當我們交付給運營的產物出現過載時，如果沒有被運營主觀上的減少運營點,那基本可以預測未來的運營階段必然是混亂的。

我已經提到了在運營事件當中，運營朋友對這個事件的專註度要求非常高，一個獨立且完整的運營事件，包括運營策略，前期準備，事件開展，過程式控制制，轉化策略，數據分析，復盤等多個環節，而這些都會集中在一個星期以內完成。

在這樣的環境下，同時並行兩個以上的運營點，會直接影響運營的過程，這也是為什麼許多從事運營行業2-3年的朋友，對運營的了解尚顯簡陋的原因。

負擔過載的情況下，我們無法專註的做好一件事情，自然無法窺視到一件事情所經歷的各個階段，也自然無法將結果調整到最好。

我們總是在來回切，就像切一些自己不喜歡的歌曲，很多時候，事情剛剛開始，就已經結束了，畢竟還有那麼多的運營點沒有被運營。

當我們的源頭，產品經理出現負擔過載時，我們的運營基本上就可以預判後期的工作節奏以及成果了。

當然，多數情況下，會是只開花，不結果

人多也是一種負擔

我們有時候會近乎偏執的相信自己是正確的，比如，負擔過載的上述 3 個結果，我們都可以歸結到人數上，那我們招人就可以了，增加人手就可以了。

這是對的，但也正因為他是正確的，所以我們離死亡更進一步

1000人以上的企業，與10人的企業，他的複雜度不一樣，他的風險不一樣這個我們是一目了然的，但大部分的時間，我們並沒有意識到 2 個人和 3 個人也是不一樣的。

當我們決定增加團隊時，負擔過載最大的致死因素就開始發生作用了，需求的負擔過載變成了任務過載，現在，他變成了人員過載。

並不是把人放在一起就是一個團隊，不考慮招人成本情況下，我們來看看已經招到人以後產生的致死因素。

新成員融入風險

新成員融入團隊是伴隨著雙向風險的，其中，對團隊而言，新成員的思想會對我們產生衝擊，我們會消耗更多的時間在於新成員的溝通上。

當已經出現負擔過載的情況時，再招人不但不能立即幫我們分擔，降低負擔，反而會為我們增加更多的負擔，讓這種負擔過載的情況變得更為嚴峻。

原本，我們加班能完成的事情，引入新成員以後，不僅僅仍然要加班，而且現在加班也做不完了。

團隊向心力的衝擊

當我們一個人自己做一件事情時，毫無疑問，我們是一心一意的，當我們兩人一起做事時，我們尚且能做到彼此尊重，互相理解。

而這層脆弱的向心力，隨著人數的增加，會逐漸崩壞，我們很難通過人與人的溝通來產生企業文化，更多的需要由規範，原則，無數次的事件來形成企業文化。

而當新成員進入一個團隊時，必然會對團隊向心力產生衝擊，並且，這往往和我們引入的人才能力成正比，越優秀的人才，對我們的向心力衝擊越大。

這是有原因的:

有經驗的人才，往往由於自己所經歷過的環境，形成了自己判斷事情的標準，我們的技能雖然比較專業，但同樣的，我們的可塑性是比較薄弱的。
我們很難找到與自己想法完全相同的人，儘管這樣的人確實存在，但我們所能接觸到的人，相對於所有人來講，實在是太少了。

最後的結果是什麼呢？我們找了更多的人，但他們並不是來幫我們解決問題的，這很殘酷，但也很現實。

我相信，不論對於招聘者，還是對於應聘者，我們都希望能很好的協作，我也相信，我們都想要幫對方解決問題，都不是來找茬的。

但我們卻忽略了，人數，也是負擔過載的一種結果。

我們迎來了更多的爭執，我們在討論上花的時間越來越多，我們的需求也越來越多，負擔過載不但沒有被降低，反而越來越多，在結果到來之前，我們便早早預測到了結果，但卻無能為力，除非我們能夠學會控制自己，減少負擔。

建議

我們既然已經提到了負擔過載是死亡原因之一，我想給大家一些建議，但文章中不準備展開描述了。有機會的話我會單獨再寫一篇詳細闡述如何避免負擔過載。

最有效的辦法，減少需求量

產品經理是負擔過載的源頭，如果我們能控制需求量，這將會對規避負擔過載有重大價值。在我的習慣里，一個大版本是由固定的節奏的，比如他會包含 1 個運營點，1 個功能模塊，諸多的細節調整。

砍需求，比新增需求更專業

砍需求，恰恰是專業的一種表現方式，只有我們充分的認識需求，能夠判斷需求的價值，能夠進行需求對比，和選擇，我們才能砍需求，而不是指隨意任性的砍需求。

你能做的，真的沒有那麼多

小龍哥如果將微信的源代碼送給你，你能再做一個微信出來嗎？

其實我們能做的事情，並不多，許多時候，即便是把功能做出來了，並且做的和別人一模一樣了，也不見得我們真的能應用這個功能。支付寶，花了許多時間，許多成本才明白他真的做不了社交。（傳言支付寶經過三個月的討論，決定放棄社交）。

我們真的不那麼強大，能做的事情，真的很少。

勿以世界為敵，做我們能做的事情，把他做好。