編輯導語：一個失敗的產品背後隱藏的原因有許多，本文將從產品現象為出發點，總結產品失敗的根本原因，推薦對此感興趣的朋友閱讀，一起來看看吧。

成功的產品遍地開發，失敗的產品更是野蠻生長，本文和大家一起聊聊失敗的產品有哪些因素。

一、文章前沿

每個成功的產品背後有著無數個角色的支撐，當然失敗的產品背後隱藏的事件並不比成功的少。

其中可能包含著領導層面的希望、有產品經理廢寢忘食想出的方案、有工程師沒日沒夜的敲出一行有一行的程式碼，還有設計師上線了不知改過幾稿的效果圖。

可是以我最近幾年做產品的經驗來看，

C端產品百分之80的產品都是不賺錢的。

做出一款成功的產品難，做出一款賺錢的產品更難，做出一款持續賺錢的產品難上加難！

近幾年大家都知道國家層面大力支援數字化轉型，從而來延伸出來很多B端軟體服務商，領導何嘗不知再從使用者身上賺錢變的非常苦難。

不如做軟體服務商，為各大企業和政務部門做定製化服務，只要合作一次基本就可以養活一段時間，也就出現了大眾級現象“半年不開張，開張吃一年”的說法。

後面又想從B端領域中延伸出SaaS服務，這樣既可以為大客戶提供定製化，又可以為小客戶提供按需求收費。

這種情況延伸至今，不知道大家有沒有想過這種模式如果也賺不錢了怎麼辦？

我也不知道，但是總會有人開闊新的路子，就像BI，元宇宙，又或者是Web3。0。

未知的先討論到這裡，文章接下來會告訴你這幾年來做產品失敗的一些原因，希望可以在你工作的過程有一絲的幫助。

二、產品現象

近幾年我拜訪過很多網際網路公司，團隊模式都差不多唯一不同的可能是著重點不一樣。

有的是——產品驅動，另一種則是——運營銷售驅動。

但一般來說銷售驅動產品的佔大多數。

當我詢問他們目前還存活產品時，為了避免企業銷聲匿跡都會舉例出一兩個，但是當我深入產品看的時候，大多也會以資料不足和還在最佳化中推辭掉。

有些公司做的是正式的商業模式，有些是非正式的。

但無論哪種方式無非都需要歸結到最後的三件事：

它會賺多少錢？

需要花費多少事件和金錢？

做成的機率有多大？

一旦一個想法排在首位，產品經理第一件要做的時間就是與利益者交談，充實這一想法並提出合適的“需求”。

一旦收集到需求，使用者體驗團隊（假如有這樣的團隊）自己來規劃產品方案，與領導層面來探討方案，接著與開發，設計溝通，然後再交付產品要求和規範交給工程師。

還有一種現象，有的公司在某一領域做的時間久了，會缺乏創新，即使創新，也會出現抱怨缺乏創新以及創意到客戶的手中需要很長的時間。

PM可能會認識到，雖然現在市面上都是跟隨敏捷開發，但實際的問題反而會出現更多。

我們要做的就是為企業連線這些點，本文的觀點會告訴你為什麼常見的工作方式，實際上是導致大多數失敗產品的根本原因。

1. 團隊構建的不同

其實在工作當中我們會發現很多有趣的事情，雖然產品經理加上來經理二字，

但是實際工作中有權利的人屈指可數，更多的是當需求的搬運工ing，角色之間的傳話筒。

公司當中有產品總監，技術總監，有的完善的還會有專案經理，呃這麼多角色，想找個背鍋的人都找不到，你會發現很多時間產品總監交代的產品交付和技術總監的想法是不一致的。

為什麼？因為他們的角色權重不一樣

，產品總監需要把產品變成錢，變成可持續利用的搖錢樹。

但技術總監就不一樣，他首先要考慮的是：技術難度和時間週期。

用大白話展示就是兩個角色“尿不到一壺”更別說專案經理。

建議：如果該公司是產品驅動，那就把全部的權利交給產品總監，不管是開發設計還是運營測試。

這樣有什麼好處？讓目的達成一致，讓各部門之間的協作更加無障礙。

2. 商業路線路

很多公司做了一段時間沒發現商業模式走的通，想要快速發現，我實際上贊成做成商業案例的。

因為如果需要融資這是非常好的路子，

但是這個路子就是有一種，那就是風險，好比賭博，你壓大還是壓小。

因為在這個階段誰也不知道會出現什麼情況，還是文章開頭的一個觀點在這個過程中，你會花多少錢，賺多少錢。

在這個階段我們對於這些可以說沒有任何線索。我們不知道我們能賺多少錢，因為這在很大程度上取決於解決方案的效果。

如果團隊做得很好，這可能會非常成功，並從字面上改變公司的發展方向。

另一方面，事實是許多產品創意最終一無所獲。這並不是誇大效果，字面上沒什麼。

無論如何，產品中最重要的一課就是知道我們不知道的東西，而在這個階段我們只是不知道我們會賺多少錢。

同樣，我們不知道建造成本是多少。在不知道實際解決方案的情況下，這對於工程來說是非常難以預測的。

大多數有經驗的工程師在這個階段甚至會拒絕給出估計，但有些人被迫採用舊的“T 恤尺寸”折中方案——

只要讓我們知道這是“小號、中號、大號和超大號”。

但是公司真的想要那些優先的路線圖，為了得到一個他們需要某種系統來評估這些想法，所以人們玩商業案例遊戲。

建議：在這個過程中，可以先增加試點，比如你是為零售行業做數字化支援的，發現手中已經有了一些忠實客戶，可以先詢問他們的意見，先讓一些客戶免費使用這些產品。

如果到時候真的可行那麼繼續延伸，如果不行也不會有什麼損失。

3. 產品經理的角色

這其實是一個和設計角色類似的故事，

為什麼在實際工作中其他部門會時常Diss你，對你的方案視而不見。

因為你在他們心目中並不能得到認可，一開始的不認可會讓你很難受，因為這些工作都需要他們來完成。

因為你看起來並不是那麼成功，說不定只是個紙上談兵的理想。

我憑什麼聽你的。比如領導下發來一個需求，讓你這周搞出來，你看了一眼手裡的方案，又看了看已經三天沒休息加班的同事，你於心不忍，但老闆並不領情。

你還是要去得罪人，到時候專案上線一堆BUG，效果圖難看至極，可是沒辦法，老闆讓上線。

最後毫無疑問產品失敗了，領導對你的印象又有了新的定義，

你說你會不會被辭退呢？大機率會。建議：詢問機制，當有新的需求產生時，先想幾個問題？

為什麼要做這個需求？

需求什麼難點？

完成這些我需要什麼資源？

事件開始錢必須要想清楚這些問題，盲目的開展必將失敗，如果你擔心覺得領導覺得你不專業，你可以先不管他，一定要把自己的方向弄清楚。

有需要你還可以不停的追問它，我想他不會說你很煩，即使有管他呢，我也是為了工作（這個觀點有風險，謹慎使用）機率在1：6吧。

希望你聽說過精益創業方法，這是替代方案的核心。

關鍵原則是減少浪費，最大的浪費形式之一是設計、構建、測試和部署一個功能或產品，結果卻發現它不是我們需要的。

具有諷刺意味的是，許多團隊認為他們正在應用精益原則。

但他們遵循我剛剛描述的這個基本過程。然後我向他們指出，他們實際上是在以我們所知道的最昂貴，最慢的方式之一來嘗試想法

。

三、寫在最後

我學到的關於產品的最重要的事情之一是，無論你多麼聰明，都無法逃避這些事實。

而且我有幸與許多真正出色的產品團隊合作。真正的區別在於你如何處理這些事實。

如果您的公司仍在執行這個陳舊且過時的流程，那麼希望您能對此有所瞭解並開始向未來過渡。

並且希望你能在你發現自己被一家能夠比你更快、更有效地行動的初創公司或競爭對手打亂之前做到這一點。

作者：王秀琴，微信公眾號：產品有個洞；智慧產品產業、SaaS企業高階產品總監

本文由 @王秀琴 原創釋出於人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。