來到最後一篇，談的是 Pivoting 的課題。

甚麼是 Pivot 和 Persevere？

Pivot 的意思就是將商業目標和產品方向造出主要改變、轉向。有時候當啟動了發展，並進入了學習廻圈，持續數週或數月後，漸漸見到產品發展和學習廻圈遇到樽頸。就是怎樣也發展不上去，就是試了很多次、試了很多設計，數據都仍無進展。這時便需要考慮 Pivot。

而相反，若堅持保持同一方向走下去，便叫作 Persevere。

Pivot 的方法論

Pivot 在公共研究方面是已經有很保證的方法論。通常有幾個方式的轉向：

1. Zoom in Pivot：將產品中一個較受歡迎的部份，抽出成為整個產品。
2. Zoom out Pivot：相反，將產品收納成為新產品方向的一個部份，造一個更闊涵蓋更多的產品。
3. Customer Segment Pivot：轉向到另一個目標用戶群。
4. Customer Need Pivot：同一個用戶群，不過將照顧的需求轉變成另一個。隨著學習廻圈，當你對用戶了解得夠深，就可能發現他們有些更重要的需求。
5. Platform Pivot：將本來銷售產品的機器，改變用途使其本身成為了一個產品。AWS Cloud 便是一個例子：本來它是 Amazon 的電子貿易支援平台，但發展得好便將其包裝作另一個產品出售。
6. Business Architecture Pivot：改變商業策略和結構。例如將定價策略從 low-cost 轉變成 differentiate。
7. Value Capture Pivot：改變盈利模式。
8. Engine of Growth Pivot：改變 Engine of Growth（參前篇有關商模 3/10），亦即推廣模式。
9. Channel Pivot：改變銷售渠道。
10. Technology Pivot：改變運用的科技。

通常一個幾保證成功的方法，就是和一些正在用這產品的用戶作個面談。面談通常都能將產品的 Pivot 帶到一個比較保證的方向。

創業跑道

有人說過一個講法：創業若比喻作將飛機起飛，那麼跑道的距離，就是創業在高飛之前可以嘗試的距離，就是這個團隊做 Pivot 的次數。那麼就有三件事是影響這個跑道的：

1. 團隊的學習能力越強，每次學習和 Pivot 都越能對準正確方向和目標，成功機會便越大。
2. 每個 Pivot 的性價比，就是它的成本越低、效能越好，就越能成功。
3. 減少不必要的浪費。

 

超迷你創業

之前 2016 年寫這個專題，然後收到一些詢問指引。所以探討並寫這個題目：超迷你創業。
對於不少人來說，創業是其中一種在工作以外，能帶來更多上游力的方法。但說創業成本似乎不輕，需要資本，還有知識和風險。怎樣可以減低創業的成本和風險，並增加其成功機會？

筆者是以推薦了迷你創業這個方向。

簡單來說，就是將一個大的計劃，造成十個細的計劃。例如不要做一個一年期目標上百萬用戶的計劃。而做一個一星期甚或一兩日，目標用戶只上千人的計劃。這個做法的好處，是一來對初學者來說可以練習下方法論；二來若能成功，也可以延伸成一個中期或長期而目標較大的計劃。

小計劃的做法是選擇一個較有限的範圍，然後用一個較細的 MVP 去啟動學習廻圈。例如半個至一個工作天的開發時間，然後用另一個工作天放出市場收集數據，並按數據來調整方向。例如若用這方法，建立到一個減除推廣支出後，有正面現金流的商業模式，就已經算是成功了。

每日進步一點

筆者也會對一些已經在產品管理或市場推廣路上的人說相似的建議。就是每日都給自己一個挑戰：今天要將產品再改進一點。持續地學習、持續地整合方向、持續地前進，產品管理就是這樣一個生活方式。

同樣地，市場推廣也可以有一樣的做法。可以不是一次用大筆的預算來做推廣。而是先以細小的預算，例如數百港幣，先用來測試不同地區、渠道、媒體、內容，按數據作出調整。然後到數據比較好，才以較大的預算來做全面推廣。這些都是比較好的做法。

 

是時候講下 Lean Method，中譯作精益或精實方法論。

精實方法

精實方法是 Eric Ries 在 2011 年開始推廣的。並以《Lean Startup 精益創業》一書為標準教材。若要很簡要的說，這個方法論有三個重點：

1. 驗證學習 (Validated Learning) 。Lean Method 的重點不是建設產品，而是以學習為中心。
2. 建設、量度、學習 (Build, Measure, Learn) 的循環。筆者慣簡稱之為「學習廻圈」。大部份你在網上找到有關精實方法的圖片都以這個廻圈為主點標誌。這個實際上是一個包涵了工程建設的科學方法。而這個廻圈，就是將驗證學習具體化執行的流程。
3. 點子會計 (Innovation Accounting)。在公司內開一個知識庫，將上述的學習內容，記錄下來。

舉個例子

舉例來說。例如你做一個面書專頁或博客，有關某個主題。就例如說有關小貓吧。實踐以上的三個重點：

1. Validated Learning
   1. 學習的對象是喜歡看小貓的讀者，或有養貓之人的市場生態。
   2. 而領域範疇為所有有關貓的內容。
   3. 而驗證學習要學習的，是這個市場的生態，它的運作方式。
   4. 例如這市場的受眾最容易被哪些內容吸引？哪些他們會最容易參與討論？最容易按 like 和轉載分享？等等。
   5. 記緊上一篇重複的提醒：這個學習就是你的主要資產，而不是個專頁或博客本身。
2. Build, Measure, Learn
   1. 先由一個最簡要的入手。例如開個專頁，然後貼一些圖片。這便開始了「建設」。
   2. 然後給它一些時間流逝，觀察一下讀者的動態。
   3. 然後建立一些科學設想 (Hypothesis)，並進一步建設去做驗證。這便打開了這個學習廻圈。
3. Innovation Accounting
   1. 做一個知識庫 (Knowledge Management System)，儲蓄你收集到的知識。最簡單的是一個普通的筆記本便可。

進深講下 Innovation Accounting

精實方法可以說是符合邏輯直覺的。一般實踐只要方法正確，都會做到這三點的。然而若是這麼簡單就不會被稱為神器了，是不？

精實方法的精采之處，是它可以像另外兩個 Agile（一般譯作敏捷開發）和 Devops（譯作發運，開發與運維）一樣，可以全面性地在公司實施，作為公司的管理系統的主軸之一。

而要將精實方法推展到整體公司執行，重點就在那個 Innovation Accounting。

Innovation Account 要執行得好：

1. 較容易做的是由廻圈中的量度入手。不少公司都有做的是在管理決策層公佈一個量度儀表 (Dashboard)。而亦可推展到整個公司，在公司內公眾地方設立儀表版，將主要的量度數據張貼出來。讓所有員工都有一個一致的標準，同心合力朝向目標邁進。
2. 進一步，是將當前的學習路徑，和測試中的項目，及其背後的原理 (Rationale)，成為員工都能接觸到的材料。例如公佈在內聯網或檔案伺服器上。
3. 更好的是收集了學習得來的數據和知識庫，用一些文檔系統分類處理。然後在公司內培養這個習慣，在討論或開會中，都引用文檔來有根據地做科學方法的推演和證實，並構造出要驗證的項目開發，如此便可以將精實方法較完整地整合到公司管理系統和文化當中。成為一個學習的公司，並擁抱科學方法論。
4. 再進一步。將 (3) 執行到後，設置獨立管理這件事的人或小隊，專門收集和整理學習的資料和數據，並有效地將之表達出來。

精實方法是有其好處，若是具盈利潛力的行業，是值得建設這個方法系統的。而方法論歸方法論，最終的目的還是回到那個「學習」上。精實方法的核心價值和重要提醒，就是讓公司累積知識，然後讓公司能解決問題，並獲得盈利。

在講 Lean Model 之前，再講一講商業資產。

拓展的重點資產

建立一個商業的過程中，要留意甚麼是你的資產，甚麼不是。而且不同階段，資產的著眼點也有不同。對傳統企業或大型企業的重點資產，和初創那種方式的重點資產也有不同。要知道自己正在走的路上，甚麼是真正重要的資產。

這幾種資產對創業是重要的

1. 首要：know-how 或對市場的知識
2. 建立 (1) 的方法論
3. 其次：建立 (1) 的技術資產
4. 然後是運作到以上 1-3 的模式所需的人才和資金

而不是這些資產：

1. 已註冊用戶數
2. 瀏覽量
3. 普通技術資產
4. 等等

這些我們一般叫做「虛榮的指標」vanity metrics。建立商業和做產品設計的過程中，切忌跌入這些虛榮心陷阱。

以 deliverable 來說

若用 deliverable 來說，在開始執行你的計劃時，你應該專注建立以下這幾種資產：

1. 你的產品領域的知識庫。尤其要對市場和用戶要非常x100的熟悉。這部份聽起來不那麼重要，但這是和 Lean 方法論息息相關，尤其以活用其 innovation accounting 的概念而言。這些在下篇會有詳細講解。
2. 而且這些知識，要顯示在你的市場漏斗和轉化漏斗中（Marketing Funnel a.k.a. Acquisition Funnel; and Conversion Funnel）
3. 支援以上系統的技術資產。
4. 然後才是支援以上系統的人才取得方法和營運資金。

學習廻圈與技術負債

這裡建立技術資產和加速學習廻圈，是一個矛盾的事。因為若要越快加速學習廻圈，代碼的質素會越低。低的技術資產，會形成技術負債 (Technical Debt)，就是一些不容易維護和擴充的代碼。

通常這方面，會建議將學習廻圈和長期代碼分開兩份。這概念有點像以前講的 prototyping 原型制作。用面向學習廻圈進行優化的原型來做學習，然後用面向技術代碼架構進行優化的技術資產。用這兩項來達到最優化方式。

將 Lean Model 和 MVP 玩得很熟，是能大大提供企業的成功率，並能將成功經驗重覆複製。

在講下去之前，先講多一點運用 MVP 的技巧，和一些設計 MVP 時要留意的事。

Rule of Thumb

MVP 的 Rule of Thumb 就是「越小越好」。要小到可以盡快推出實際市場環境，亦要大到足夠啟動學習廻圈。

有時有些人會對足夠啟動學習廻圈有點抽象。亦有些人會對之誕生恐懼感，但經驗告訴我們這種恐懼感是會延展上去的，因為越遲推出市場面對實際環境，就越容易累積恐懼感。

不確定 MVP 的大小，通常就會一直加功能上去 MVP。而這便是領導者的智慧，亦涉及機構內的執行權力，例如在位的人是否有經驗判斷、有經驗的人又在不在其位。所以對任何新產品的開發，能全力支持的 Project Sponsor 是很重要。

對於一直加功能上去 MVP，通常筆者會給一個指引：將整個 MVP 限制在「不多於 10 man days (MD)」為標準。man days (MD) 是「一個工程師做一天」的工作量。例如若你有兩個工程師，10 MD 就是兩人做五天。

黑客松

MVP 是可以參考下黑客松 (Hackathon) 的模式。

黑客松是一些企業或大學舉辦的小型創業比賽，通常是週末的三日兩夜舉行。而且外國的大型黑客松不少都有科創投資參與，其優勝者都可即時得到這些天使投資公司的投資和日後營運的孵化培育。

黑客松的三日兩夜，通常星期五晚有個華麗的開幕禮，介紹下主辦機構、日程、規例、獎品，或有個示範、加上充滿幹勁的音樂和影片的華麗視效，然後就開始了。一般團隊由四至六人組成，星期五晚上已有個概念，然後團隊各人便開始分頭埋頭苦幹了。

通常黑客松大家都是不睡覺的。而且飲品、食物、啤酒、零食，免費任食。然後到第三天上午，大家來到評判時間。各人都在評審前做專業級的演講報告，各人帶著實際的具體開發成果，和一些初步的商業營運數據，讓評判評分。然後就是一個頒獎禮和閉幕禮。

你可以想像到，這個黑客松裡面，能做的產品大小不會很大。但也是足夠評審看出商業方案的高下。可以說，這三日兩晚用到盡不睡覺，扣除開幕與演講評審，也大約只有 30 小時左右，還要包括營運數據和準備演講報告。假設四人是核心工程團隊，另外一人是行業專家，一人是目標領袖和準備報告，30 小時 x 4人 =120 小時，x6 人=180小時。大約就是 5-8 MD。

超迷你創業

MVP 的理想做法，是「化整為零」。對筆者來說，五日都已是太多。較理想的例如 0.5 – 1 MD 開發，另外 1 MD 推入實際環境市場的營運和測試。這種創業，週六日晚有空或隨時都可以做。盡快並加速其學習廻圈，是 MVP 和 Lean Model 的精髓所在。

 

團隊框架

在這個階段，你已需要加入核心團隊。初始團隊構成有不同理論，這裡分享兩個較好的行內流傳的 framework：

Framework 1 是個較簡單小型的基本團隊形式：

1. Vision Star：推動目標、迎向市場的人物。
2. Tech Hero：技術專家
3. Administrator：處理一切行政、投資、環境需要。

Framework 2 是個較全面的框架。可一人多演：

1. Vision Genius：目標的倡儀者
2. Tech Hero：技術專家
3. Superstar：執行力推動力的來源
4. Leader / Team Coach：引導團隊和解決團隊執行疑難的人物
5. Industry Veteran：對行業有專業知識的人物
6. Sales Animal：銷售專家
7. Financial Suit：處理公司現金流的人物

以最小團隊而言，Tech Hero 配搭另一個 Vision Star + Administrator，這樣的兩個人就可以是團隊。通常最需要知的幾條問題是：

1. Vision Star 的 Vision 有可行性嗎？
2. Administrator 投資情況是否妥善？對團隊的支持度/是否放手去做？（因為他管理投資者期望）
3. Tech Hero 是否能否有效執行，而且包括優化？

若這三個問題都是「是」，恭喜你，你已有一個有成功潛力的團隊。

招聘

有些創投者喜歡找外判公司（outsourcee）代替 Vision Star 或 Tech Hero 的功能。建議最好不要這樣做，雖然找人才也不容易。筆者見過不少人找外判的 software house 代替 Tech Hero，做出來的產品質素往往很差，加入不少技術負債（Tehnical Debt）；而且連同購入源碼的價錢，往往抵不上聘請一個 Tech Hero。而且 Tech Hero 可以替你在技術資產 (Technical Assets) 上做 optimization 優化。

對這幾個核心人員，筆者提供一些聘請形容。

Tech Hero：
八年技術年資以上（非技術不計算，例如不計項目管理），有其中三年以上是系統分析師或以上。
方案若包括前端、後台和資料庫幾個部份，適合每個部份都至少三個以上的實戰參考案例。
對完整系統、系統開發流程有概念。

Vision Star：
明白市場是「誰」WHO。能解釋 Value Hypothesis 和 Growth Hypothesis，即商業模型中的核心：產品回應需要的（需要被MVP證實的）假設。
若 MVP 需要調整或轉向，知道 know-how。
對budgeting、產品週期、analytics、product funnel / sales funnel、persona、開發流程有概念。

Administrator：
對環境、系統開發流程有概念。
對投資市場知道 know-how。

一開始做了定調（第一篇），然後審核了商業模型後（第二篇），下一步的最優化方案便是進入 MVP 學習廻圈、建立量度機制、並加入 Lean – Agile – DevOps 等營運架構。然後直到企業展翅高飛。這些我們之後都會陸續詳細講解。

MVP 的 Rationale

這裡要先講解一下 MVP 和其背後的 Rationale。

MVP 不是為自己而誕生的。是基於 Lean Startup Model 而應運而生的。
Lean Model 的原理是藉 MVP 盡快進入學習，專注於學習，並不斷藉修改產品進行學習廻圈。

MVP 很多人都聽過。似乎很多人都懂。但筆者就不知見過多少人搞錯了 MVP 的方法（可能多於一半人….）。MVP 是「Minimum Viable Product 最簡可行產品」。很多人就從這個字的字面意思去理解它的用法。所以會知其然而不知其所以然。

MVP 的重點不在最簡、亦不在可行、亦不在產品。產品不是其本身的重點。只要任何人講 MVP 時重點在其產品，差不多你都可以知道他走錯了重點。

MVP 的重點在「學習」。而不是產品。MVP 的惟一存在目的，就是盡快幫助企業進入學習廻圈。而這個對市場的學習，朝向 Product-Market Fit 盡快邁進，這是 Lean Model 的核心精髓所在。

MVP 的例子

舉例說。有一段時間很流行的 kickstarter，先籌集投資後開發的做法。有些創業者的做法是做了一條影片，去講解產品的概念。也只做了一條影片。即是沒有實際現成產品在手上。甚至連其基本形態都沒有。這個影片也合乎 MVP 的定義，就是幫助公司盡快進入學習廻圈，去明白市場和盡快朝向 Product-Market Fit 邁進。

另一個例子。例如筆者試過搞某個大型集體活動，例如遊船河或宿營之類。是事先沒有做任何訂船或安排食物之類。而是先做了一個網上問卷。然後用同樣的產品設計方法論，按埋點 (analytics) 收集數據分析，讓數字和專頁的訂閱數說話。

MVP 的兩個 Hypotheses

MVP 的學習，是一個完整的科學方法。科學方法自然有其需要驗證的設想 (Hypothesis)，其專注在兩個設想上：

1. Value Hypothesis：你的產品是否在提供一個用戶願意用錢去換的價值？
2. Growth Hypothesis：你的產品是否能在巿場環境有效發展和推廣？

歷史案例告訴我們，那些很成功的企業的產品，這兩個 Hypothesis 在很早的時間就已有很高的分數。而這個以科學和量度數據為主的方法論，可以讓企業在安全穩固的基礎上揚帆前行。

 

第二篇。在往下去講之前，再講解一下商業模型。

有些人開展新公司之前，做營運管理已有相當年日和經驗，他們對商模（商業模型 / Business Model / Biz Model）已相當熟悉；亦有對商模不太稔熟的新手。這篇是都適合這兩者；熟悉的人可溫故知新，初學者也可以得到一個好而實用的框架長遠運用。

《Business Model Canvas》

文頂的圖是取材自《Business Model Canvas》，發佈由 Alexander Osterwalder 帶領的學術研究，研究商業模式的藍圖，一本殿堂級商業典藉。（筆者看這書不知不覺已經是十年前，光陰似箭🙈）這個圖也就是以該書命名的一個核心概念：一個設計商模的框架。

這個 Biz Model Canvas，用九個部份分析了不同的商業模型組成方法。而該書的餘下部份，都是將現有世界上成功的商業模型案例，放到這個框架當中作分析比較。

詳細的細節，讀者可以參考《Business Model Canvas》這本書。亦有它的姊妹作《Business Model You》，對個人的事業和人生發展有所分析。

改進與進化

Business Model Canvas 的年代是未有 Lean Startup Model 的年代。而 2011 後 Lean Startup Model 大放異彩，有效地導向產品設計和巿場推廣，並將其放進科學方法和模型裡有效分析。並及後 Lean 與 Agile 和 DevOps，合併運作，筆者常稱之為營運的三大神器。這三者的配合得很好，而優點在非常有效地以科學方法推動執行力和營運，並從頂至底都能一貫統合為一個企業機器。一個非常整合全身協調互動的系統。所以現代的營運管理，基本上筆者都會推薦 Lean Model。

而上述的 Business Model Canvas 與 Lean Model 的配合協作，是不太簡化和具彈性。所以筆者自己設計了一個，較能簡化而具彈性的商業模型框架。並能和 Lean Model 無縫函接。兩者都參考可以互相取長捕短。

筆者的商模框架主要考慮三件事：

1. Value Proposition：你是提供甚麼價值給用戶；廣義來說：你是提供甚麼價值給世界？這亦包括了生產系統 Production Engine。
2. Financing & Sustainability：提供 (1) 的價值的同時，你打算怎樣使這個模式能長夠維持運作下去 (Sustainability)？怎樣賺得這企業機器的運作資金？
3. Engine of Growth：你打算怎樣將你的產品推廣出去？怎樣量度其效率？怎樣支持這個系統？

 

 

有一些技術守則是筆者應用了很多年的，對工程技術團隊適用：

1. 有一些結構寫法，盡量不要用。若用了，請知會你所從屬的主管
   1. SQL joining multiple table。以 Denormalization 為效率優先的設計為主。若有 join table 請提出來登記。
   2. For loop +=2
2. Git
   1. 每天都 pull 一下你的項目。
   2. 由主管管理 release / master branch。
   3. 只提交能運行的代碼。確保提交後代碼是一套能運作和上線的版本。這是 CI / CD 的標準。
3. 協作
   1. 前端同事沒有後收到後端同事的 postman，可以不做。

平常筆者在 Problem Solving 解難方面，會推薦一個叫「火車」的方法。

通常問題的結構就像一個鎖鍊或火車車卡，環環相扣。
所以解決問題時，可以用這個衍生出幾個方法論：

1. 方法論一
   1. 先執住頭同尾，限制範圍 scope。
   2. 然後逐節檢查車卡，找出問題。
   3. 最快的方式之一，是用 Binary Search。就是先檢查中間。
      1. 例如若左為對，右為錯，而中間為錯，那問題在中間偏左的位置
      2. 若左為對，右為錯，而中間為對，那問題在中間偏右的位置
2. 方法論二
   1. 留意一些特別難的問題，往往因為有錯誤的假設。
   2. 例如十節車卡，所有都為真，但其中一節的車架是有 99% 為真，有1% 是建立在不可靠的假設上。就會使到整個列車成為錯誤。
   3. 同上，用方法論一找出錯誤。
3. 方法論三
   1. 以紅綠燈來說，檢查所有車卡的紅綠燈。找出 weakest link。