逃逸速度:初創(chuàng)企業(yè)如何走出失敗的泥沼

0 評論 12313 瀏覽 1 收藏 12 分鐘

導讀:對于一個初創(chuàng)企業(yè)來說,有什么比速度更珍貴的呢?Sam Altman如是說:“快速推進。速度是你逃離巨大競爭吸力的最主要的方法”。 而Eric Ries所提出的當前炙手可熱的“精益創(chuàng)業(yè)”理念大部分說得也就是速度的問題。那么對于一個初創(chuàng)企業(yè)來說,速度最大化以避免你的企業(yè)墜毀得灰飛煙滅尸骨無全究竟意味著什么呢?下面我們就好好分析分析!

物理學上有個術語叫“逃逸速度”,指的就是一個物體如果要逃離萬有引力的約束所要達到的速度。一個火箭上升的初始速度如果能達到11.2km/s以上的話就能夠沖出地球走向宇宙一去不復還。如果低于這個速度的話,那對不起,你將需要消耗更多的燃料慢慢的推動著火箭往上升,最終的結果可能就是上演一出真實版的“重返地球”最終墜毀化作一團火球,只是電影《重返地球》中人家是從外太空來回到地球,而你卻從來沒有離開過地球。

對于一個初創(chuàng)企業(yè)來說,有什么比速度更珍貴的呢?Sam Altman(注:YC董事長,”硅谷創(chuàng)業(yè)教父“Paul Graham的接班人)如是說:“快速推進。速度是你逃離巨大競爭吸力的最主要的方法”。 而Eric Ries所提出的當前炙手可熱的“精益創(chuàng)業(yè)”理念大部分說得也就是速度的問題。那么對于一個初創(chuàng)企業(yè)來說,速度最大化以避免你的企業(yè)墜毀的灰飛煙滅究竟意味著什么呢?下面我們就好好分析分析!

初創(chuàng)企業(yè)發(fā)展速度模型

初創(chuàng)企業(yè)跟火箭一樣都是按著一個速度往前推進的。在物理學中速度指的是在某個時間內(nèi)推進的距離。而對于初創(chuàng)企業(yè)來說,速度意味著企業(yè)發(fā)展的進度(上圖右上的Progress)除以所需的時間(上圖右下的Time)。假設一個初創(chuàng)企業(yè)所需要投入的資源成本就是時間,進度就等同于獲取到的商業(yè)價值,那么替換到以上的公式就得出了你的ROI(投資回報率)!

作為一個初創(chuàng)公司來說,你將會面臨很多的不確定性。你很難去預測你下一次迭代的功能點收效如何。你的預測結果也許會命中,但大部分情況下往往結果會是錯的。你所能做的事情就是去快速投放市場驗證然后觀察效果??偟膩碚f,初創(chuàng)企業(yè)在每次迭代時所取得的進展平均起來都是很小的,因為在10個功能點快速驗證當中,你如果有幾個效果是很成功的話已經(jīng)是非常阿彌陀佛的了。

為了在我們的初創(chuàng)企業(yè)速度模型中更好的描述這些令人擔憂的因素,讓我們把迭代進度進一步細化成“預期功效“(下圖右上的Expected Win)和“成功機率”(下圖右上的Success Chance)。在下圖中你就能看到每次迭代中低迷的”成功機率“會大大的拖住每個初創(chuàng)企業(yè)的發(fā)展速度。這我們總不能坐視不管啊。

好消息是在上面的迭代效率模型的底部你還有個叫做時間(Time)的東西讓你扳回一城。你將需要竭盡所能的在每次迭代中用盡量短的時間將功能推出市場進行快速驗證。同時,迭代時間又可以細分成以下兩個主要部分:

  • 開發(fā)時間:所有直接對產(chǎn)出做出貢獻的活動—?編碼,設計,測試,以及部署速度
  • 間接消耗時間:研究,討論,頭腦風暴,計劃,等等

最終得出的細分的迭代效率模型圖如下:

從中可以看到,如果能把開發(fā)時間(上圖右下的Development Time)和所有間接消耗時間(上圖右下的Overheads Time)拉下來的話,你就能大幅度的提升你的初創(chuàng)企業(yè)的迭代速度。如果僅僅測試一個小改動你就需要花費幾個小時的測試時間的話,那么,兄弟,這意味著你的產(chǎn)品開發(fā)正面臨著一些嚴重的問題,是時候開始做點事情了。同理,在你費盡口舌耗費幾個小時來說服你的小伙伴們來認同你的觀點期間,你其實已經(jīng)可以將它實現(xiàn)出來并開始進行測試了。少說,多做!

那么我們可以做些什么事情來加快我們每次迭代的進度呢?答案是肯定的,建議如下:

  • 從潛在價值高的功能入手 — 首要的就是要關注在那些你在短期內(nèi)可以實現(xiàn)的給你的產(chǎn)品帶來重大改觀的那些功能點上面。
  • 好好對你的上一次迭代進行研究分析,以便更精準高效的對這次迭代的預期效果做出評估以提高成功率。
  • 對大功能點要抱著如履薄冰的態(tài)度 — 雖然大的功能點往往會帶來可觀的贏面(這樣說吧,我現(xiàn)在做個產(chǎn)品,有個功能點叫做QQ。這功能點贏面夠可觀吧?但你不把它細化的話,你根本就會找不著北該如何入手去做,只能東搞西搞的把投資人的金錢燒得無影無蹤而已),但它們同時也會充滿風險和消耗時間(基本上,大功能點會拖你后腿讓你行動緩慢)

好的,理論分析完了,完整的初創(chuàng)企業(yè)速度模型和迭代效率模型我們都有了,那么是時間來找個麻雀來解剖下了。

案例分析

不久之前我正好給一個面臨著開發(fā)時間嚴重挑戰(zhàn)的初創(chuàng)企業(yè)進行指導。他們的組成成員其實都是一級棒的,非常有天分。其實他們都非常想做出點改變,但是事實上又對他們的產(chǎn)品開發(fā)進程裹足不前這種狀態(tài)束手無策。開發(fā)和部署一個小功能往往都會耗掉大家超過一個星期的時間。很多不錯的功能點一直都只能在他們的Product Backlog(Scrum術語:產(chǎn)品清單)或者Sprint Backlog(Scrum術語: 沖刺清單)中長眠不醒無人觸碰。大伙慢慢變得意志消沉備受打擊但又無可奈何。

為了解決這個問題他們也嘗試過想出一個這樣的解決方案來:根據(jù)商業(yè)價值和實現(xiàn)技術復雜度來對每個功能點進行評估(其實和我們上面的迭代效率模型已經(jīng)很接近了,只是他們沒有把風險/成功機率給考慮進去)。他們希望對每個功能點都做詳盡的分析以便更精確的把握這些功能點的潛在回報率,然后再從中挑選一些出來進行迭代實現(xiàn)(可以想象這樣的流程在一個迭代中將消耗大量的間接時間)。

為什么他們得做法不奏效呢?

  1. 后來的方案沒有把大功能點的潛在風險考慮進去。這就導致了他們高估了(擁有最高風險的)大功能點所帶來的價值,而反過來又低估了小功能點優(yōu)化所帶來的價值。
  2. 最開始方案的過長的開發(fā)和部署時間的消耗導致了大量的優(yōu)秀功能點沒有辦法在迭代中完成,時間不夠。
  3. 后來的方案中對每個功能點進行額外分析所帶來的間接時間消耗就讓上面模型方程式中的分子變得越加龐大,分子變大了,結果當然是等式左邊的迭代效率下降了。

所以,該方案一開始就走錯了方向,因為沒有把問題定位到過慢的開發(fā)時間上面來。通過限制從Product Backlog中取出的功能點數(shù)量,并要求對每個功能點投入額外的調(diào)研時間來確定哪些功能點需要放進當前的Sprint Backlog上面,這只會大大的拖住你的初創(chuàng)企業(yè)往前邁進的后腿。其實他們更應該關注的是去降低開發(fā)部署時間以及其他間接消耗時間(包括那些額外的調(diào)研),以確保盡量多的功能點能得到盡快實現(xiàn)并投入市場進行驗證。

結論

以下各點就是從初創(chuàng)企業(yè)速度模型提煉出來精髓:

  1. 在產(chǎn)品開發(fā)期間把目標瞄準那些具備可操作性的優(yōu)秀功能點上—把功能點的實現(xiàn)并推向市場的時間最小化。把你的開發(fā)周期壓縮到以小時為單位,而不是以多少周來衡量。交付MVPs(最小可行產(chǎn)品)而非大而全的產(chǎn)品。
  2. 別妄想你能準確預測用戶對功能點的接受效果。離開你舒服的椅子,走出你的辦公大樓去尋找真正的用戶進行驗證。別害怕失敗。只要你能從中學習,別在同一個位置上栽兩次跟斗就行了。
  3. 別把好的功能點都放在你的Product Backlog中睡懶覺,確保你有足夠的“帶寬”來處理那些最“有前途”的功能點。
  4. 別讓上面說的那些“間接消耗時間”拖了你的后腿。避免那些過長的無謂討論或所謂的長期計劃??焖俚答伈攀峭醯?。
  5. 盡量把大功能點細化成小的步驟來付諸實現(xiàn)和驗證。耗時的大功能點只會讓你舉步維艱。

英文文章參考:https://medium.com/@skalskiw/the-physics-of-startups-startup-speed-model-b014fab7deec

#專欄作家#

朱佰添,網(wǎng)名:天地會珠海分舵,微信公眾號:techgogogo。人人都是產(chǎn)品經(jīng)理專欄作家兼高級翻譯官。9年軟件行業(yè)從業(yè)經(jīng)驗,涉獵海外最新創(chuàng)業(yè)、融資、產(chǎn)品類的資訊和方法論,喜愛結交各行各業(yè)的朋友,歡迎聯(lián)系。

本文系作者授權發(fā)布,未經(jīng)許可,不得轉載。

更多精彩內(nèi)容,請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發(fā)揮!