做好產品的第一步

在過去的幾年裡,我和很多初創公司和大公司談過,我發現自己也給出了類似的反饋。所以開始把這個反饋寫下來是有意義的。在過去,我曾多次犯過這個錯誤。

探索產品創意的第一步可能是一個混亂的過程。隨著產品的發展,大量的想法將會改變和發展,我們會了解到什麼驅動了預期的效果。這就像是當你在降落的時候才建造飛機,而且手邊沒有關於空氣動力學的書籍……只有風從我們身邊疾馳而過!

當你定義你的產品的第一個版本時,你很自然地專注於構建和交付第一個版本。讓它在使用者面前儘可能快速地在使用者面前進行,這樣你就可以開始利用這種甜蜜的、甜蜜的反饋,這是非常有價值的。優化你的過程,使產品在那裡得到滿足是有意義的。

這是精益生產、測量、學習方法的精髓:

  1. 基於我們所知道的,建造出我們認為能夠解決問題的東西
  2. 衡量其有效性
  3. 沐浴在知識的光輝中,人們開始使用產品!
  4. 於是你成功的「從零到一」

許多人將這個「建造」部分解釋為主要目標,並且構建需要成為一個合理的功能產品。這是個不錯的建議,讓你的產品在眾人面前不舒服地提前把你的產品擺在面前是一種很好的方式來發現什麼是有效的。有一些真正的東西關閉了反饋迴圈,為下一次迭代做好準備,給我們提供一些需要改進的東西。

我經常看到的主要失敗點是團隊沒有花足夠的時間來確定,產品的核心結構是如何導致他們想要的效果,並且他們過早地發佈了產品的核心結構。

通過發佈了第一個產品,產品將會限制他們的機會學習和將不得不做大量的工作去嘗試另一種方法(通常是重組的大部分產品,甚至旋轉整個方法)。

是的,程式碼可以快速地改變,思想會隨著我們的學習而發展,但是儘可能地使用我們正在構建的東西儘可能的實用,可以節省大量的時間。我們要確保我們最終得到的是真正有用的東西…記住,我們很快就會落到地上,但是我們需要確保我們能飛起來!

問題會出在哪裡?

讓我們看一個可以重現問題的例子,然後讓我們看看如何改進它。

假設我們的目標是建立一個市場產品,將軟體公司和軟體承包商進行媒合(這是一個真實的例子,但是產品稍微改變了,以保護那間公司)。

在構建這個市場時,團隊的核心目標之一是讓公司與承包商聯絡,並且可以在上面簽訂開發合約。

很容易想象這個功能,並且這個功能也很容易實現。我們可以設計一個流程,讓公司建立軟體的需求,並且為承包商申請這些訂單。棒棒。

但是,讓這些公司審查一份承包商名單,選擇他們想要預訂的人,會不會更好?或者,對於承包商來說,直接申請那些公司的職位會不會更好呢?這兩種流程在表面上看起來很簡單,但是為了得到一個最小可行的產品,許多不同的 UI 流都需要支援這兩種方法。這是一個關鍵的岔路。

我經常看到類似產品的團隊在進行早期研究時,直接與這兩種(或是多種)受眾開會,談談彼此的需求,找到一個共同點,並且在產品發佈時測試它。在這種情況下就是這樣。

開發團隊與承包商溝通。他們知道他們想要能夠選擇一個公司來工作。

開發團隊也和公司對話。他們學習到了公司需要選擇的權力,可以從眾多的承包商中選擇一個為他們工作。

該團隊繼續進行原型開發,公司釋出職位空缺,承包商選擇一個空缺職位。在最後一步,釋出空缺的公司決定哪個承包商得到這個職位。

在原型測試中,整體看起來很不錯,團隊從他們測試的公司那裡得到了積極的反饋,而承包商對清單和平台的反應很好,說他們很容易就能申請到訂單。

聽起來很有希望!這個團隊開始著手進行這項工作。他們推出產品,希望看到公司開始列出需求,承包商開始申請閃亮的新職位!

為了讓事情有所進展,他們開始在 Facebook 上花上一筆錢,把人們帶到「漏斗」的頂端。

他們的使用者體驗設計很棒,一些公司開始在平台上刊登廣告,並且有一些承包商開始申請,但是增長相當緩慢,他們在 Facebook 廣告上花了很多錢!

在產品上線後的早期反饋中,他們產品設計的一個意想不到的副產品是,承包商在看到現有公司的清單之後,就不會再回到這個網站。太棒了!上了寶貴的一課。因此,他們建立了一個電子郵件服務,為承包商提供新的機會。這有助於讓一些承包商回來,但很多人開始從電子郵件中取消訂閱,因為他們現在要麼已經成功媒合,要麼上面沒有他們想要的公司,或者公司最後沒有選擇那間承包商,這感覺像是浪費了時間。

在這一點上,團隊非常執著於現有的公司釋出清單的模式,而承包商也在向他們申請,對應用程式結構的巨大變化是難以保證的。也許他們應該選擇讓承包商建立一個檔案,列出他們的專長,讓公司直接聯絡他們?他們也可以通過產品來處理付款。這能幫助他們更好地留住員工嗎?

這樣一來,在不斷的電子郵件中產生的噪音就會少一些,但承包商告訴他們,他們想選擇一家公司!

這個團隊現在必須做出一個非常困難的選擇,完全重新思考他們的模型,嘗試一些可能更好的東西,並可能將他們現有的模型擱置起來。

那麼,這有什麼不同呢?

團隊如此專注於構建產品的初始版本,以至於他們沒有將他們想要學習的東西分解掉,並將大部分時間推遲到最初產品發佈之後。這使得他們很難承諾嘗試截然不同的東西,從而創造一個更強大的市場生態系統。

讓我們回顧一下構建,度量,學習週期。它對測試假設非常有用,但是它也要求團隊理解他們應該只構建他們想要學習的東西!他們不需要把產品從頭到尾都建立起來,也不需要專注於推出一個最小可行的產品,直到他們嘗試了一些方法來找到最小阻力的路徑,以及什麼驅動了最強大的網路效應。

在一個糟糕的模型上構建你的產品的第一個版本會讓你在以後的日子裡很難擺脫它。

所以,我對早期團隊的建議是逆轉這個過程:

  1. 從你想學的東西開始
  2. 確定如何測量這個。
  3. 你能建立的最低限度是什麼?

讓我們試試這個…

那麼,讓我們想象一下,我們回到了我們之前討論過的市場產品的開始。

這一次,團隊問自己「我們想學什麼?」

他們列出了一系列要學習的東西,其中包括:

  1. 公司需要從承包商那裡得到什麼?
  2. 是什麼讓公司在一個市場中工作?
  3. 是什麼讓承包商持續使用?
  4. 是什麼惹惱了承包商目前的工作方式?

通過讓團隊專注於他們需要學習的東西,他們可以設計實驗和原型,從而驅動一個更強大的基本模型,而不是不得不在後面回溯。

如果你花時間閱讀 Jeff Gothelf 的精讀書籍,你會發現這是他方法論的核心;你需要專注於學習,優化你的學習,而不是堅持你的核心假設。

在早期,只建立你需要學習的東西,一些核心的決定很難離開。

TL;DR

不要先建立產品,然後才從產品中學習。從你想知道的事情開始,計算出你將如何衡量它,然後再開始動工。

儘早優化靈活性,並嘗試其他方法。關注結果,而不是方法。

不要愛上你的想法,而是熱愛你的結果。

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *

*
*