第四招是，每日執行 Standup Meeting。
坦白說，這是我認為這四招當中最重要的一招了。當你的公司如果只有兩個人，什麼都可以用口頭交代的方式。但是一旦成員到達三人以上。就會發生溝通不良，或者短期目標不一致所以導致執行優先權狀態不一致的狀態。
Agile 專案管理中的 Standup Meeting 可以很好的解決這一個問題。
What is Standup meeting ?
Standup Meeting 是一種團隊例會，長度只有 15 分鐘，也只能有 15 分鐘。在開會時每個人都必須保持站立。（防止有人太囉唆）。這個會議強制各位同事參加。
每個人在會議中都要依序報告三個規定的問題：
- 昨天我完成了什麼
- 今天我要去完成什麼
- 在過程中遇到了什麼樣的阻力
Why we need Standup Meeting?
抓出腳步不一致的人（當然這不是主要重點）
感覺回答這三個問題很容易對吧。非也，如果是對充滿幹勁的人來說，回答這三個問題超容易。但是對於偷懶或散失鬥志的人，超級難。對於偷懶的人，編造這三個問題超級困難。
P.S. 這裏有兩個訣竅
- 絕對不允許同事在 Standup 前臨時請假翹班
- 不要因為貪圖快速，而允許「只用軟體」線上 Standup，這樣大家只會拿到一堆假的濫竽充數互相自慰的報告。
聚焦
從大家的 Standup 大致上就會發現，這一週大家的重點與優先權是什麼。需要協作的狀態是什麼。而不是大家無頭蒼蠅一樣在忙不同焦點的專案。
互助
Standup 不是跟老闆回報的會議，也不是回報同事互相監視的會議。而是一個「互助」會議。
在這個會議裡面，關於專案的進度，大家應該要誠實回報，沒有做、或做砸都沒有關係，重點是我們可以修補彌補這件事。自己不擅長沒關係，遇到專案阻力，也許同事也不同的想法以及專精可以幫助你解決眼前的問題。
畢竟快速往一致的目標前進，才是這個團隊需要的。
我們團隊怎麼做？
我們團隊目前的方式是：
- 每天下午 1:30 Standup Meeting
- 用 Hackpad 在 Meeting 之後記錄 Standup meeting 內容。
Hackpad 格式是：
- 昨天與今天我做了什麼
- 今天預計要做什麼
- 今天我做的東西遇到什麼困難需要別人幫忙的點
- 明天我預計要做什麼
當作寫日記一樣。
這樣的好處是當翻到前幾天日記的時候，你很容易回憶起幾天前我們做了哪些事情。
系列文章
我在創業日子裡面體悟最深的。就是在大公司裡面，做一件事情你擁有有無限的時間與資源。但是在小公司裡，你可能只有三天時間以及一個人手。
我以前熱愛打 Hackathon，我在打 Hackathon 這種需要嚴密調配資源的遊戲裡面，鍛鍊出一種做專案的 mindset 與實踐的方法。具體分為兩個步驟：
Deadline-Driven Planning
小公司的專案裡，通常只有 Deadline 是明確的，其他結構全部不明確。而且 100% 的情況，你不會有任何時間資源去「按照順序去規劃並完成所有你想要完成的事」。
這是跟在公司裡面「假裝敏捷」有很大的差異。按照一般公司的步驟在創業公司裡面做專案。常常會出現「手術成功」，但「病人已經死了」的悲劇。
而且後來，我更進一步地發現，絕大多數人會搞砸專案的原因，往往是因為資源太多，而非太少。如果你把時間抓得非常緊迫，那反而會逼出人類的危機感，自動過濾出「哪一些是是真的該做的」。
就跟期中交作業，期末準備考試一樣的原理。缺少時間，人類自然就會自動按照危機感把該做的事自動做有效的劃分。
所以我在 Startup 裡面執行專案的方式，是把每一個案子都當作 Hackathon 在打一樣。利用 Hackpad 盤點資源，然後用 Deadline-Driven 的方式，把看似無盡的時間與資源，切成幾塊有明確的時間區塊。
每個時間區塊有自己的 KeyResult。這樣就能確保不至於有太大的超時。
MoSCoW method
接下來我會將 Key Result 再次區分，用 MosCow Method 排優先權。
MosCow Method 是把所有的需求照
- Must have
- Should have
- Could have
- Won't have
的方式區分。
MosCow Method 配合時間倒序的專案管理方式特別有效。如果是用正向順序進行專案管理，人們往往會將需求通通定義為「Must Have」。
而如果將 Key Result 鎖在在有限的時間內，反而會迫使人們去決定重要順序。所有人的精力只會 Focus 在 Must have 與 Should have。
團隊可以在很短的時間，不拖泥帶水的取得 MVP 與 small wins。這正是 Startup 最需要的戰果。
系列文章
目標有了。接下來我想談步驟。我覺得創業公司第一件該做的事，是要導入 OKR。
什麼是 OKR 呢？
知乎上有一篇文章，把 OKR 的原理解釋得非常詳細：https://www.zhihu.com/question/22471467。這裏我就不花篇幅照搬運一次了。
這裏我只歸結重點。
OKR
- O 是 Object 目標
- KR 是 Key Result 關鍵成果
- 將公司階段目標「量化」
- 具體聚焦公司當下最重要的大目標
- 下層執行者具體「承諾」自己為了完成「組織大目標」所要完成的「個人工作承諾小目標」。
OKR 是為了指出公司成長北極星
為什麼引入 OKR 是第一件事，也是最重要的事？
創業公司最需要的就是聚焦。創業階段是一段非常混亂的時期。創業團隊會同時
- 湧入太多的機會
- 湧入太多的員工
- 產生太多的方向
眼前有一萬件事情要解決，但你卻只有 5 個人。
如果團隊不聚焦，很容易就被自己人踩到或者是殺掉。
創業跟在公司「上班」也非常不一樣。在「公司」你總希望事情平順進行，在創業每天都會有驚嚇。保持同一個方向前進變成是很困難的事情。
OKR 就是用來確保這個團隊裡，至少 1-3 個月內，大家的成長目標是一致的。而且不是漫無目的的 bullshit，而是實際可量化的指標與方向。
系列文章
在這篇文章裡，我要來談：「在創業公司裡面如何做專案管理」。這是一篇我認為難度很高的題目。
當然，在幾年前的我，是根本不這麼覺得的。甚至大部份熟 Agile 的 RD 都不會這麼覺得。不就是 Lean 嘛、Agile 嘛，少掉公司內囉唆的規格而已。
Agile is not completly for "Startup"
後來我自己在創業過程中，也不斷的思索這些問題。但想來想去，總覺得現有流行的敏捷管理，套在 Startup 的模式裡，總是怪怪的。甚至一些精闢的敏捷經典文，立論沒有錯，但是在這樣的場景內，總覺得哪裡歪了。
後來我理解到這樣的幾個現實，為什麼我會覺得他們歪
- 現有的敏捷開發，誕生的環境不是為了「Startup」。是因為一定規模的公司，人太多，為了改良使用「傳統瀑布流方式規劃專案」，提出的新架構。「增加效率」「減少浪費」。
- 大部份的敏捷提倡與實踐者，是 Engineering 部門的人。這些人跟「真正市場」與「付錢的真正用戶」非常的疏離與脫節。也許敏捷可以快速迭代成「他們想像的產品樣子」。但是做出來的東西，沒有滿足市場上任何人的需求。
- 既然都請得起 Engineering 「部門」。那麼這間公司定義不再是 Startup。而是 Company。
- 專案管理本身的其一目的是「消除風險」。而創業處處都是「驚喜」與「風險」。未知的機會與市場隨時會把你帶向另一個高峰。如果你真的在 Startup 做了非常好的的(so-called)「專案管理」，恭喜你，你的創業公司也離死亡不遠了。最常聽到的是技術團隊創業的公司，"Doing Perfect Agile" 卻把自己管到死掉了。
這就是為什麼我覺得「創業公司 Startup 如何做專案管理」是一個難度很高的主題。
For Growth, not for Risk Management
但是很多 Startup，還是非常希望引入「專案管理」，主要是太多的混亂、與眼前的機會爆發，反而把前進腳步打亂了，到了一個某一個臨界點。原本知道怎麼做把 MVP 做到 pre-PMF 的 Founder。反而不知道怎麼再繼續走下去了。
這時候就會面臨下一個問題「繼續維持高成長，但是公司不再混亂」。這就是我在這篇想要談的目標。
在這裡我有一個目前歸納出的重點：在創業階段的專案管理
- 不需要傳統專案管理的「風險管理導向」技巧
- 需要的是「成長導向」的專案管理技巧
系列文章
有很多人問在軟體界， Growth 與 Marketing 有什麼差別呢？
我覺得可以從三個角度來論述切割。其實這一篇也是在講 Growth Team 的職責守備範圍。
1. Brand 品牌
首先，「品牌」在傳統產品以及 Marketing 中，是相當重要的。你會圍繞著「品牌」這個核心進行行銷（ Marketing），進行Branding、PR、Event 等等。
而消費者會固定消費固定一間品牌公司產出的牙膏、肥皂、等等等等等。
但是「品牌」在「軟體」行銷世界中，其實重要性「沒那麼高」。
消費者在軟體世界的行為 pattern 裡面其實不太會理會「品牌」這個元素。而 Branding、PR、Event 能起到的作用也沒有那麼高。
2. Growth Marketing 技術。
以前做 Marketing 的行銷效果是很難被量測的。
而現在 Growth 有一大塊的執行與操作手法在講：如何更精確的量測「效益」以及「影響」層面。
用「最有效率的方式正確執行」。
這部分跟我們在第一段講的圍繞著品牌做行銷，手法與結果非常不一樣。
3. Growth Product
實作「產品」的哪一個部分，對於成長能夠造成巨大的影響。
NUX ( New User Experience）、Viral、Referral、Share 等等。
而成長團隊主要在做什麼呢？品牌是絕對不在 Growth Team 的守備範圍裡面。
Growth Team 的負責範圍，只有
- Growth Marketing
- Growth Product
這也是 Growth 與 Marketing 的界線所在的地方。
這是我半年來的心得。提供各位參考。
將產品分為幾個階段
首先，你必須認知到自己的產品到底屬於哪一個階段。
- 10 分：沒人用
- 20 分：Minmal Viable Product
- 40 分：可以跟顧客收錢
- 60 分：Product Market Fit
- 75 分：客戶回流高
- 90 分：壟斷市場
老是有人問我如何「一周成長 7%」這個問題。這裏提供各位一套具體的作法。
這個方法是我從 One Month 的創辦人 Mattan Griffel 身上學到的一個檢討方法，叫做 After Action Review。
這個方法也是他的一個投資者教給他的方法。因為公司開始擴張後，團隊輸出老是會高高低低，甚至有時候很蠢的事情會一直犯。這個方法能夠確保團隊一直走在「修正然後成長」的道路上。
實作方法
這個方法很簡單。只有一組共三個問題：
- What was supposed to happen? What actually happened? Why were there differences?
- What worked? What didn't? Why?
- What would you do differently next time?
在每次專案完工後，立刻做這件事。
像我們就是在每次演講結束後。隔天就會開始寫這份報告。這份報告並不是要「檢討個人錯誤」，相反的，它的角色是中立的。他的作用是要將團隊每次搞砸的事抓出來，並且下次做得更好。
避免屋子裡的大象現象
因為在傳統的做事觀念當中，每次專案有人當中搞砸了，大家要不是避而不談。不然就是承諾下次會改善，但從來沒有做到（除非捅了天大的婁子）。這份報告是強迫檢討並改進，寫下來的書面報告大家才會認真檢討。
這份報告對我們的團隊做事的方法極有幫助。推薦給各位使用。
延伸 Framework
當然，這個方法還有一些深入的工具與變形。 Harvard Business Review 也有出工具集。一份 29.95 美金。
我相當推薦各位購買。要是你不相信這個方法與工具集的價值。不妨先運作個兩次。相信你會體驗到這個方法的巨大威力。
P.S. 我正在寫線上工具了。否則堆積如山的報告與改善事項真是整理不完啊 XD
之前在上幾梯實作班的時候，很多同學對於 NPS 的下一個衍生問題是：如果問卷回覆率低，NPS 的準確性如何？
這個問題我本來也沒有好解法。不過最近我在持續鑽研的過程中，找到一本專門在研究 NPS 議題的好書：The Ultimate Question 2.0。裡面給了這個問題的解決法。
他們實際對幾個公司量測過 non-responder 的行為後，找出了修正公式。
修正公式是：這些沒有回覆問卷的人，10% 是推薦者，40% 中立，50 % 反推薦。
原始 NPS 是 50，只有 20% 回覆問卷
加上修正公式後， NPS 是 -22。
修正公式：
所以修正公式會是
原始 NPS * 繳交問卷率 + -40 * 沒有交問卷率。
以上圖的例子會是 50* 0.2 + (-40 * 0.8) = - 22
延伸閱讀
最近有幾封來信，希望我提供一下 Growth Hacker 適合的人選標準經驗。就我個人的經驗，以及與其他人交流的經驗。
我會把我的回答拆層兩種層面看，一個是技能 Stack，一個是人格特質：
技能 Stack
一般來說，最棒的當然是挖現有 Growth 團隊的成員，這樣最快。很可惜台灣不可能有 Team 可以挖。所以在台灣，只能找到適合的人自己養。
就技能方面，我推薦背景有這樣基礎
Read on →這篇要講的是 Growth 最重要的基礎在於 Retention。
Retention 強後，你就有基礎的財源，有了更好的 LTV ( Lifetime Value)，有更多資源可以去做更強的 Acquisition。更容易做 Referral。
這個道理很簡單直觀。好像有講等於沒講。
盲區一：沒有人想要「改善舊功能」，但是「成長」多是基於改善舊功能
但是為什麼就算很多人知道了，還是做不到。這歸咎在於在大部分的網路公司，在業務擴張的規則底下，人性對於業務提振的方向還是
- 開發更多產品新功能
- 開發更多產品新功能
- 開發更多產品新功能
別誤會。
開發更多產品新功能不是不好。而是開發產品新功能並不保證「會」成長。
Read on →