在這篇文章中我想去討論許多產品失敗的根本原因。

我看到在絕大部分公司用的都是相同的基本工作方法，我不禁想提醒這和那些好公司的實際工作方法相去甚遠。

我不得不提醒你這討論出的結論可能會非常令人沮喪，甚至你覺得有點太打擊人，如果是這樣，我覺得你可以停在這里不必往下看了。

讓我們從絕大多數公司仍在用之創造產品的過程開始，我會試著不發表評論，我們僅是描述這個過程：

任何事情都始于想法。在大部分公司，想法來源于執行董事，或者關鍵的利益相關者，或者企業主，或者大客戶（或潛在客戶），但是任何情況下業務的不同部分都有一大堆事情需要去做。

現在大部分公司想要在路線圖中確定這些想法的優先順序，他們這樣做基于兩個理由。首先，他們想要我們優先專注于最有價值的事情，其次，他們想預測事情何時能準備好。

為了做到這一點，通常會有某種形式的季度或者年度計劃會議，會上領導就這些想法思考并協商出一個產品路線圖。但是為了確定優先順序，他們首先需要為每個項目提供某種形式的商業案例。

一些公司會形成正式的商業案例，一些則是非正式的，但不管是哪一種，歸根到底，關于每個想法都需要了解兩點：

1. 它將賺多少錢？
2. 它將花費多少時間或金錢？

然后用這些信息來提出下一個季度有時也可能是一年后的產品路線圖。

在這一點上，產品和技術部門有他們自己的工作節奏，通常是按照項目的優先順序，從最高優先級依次往下走。

一旦一個想法被確定為最高優先級，產品經理需要做的第一件事就是和項目利益干系人討論，將想法具體充實化，并提出一系列的“需求”。這有可能是用戶故事，也有可能是某種形式的功能細則，但目的都是為了和設計師以及工程師溝通需要創建的是什么。

一旦需求被收集起來，用戶體驗設計團隊（假設公司有這樣一個團隊），就需要提供交互設計，視覺設計，以及物理設備情況下的工業設計。

最后將需求以及設計細則交給工程師，這時敏捷開發最終登場。

無論如何，工程師通常會將項目劃分成一系列的迭代——在敏捷開發模型中這稱之為“sprints”。想法構建出來可能需要1-3次敏捷迭代。

很希望QA測試是這些敏捷迭代過程中的一部分，如果不是，QA團隊應該用其他的測試跟進，確保新產品和宣傳的一致，同時不會引進其他問題（稱之為“回歸”）。

一旦我們在QA團隊那拿到了綠燈，新想法可以最終部署給真實客戶了。

在我第一次見面的絕大多數公司，無論大小，重要的是他們的工作方式，并保持這樣的方式工作了很多年。但也同樣是這些公司，他們不斷抱怨著缺乏創新，從想法到落地需要非常長的時間。

你也許已經意識到，當我提及敏捷開發的同時，幾乎今天的每個人都宣稱是敏捷開發，而我剛剛描述其實更多的是瀑布過程。公平說來，對于工程師，如果他們能夠給更廣闊的瀑布環境，他們能做的其實和敏捷開發一樣多。

OK，既然大部分團隊都是敏捷開發，但為什么那是如此多問題的必要理由呢？

我現在想做的就是將這些點連接起來，向你展示為什么這種普通的工作方式要實際為大部分失敗的產品努力負責。

最嚴重的10條問題

關于這個問題我可以暢談一整天，但我即將分享的是我認為這種工作方式中，最嚴重的10條問題。更清楚一點，我所講的這十條都是非常嚴重的問題，其中任何一條都足以摧毀一個團隊，但大部分公司占了這十條中的大多數，甚至，全中。

1.讓我們從最上面那條開始——想法的來源。這種模式導致了銷售驅動特價，以及利益干系人驅動產品。想法的來源有很多，但是這不是我們產品想法的最佳來源。這種方式的另一個結果是團隊缺乏自主權——在這種模式中，他們只是在那兒執行，就像一個雇傭兵。

2.接下來我們談一談這種商務案例中的致命缺點。我實際是支持做商務案例的，至少對于想法需要一個更大的投資。但與此同時，大部分公司在這階段做商務案例，為了想出一個確定了優先順序的產品路線圖，確實是可笑的。為什么？還記得每個商務案例中兩項關鍵的投入是什么嗎？你會賺多少錢？它又會花費多少？冰冷的現實是，在這一階段，兩者我們都不會有答案，我們不可能知道。

我們不可能知道我們會賺多少錢，因為這很大程度上取決于我們的解決方法會變得有多好。如果團隊表現杰出，這可能會取得巨大的成功，的確有可能會改變公司的進程。另一方面，許多的產品想法會落得一場空。這并不是夸大其詞。確實是什么都沒有。任何情況下，產品中最重要的一課是明白——什么是我們不可能知道的，在這個階段我們不可能知道的是，我們能賺多少。

同樣地，我們也不可能知道構建出這個想法需要花費多少。在不知道實際解決方法的情況下，工程師是很難去預測的。在這個階段，大部分有經驗的工程師甚至會拒絕去給出一個估算，但有些工程師迫于壓力，只好作出老式“T恤size”式的妥協——僅僅讓我們知道這預算是“小的、中等的、大的還是特大的”。

但公司高層確實想得出確定了優先順序的產品路線圖，為了得到它，他們需要某種系統來評估想法，所以人們就玩起了商務案例的游戲。

3.一個更大的問題來了。公司對他們的產品路線圖感到十分興奮。我見過數不清的路線圖，絕大多數確實按照特征確定了優先順序。市場需要這些特征來搞商務活動，銷售需要這些特征來招徠新客戶。一些人則想要一個PayPal集合。你懂的。

但是這里有一個問題，也許是其中最大的問題，我把這稱之為“不愿面對的兩個產品真相”。

第一個真相是，我們的想法至少有一半是不能被實現。一個想法不能被實現有許多理由。最普遍的是，客戶不會如我們一樣對想法感到興奮。所以他們不會選擇去使用它。有時他們想去使用它，但是他們試過之后發現它是如此的復雜，麻煩遠大于它的價值，所以導致了同樣的結果——用戶不會選擇去使用它。有時問題是客戶很喜歡它，但要實現的東西遠超出我們的想象，我們并沒有足夠的時間和金錢來實際實現。

所以我向你保證，你的路線圖中至少有一半不會如你所愿實現。同時，真正好的產品團隊認為，至少有四分之三的想法的表現都會不盡人意。

如果這還不夠糟，第二個不愿面對的真相是，盡管這個想法被證明有潛力，它通常需要經過幾次迭代之后才能實現它的想法傳遞真實商業價值。我們稱之為 “時間就是金錢”。

我所學習到的關于產品最重要的一點是，無論你有多聰明，都逃不過這些真相。我曾有幸和許多杰出的產品團隊工作。真正的差別在于你如何處理這些真相。

4.接下來我們要談論的是這種模式下的產品角色。事實上，我們根本不用把這個角色稱之為產品。它實際上只是一種項目管理的形式。在這種模式下，它更多的是收集需求并為工程師們記錄下來。在這一點上，我們可以說，它離現代產品管理差了180度。

5.關于設計的角色也是同樣的故事。設計發揮真正的價值已經太遲了，他們所做的大部分工作，我們稱之為“給豬涂唇膏”。破壞已經造成，現在我們只是盡力去給這堆亂七八糟的東西畫上一件外衣而已。UX設計師知道這并不好，但他們還是盡可能地讓它看起來好一點，看起來一致。

6.在這種模式錯過的最大機會也許是工程師完成得太晚。我們說如果你只是用你的工程師碼代碼，你只是得到了他們一半的價值。產品里有個小秘密是，工程師其實創新最好的單一來源，但他們甚至都沒有被邀請參加這個過程的party。

7.不僅是工程師帶進這種方式太遲了，敏捷開發的原則以及核心利益進入得更遲。團隊也許只發揮了敏捷方式真正價值以及潛在價值的20%。你真正看到的是敏捷用于交付，但是剩下的組織以及環境根本不敏捷。

8.這整個過程是非常以項目為中心的。公司通常會為項目提供資金，人員并通過組織推動這些項目，最終啟動項目。不幸的是，項目只是產出（output），而產品則是全部的結果(outcome)。這個過程預見性的導致了孤立的項目。是，某個東西最終會發布，但它沒有達到它的目標，所以真正的那個要點是什么？在任何情況下，這都是一個嚴重的問題，它并沒有達到我們需要構建的產品預期。

9.老的瀑布流進程一直以來，并且還會持續的一個最大缺點是，全部的風險都在最后。這意味著用給客戶驗證的時間太晚了。

你也許聽過精益生產法，這是大部分人的選擇。關鍵原則在于減少浪費，而最大的浪費形式之一是設計、建筑、測試以及配置功能或者我們并不需要的產品。諷刺的是許多團隊認為他們正在使用精益法，但是他們進程的跟進就如我剛剛所描述的。他們實際正嘗試的是我們現在所知道的最昂貴、最慢的方法之一。

10.最后，我們忙于這個過程的同時也是在浪費時間和金錢，結果最大的損失在于機會成本。組織原本能（could）擁有，現在卻成了應該（should）擁有。時間和金錢一去不復返。

對于我來說，大量的公司花費大量的時間和金錢卻收效甚微，這并不奇怪。我警告過你，這可能是非常令人沮喪的。

好消息是我保證最好的團隊從來沒有發生過如我剛剛描述的事情。

關于最好團隊是如何工作的，我從不同的方面寫過許多文章。產品探索是指我們如何用成功的方法解決我們正在面臨的問題。探索是一種產品、用戶體驗設計以及工程開發之間積極的、不間斷的合作。持續的探索與持續的交付并行。路線圖（output）上的特征被解決業務問題（outcome）所代替。目標是產品／市場契合。

如果你的公司還在用這種老的早就被淘汰了的過程，我希望你能發光，開始向未來過渡。并希望你在做之前發現，你已經被比你更快更具有效率的初創團隊或者競爭對手所打破。

原文地址：http://www.svpg.com/product-fail

本文由 @Yibo設計?翻譯發布于人人都是產品經理。未經許可，禁止轉載。