在一小時內終結點子
這第一個小時的重點不是決定是否要打造。而是快速找出「不做」的理由。能通過一小時考驗的點子，才有資格進入下一步。
在這裡花一小時，通常能省下三個月的開發時間。即使對方已經很確定，也值得做。
如何進行
你的目標不是駁倒點子，而是用低成本的方式找出這個生意的困難部分是否真的能克服。清楚地說出你的發現，即使點子通過考驗也要說。
留意自己兩件事：
- 別軟化結論。 把「法規禁止了這個」轉譯成「需要留意一下」就浪費了整個練習。如果點子死定了，就說死定了。
- 別急著救援。 建議「你可以做成管理服務，配上現場檢查員」通常只是換成另一個更難的生意。如果你想建議轉向，就把那個當作新點子，再重新跑一次檢查流程。
第一步 — 三種搜尋
首先，確定地點。 沒有管轄區就做法規搜尋是無效的，而大多數人描述點子時不會指定地點——「我的城市」、「這裡」、「家鄉」。在搜尋前先問清楚。憑猜測搜尋浪費一次機會，還可能讓你跑到完全錯誤國家的法規裡。
如果他們真的在多個市場營運，就對每個市場執行法規搜尋。答案往往不同。
然後執行全部三種搜尋。它們能捕捉不同的問題。
| 搜尋詞 | 會捕捉到的問題 |
|---|---|
<點子> competitors pricing | 已經有人做這個，以及他們的收費 |
<點子> free alternative | 已經有人免費做這個 |
<點子> regulation <年份> | 法規或平台讓這個無法實現 |
第三種是大家會跳過的，但它能殺死其他兩種搜尋找不到的點子。一項規則變更可以在一個晚上讓一門生意變得無法建立，而且不會留下任何競爭對手來警告你——他們全都退出了。
如果有好的免費替代品，這個點子通常就死定了。「我的會更好」不是發現，而是希望。問問什麼會讓人們真的從免費方案跳槽，以及那個東西是否容易被複製。
第二步 — 四項檢查
即使搜尋結果乾淨，也要執行這些檢查。
誰擁有管道，他們會自己打造這個嗎？
如果產品依賴某個平台——一個訊息應用、一個應用商店、一個支付處理器、一個銀行監管機構、某人的 API——那麼那個平台隨時可以改變經濟模式，而且通常會免費推出同樣的功能。一個獨立創辦人坐在大平台的下游，只是在租用他們的商業模式。
把它們數清楚——它們會疊加。 一個點子可能同時處於三個擁有者之下：一個實體守門人（機場、場地、房東）、一個已經在做配對的平台，以及一個具有自己許可的支付管道。每一個都可以獨立殺死它。當你找到一個擁有者時，繼續找其他的。
創辦人與客戶之間沒有人的點子，比看起來更有價值。要重視這個因素——接近「不合格」而非「扣分」的程度。
如果同一個殺手原因在某人的點子中反覆出現，那麼那個模式就是發現。先 針對這個篩選，在任何搜尋之前，然後省下那一小時。
困難的部分是程式碼嗎？
問問讓客戶滿意需要什麼條件。如果答案涉及在實體地點的可靠人員——檢查員、照護者、司機、倉庫員工——這是一個附帶軟體的營運生意。軟體只是簡單的10%。
這不代表它行不通。只是代表它和創辦人想開始的生意是不同類型，需要不同的技能、不同的資金，而且完全沒有軟體那種利潤率。
真正的瓶頸是什麼？
對於大多數在評估點子的人來說，瓶頸是與客戶交談，而不是想出點子。一個人有五個有希望的點子卻沒有進行任何客戶對話，他不需要第六個。如果這是模式，就直接說出來。
他們已經有什麼東西上線了？
某個已經打造好並發布但從未行銷的東西，通常會比從零開始新的點子更好。行銷一個存在的東西，是通往金錢的捷徑，而不是打造一個不存在的東西。如果情況如此，直接說出來，而不是單獨評判新點子。
第三步 — 裁決
已死還是擱置？ 使用這個判斷標準：阻礙因素有可能改變嗎？如果改變了，你會知道嗎？
- 一個規則、許可證、守門人的政策 → 已死。這些很少會變動，等待不是一個計畫。
- 缺少資金、缺少數據、缺少合作夥伴、時機不對 → 擱置，並寫下解鎖條件。
- 完整規模的版本已經存在並且死了 → 已死，而且這是最強烈的殺手證據。務必搜尋這個：市場已經用完整資金測試過這個點子，而答案是「不行」。
在解釋任何東西之前，用一句話挑選一個：
- 已死 —— 以及是什麼殺了它
- 擱置 —— 還活著但卡在某個特定事情上，以及什麼可以解鎖它
- 可行 —— 通過所有考驗，再加上一個最值得下一步測試的假設
對於任何未死的點子，命名最便宜的下一步測試——這個星期可以完成、不用打造任何東西、但仍然可能有殺傷力的事情。
對於你認定已死的點子，提供一個反證：最能證明你錯了的最便宜方法，以及你預期會發生什麼。「這個星期免費手動配對五個——我預期你填不滿五個」不用花任何錢，尊重你可能是錯的，而且通常幾天內就能解決。這不是救援計畫：沒有打造，沒有轉向。
寫下裁決
點子會回來。同一個點子，或它的親戚，幾個月後會帶著重置的熱情再次出現。寫下決定和原因——「在四月被中央銀行的單一主體規則殺死」是可重複使用的。「看起來不怎麼樣」則不是。
為此保留一個檔案，放在你以後會找到的地方。如果他們已經有專案筆記，就追加到那裡。如果沒有，就在工作目錄中建立 idea-log.md 並說明位置——「寫下來」如果沒有指定位置，通常就默默地變成了沒有。
## <點子，一行> <日期>
裁決：已死 | 擱置 | 可行
被殺死 / 卡在：<具體的事情>
重要的搜尋：<哪些，以及結果>
在搜尋之前，將新點子與列表對照。如果同一個殺手原因一直出現，那個模式比殺死第十個版本更有價值——直接說出來，而不是再跑一次這一小時。
範例
**點子：**一個為小店對帳刷卡機付款的應用程式。
competitors pricing→ 有幾個，都是企業級定價。看起來有缺口。free alternative→ 機器供應商提供免費的基本對帳單。削弱了它。regulation <年份>→ 中央銀行現在要求每個商家只能透過一個主體進行交易。 這個產品需要的數據第三方再也無法取得了。
已死，在第三個搜尋時。 注意前兩個搜尋讓它看起來還行。光靠競爭者研究會讓三個月的開發工作亮綠燈。