幫你快速排定產品功能順序，少踩雷、也不怕用戶看不懂，直接帶來市場回饋。
- 先圈出前 5 個你覺得「非做不可」的功能，馬上對比現有用戶投票，數字高於 60%再留。
這種抓重點的方法能直接避開功能焦慮，大家往往一次只需要兩三個核心功能（7 天後看用戶調查回覆率有沒有破 50%）。
- 直接用 MoSCoW 法，5 分鐘內把所有功能劃分四類：必須要有、應該有、可以有、不要有。
把功能分清楚就能快速看出哪一個才是真的用得到，避免大家常常越做越多但卻沒人用（每週追蹤後端日活功能點擊率，top 2 顯著高出其餘功能 1.5 倍）。
- 每週挑 1 個新功能，限定 14 天內找 10 位用戶聊聊，看他們理解難度如何，太多說不清就砍掉。
功能要能讓用戶 10 秒內說出用途，不然容易卡在溝通障礙（14 天後記錄實測用戶能不能順利說明用途，至少 8/10 才算過）。
- 開始從80/20原則下手，只保留會影響最多 80% 用戶體驗的 20%核心功能，直接砍掉冷門。
功能少一點，團隊資源集中，反而用戶滿意度會明顯提升（30 天後比較新舊版本 NPS，核心版提升至少 1 分）。
找到方法避免產品功能焦慮與過度堆疊
這個現象好像大家都會遇到，嗯，叫Feature FOMO死亡螺旋吧。創業者常常在想到底該先做什麼，然後東加一點、西塞一點，最後搞到完全收不住手，有時真的覺得有點煩啦。本來只是想造個腳踏車，結果各種聲音一來，好像變成要生出一台會飛的怪東西，蠻離譜。
說實話，有時候凌晨三點突然靈感閃一下，「就是這功能了！」欸，好嗨哦，但馬上又會想，是不是該先問用戶。嗯，所以只好跑去找幾個潛在客戶問問。第一位超興奮：「哇酷耶，不過能不能再多弄個跟主題沒關的？」第二個很直接：「其實很棒啊，可是如果加新功能應該更好」，聽起來那要做半年吧。還有第三個很佛系：「其實可以把Facebook那套通通放進來就無敵了」…你看看，每次好的MVP全被莫名其妙的新需求堆到動不了，最後大概就是這樣被Feature FOMO吃掉啦。
說實話，有時候凌晨三點突然靈感閃一下，「就是這功能了！」欸，好嗨哦，但馬上又會想，是不是該先問用戶。嗯，所以只好跑去找幾個潛在客戶問問。第一位超興奮：「哇酷耶，不過能不能再多弄個跟主題沒關的？」第二個很直接：「其實很棒啊，可是如果加新功能應該更好」，聽起來那要做半年吧。還有第三個很佛系：「其實可以把Facebook那套通通放進來就無敵了」…你看看，每次好的MVP全被莫名其妙的新需求堆到動不了，最後大概就是這樣被Feature FOMO吃掉啦。
搞懂為什麼用戶需求不等於好產品方向
你知道嗎，問用戶想要什麼新功能，感覺就像跟小孩問今天晚餐吃什麼一樣。嗯，他們八成說冰淇淋、披薩、巧克力蛋糕，還想加個獨角獸？其實真的不太可能滿足啊，欸，不能直接送上一堆糖分的東西啦。獨角獸...這想法是有點可愛沒錯。
Henry Ford之前那句話嘛，「如果我問大家要什麼，只會說更快的馬。」不是他囂張，算了，也沒有那麼偉大啦，但這就是事實，用戶會抱怨問題很行，可是真要出解法就不行。大概是設計東西跟發現痛點根本兩件事。
怎麼說？舉個例好了，有人跑來說：「我希望有暗黑模式，而且AI還能根據我的情緒跟房間燈光自動變換主題色！」喔，但其實原因應該就只有螢幕晚上太亮眼睛不舒服啦。沒必要搞這麼花俏對吧。
然後，「驗證悖論」又來湊熱鬧了。簡單說啦，你先去問10個人需求，不小心就收回來47條天馬行空的願望清單（老實講，一堆邏輯都亂掉，還挺像創業早期會發生的事），結果就是，每一項都想照顧，只因為怕有人不開心，你就全做了...嗯，大概這樣。
Henry Ford之前那句話嘛，「如果我問大家要什麼，只會說更快的馬。」不是他囂張，算了，也沒有那麼偉大啦，但這就是事實，用戶會抱怨問題很行，可是真要出解法就不行。大概是設計東西跟發現痛點根本兩件事。
怎麼說？舉個例好了，有人跑來說：「我希望有暗黑模式，而且AI還能根據我的情緒跟房間燈光自動變換主題色！」喔，但其實原因應該就只有螢幕晚上太亮眼睛不舒服啦。沒必要搞這麼花俏對吧。
然後，「驗證悖論」又來湊熱鬧了。簡單說啦，你先去問10個人需求，不小心就收回來47條天馬行空的願望清單（老實講，一堆邏輯都亂掉，還挺像創業早期會發生的事），結果就是，每一項都想照顧，只因為怕有人不開心，你就全做了...嗯，大概這樣。
辨識用戶真正痛點而非表面功能建議
天啊欸，超爆有感 - 你如果什麼都想塞進去，真的，最後就是四不像啦！用戶根本只會抱怨：「啊，這也太亂了吧」還有「那個功能怎麼雞肋成這樣？」說認真，那根本自找麻煩，然後結果是，每一項都半吊子。大堆頭就像那什麼瑞士刀，有47個神奇小工具沒錯，但哪次迷你那刀片真拿來用過？牛排館掏出來只會被朋友笑。
哦講重點！直接丟出比較靠譜的玩法啦 - 其實這結構行得通！（嗯…應該算合理、我不騙）
第1步，「問題火力全開搜尋」！！別再啥都問「你想要哪些功能」啦。試著改成：「[某任務]你最卡關在哪？」、「演示一下你現在實際操作」，或者問「哪件事超級不爽，只要錢到位寧願外包掉？」—順便說，有時嘴巴講很愛健康、可是點擊率最高的卻永遠都是繽紛大按鈕。不信？多觀察，比光聽更準！
再來是第2步：MoSCoW法則版本升級哈哈，把功能全分門別類：
MUST have - 沒有就GG（即時通訊app不能發訊息…直接祭天吧）
SHOULD have - 不錯很重要，但初版沒有也不死人（比如已讀小通知，看了更焦慮，行，也行）
COULD have - 有最好，不急，有餘力加上（自訂emoji就是了）
WON’T have - 此刻遺忘它！未來隨便等，也不用強求（例如區塊鏈通通算了…除非主攻區塊鏈領域）
第3步必須記得！老規矩80/20定律！！八成用戶實際玩就只玩兩成頂尖主功能，好嘛，把精華放大，不要求全求「神」—拚到極致最有效率！
哦講重點！直接丟出比較靠譜的玩法啦 - 其實這結構行得通！（嗯…應該算合理、我不騙）
第1步，「問題火力全開搜尋」！！別再啥都問「你想要哪些功能」啦。試著改成：「[某任務]你最卡關在哪？」、「演示一下你現在實際操作」，或者問「哪件事超級不爽，只要錢到位寧願外包掉？」—順便說，有時嘴巴講很愛健康、可是點擊率最高的卻永遠都是繽紛大按鈕。不信？多觀察，比光聽更準！
再來是第2步：MoSCoW法則版本升級哈哈，把功能全分門別類：
MUST have - 沒有就GG（即時通訊app不能發訊息…直接祭天吧）
SHOULD have - 不錯很重要，但初版沒有也不死人（比如已讀小通知，看了更焦慮，行，也行）
COULD have - 有最好，不急，有餘力加上（自訂emoji就是了）
WON’T have - 此刻遺忘它！未來隨便等，也不用強求（例如區塊鏈通通算了…除非主攻區塊鏈領域）
第3步必須記得！老規矩80/20定律！！八成用戶實際玩就只玩兩成頂尖主功能，好嘛，把精華放大，不要求全求「神」—拚到極致最有效率！
掌握實用的MoSCoW法排序產品優先順序
嗯…功能怎麼挑？欸，就是你先腦海裡能想的，全部列下來啦，別省。寫完之後，你想一下喔，如果只准你留一個，哪一個會讓人家看到直接說，「拜託閉嘴，錢都給你了」。如果有那種反應，大概八成就是重點功能。
對，其實很直觀啦。挑出來後，就再回頭看看其它。重複一次，選第2、第3強的，不用太多，也別猶豫什麼了啦。真的不用再拖，一直加也只是自己亂；夠了，就這樣。我不開玩笑啊，有時候該停手。
另外…欸，「The Mom Test」那個，也算滿重要。講法其實超簡單 - 你就拿著這feature，試著10秒以內直接跟媽媽解釋一遍。如果她覺得懂，那才叫OK。可是如果是像什麼「我們用區塊鏈結合AI再搞組織優化」，媽啊，大部分媽媽聽到應該傻眼吧？這種描述…唉，不過是嘛，誰懂啦。
對，其實很直觀啦。挑出來後，就再回頭看看其它。重複一次，選第2、第3強的，不用太多，也別猶豫什麼了啦。真的不用再拖，一直加也只是自己亂；夠了，就這樣。我不開玩笑啊，有時候該停手。
另外…欸，「The Mom Test」那個，也算滿重要。講法其實超簡單 - 你就拿著這feature，試著10秒以內直接跟媽媽解釋一遍。如果她覺得懂，那才叫OK。可是如果是像什麼「我們用區塊鏈結合AI再搞組織優化」，媽啊，大部分媽媽聽到應該傻眼吧？這種描述…唉，不過是嘛，誰懂啦。
運用80/20法則聚焦打造關鍵核心功能
你知道嗎，有時候要講明白一件新服務，像這樣說：「Uber版的遛狗服務」，其實就超級直觀啊。馬上get到意思對吧？假如你媽都能秒懂，八成用戶也會明白。可要是你媽直接一臉懷疑看你，嗯，那多半搞不好自己想複雜了啦。
然後評估新功能，其實流程很清楚：每項功能，可以打兩組分數 - 影響分跟努力分，各三個小項目，全都1～5分自己選。影響分怎麼來？第一，看用戶體感爽不爽；第二，看能不能正中核心問題、直接解；第三，思考這功能有沒有特色或差異化賣點。
再看努力分：一、開發會花多少時間（寫起來到底累不累）；二、後面維護煩不煩，有沒有技術債那種；三、做下去可能爆出什麼其他麻煩或未知風險。
啊重點公式記一下：
Priority Score = (Impact Score × 2) - Effort Score
Impact為什麼要乘2？其實大多數新創產品根本就是先衝impact，用戶有需求才是真的！等需求穩了，工程那些慢慢優化啦，沒人在意那種「還沒人要」的空氣優化方案喔。
排序很簡單啦。大於10 - 不用想直接幹（BUILD THIS NOW），如果5到10之間，就先加進Soon™️清單當備案等一下。不到5就，不好意思，目前冰封等哪天公司真的變unicorn再回頭翻Maybe when we're unicorns資料夾啦。
欸，對了，其實蠻多人常掉心理陷阱耶，例如「Real Talk: The Psychological Traps You're Falling Into」。所以最後還是建議冷靜照上表分析，每個環節過濾清楚，不然很容易腦衝結果出大包呢！
然後評估新功能，其實流程很清楚：每項功能，可以打兩組分數 - 影響分跟努力分，各三個小項目，全都1～5分自己選。影響分怎麼來？第一，看用戶體感爽不爽；第二，看能不能正中核心問題、直接解；第三，思考這功能有沒有特色或差異化賣點。
再看努力分：一、開發會花多少時間（寫起來到底累不累）；二、後面維護煩不煩，有沒有技術債那種；三、做下去可能爆出什麼其他麻煩或未知風險。
啊重點公式記一下：
Priority Score = (Impact Score × 2) - Effort Score
Impact為什麼要乘2？其實大多數新創產品根本就是先衝impact，用戶有需求才是真的！等需求穩了，工程那些慢慢優化啦，沒人在意那種「還沒人要」的空氣優化方案喔。
排序很簡單啦。大於10 - 不用想直接幹（BUILD THIS NOW），如果5到10之間，就先加進Soon™️清單當備案等一下。不到5就，不好意思，目前冰封等哪天公司真的變unicorn再回頭翻Maybe when we're unicorns資料夾啦。
欸，對了，其實蠻多人常掉心理陷阱耶，例如「Real Talk: The Psychological Traps You're Falling Into」。所以最後還是建議冷靜照上表分析，每個環節過濾清楚，不然很容易腦衝結果出大包呢！
判斷新功能是否易於傳達和理解給用戶
先來Trap #1！IKEA效應爆擊登場！你有沒有過組完IKEA桌子就覺得超級無敵讚？但，事實講啦，就是紙板一堆 - 喔，我沒有嗆你，大家都會愛自己動手做的東西啊哈哈哈。重點是，大腦真的會鬼打牆！要破解這種自戀小陷阱超簡單啦：立刻找一個根本不甩你面子的同事，直接讓他當feature大法官。欸他說難聽話就讓他講！這種人往往才是真的救命恩人，比假讚美更有效。
Trap #2轉場～沉沒成本迷思來了。有時會猶豫：「欸，我們搞這功能都忙2週，乾脆硬幹吧？」拜託等一下、想一下行不？真正慘的，不是兩週泡湯，而是做到底結果再多浪費2個月、最後完全沒人用 - 那才真的虧到哭爆欸！反省一下，要勇敢停損啊，不然後悔。
然後Trap #3：競品恐慌正式現身。「唉呦，那家對手也有這功能耶！」所以勒，他們賺錢嗎？他們user很爽嗎？還是只是瘋狂亂塞新功能當寶可夢集卡遊戲玩？？認真問，你又不是在跟別人比誰按鈕多，只專注衝數量有屁用啊。記住喔，你要的是實用，不是大雜燴（信我一次）。
Trap #2轉場～沉沒成本迷思來了。有時會猶豫：「欸，我們搞這功能都忙2週，乾脆硬幹吧？」拜託等一下、想一下行不？真正慘的，不是兩週泡湯，而是做到底結果再多浪費2個月、最後完全沒人用 - 那才真的虧到哭爆欸！反省一下，要勇敢停損啊，不然後悔。
然後Trap #3：競品恐慌正式現身。「唉呦，那家對手也有這功能耶！」所以勒，他們賺錢嗎？他們user很爽嗎？還是只是瘋狂亂塞新功能當寶可夢集卡遊戲玩？？認真問，你又不是在跟別人比誰按鈕多，只專注衝數量有屁用啊。記住喔，你要的是實用，不是大雜燴（信我一次）。
快速評分每項功能，決定開發優先級別
欸說到想真的幫用戶解決問題，其實我覺得關鍵還是在能不能找到最有感的那個方案啦。有一套叫「Holy Grail」的驗證方法真的滿實用的，之前聽過很多人在創業社群都拿來推，蠻值得大家直接照這流程來走一次！
首先啊，第1週主要在做所謂的問題探索。直接衝去找10個潛在用戶，一定要是面對面訪談喔，不要以為丟份問卷就能搞定。因為你想要了解的根本不是什麼他們嘴上想的新功能，而是那些讓他們卡住、崩潰的具體情境。聊一聊記下重點之後，可以觀察一下是不是有三個以上的人都有同種困擾。欸如果真有出現這種共通模式，那應該很可能就是真的市場需求了。
然後到了第2週啦，就拿最關鍵那3個痛點隨手用Figma做幾張mockup吧，真的別再搞PowerPoint，會被設計師笑到翻😆。畫完找剛剛那批受訪者過來，給他們直接反饋。千萬不要插嘴，靜靜看對方反應超有戲。如果有人臉亮了起興奮，嗯這方向沒錯。如果全部都無感…就只好老實說要趕緊回頭檢討。
等進到第3週，「Fake Door Testing」時間啦。簡單說就是先搭個Landing Page，把新feature亮相放好，再加顆「Coming Soon」按鈕看看。不需要系統真會動，只想測到底多少人會去點，也就知道這東西到底是不是表面熱度還是真的被渴望。
最後第4週也滿狂，叫「Build the Ramen Version」。意思其實就是只先開發出超陽春版，可以動但不完整，不要丟臉你都不敢給朋友看才對勁。如果這版成品一出來，你已經興高采烈地大秀四方，那九成都塞了不少沒必要的小功能XD
驗證標準也超直白喔，如果有40%的試用者超熱愛喊「非得不可」，立馬推進下階段！只有20–40%的話，看要微調或刪減東西繼續試；低於20%不用猶豫，直接換主題吧（「Kill it with fire」這句可不是開玩笑）。
另外，他們還推薦了一份「Ultimate Feature Decision Checklist」，真的滿機車卻很務實：首先，一句話講得清楚嗎？再來，有讓核心價值變強？這輪不上線會怎樣嗎？超過80%用戶天天要用才算數喔，不然就是多餘功能而已。另外能兩個sprint完成最好，再不能拆得再細。不是真痛就不用急著上！最後題目超狠，如果賭一千塊美金你敢壓這東西能紅嗎？不敢那算了。
啊對，其實大家常提一句Steve Jobs從沒跑民調問iPhone會不會紅，所以結果根本不是瞎問，而是一步步紮實驗證走過來才能信心滿滿出手！
首先啊，第1週主要在做所謂的問題探索。直接衝去找10個潛在用戶，一定要是面對面訪談喔，不要以為丟份問卷就能搞定。因為你想要了解的根本不是什麼他們嘴上想的新功能，而是那些讓他們卡住、崩潰的具體情境。聊一聊記下重點之後，可以觀察一下是不是有三個以上的人都有同種困擾。欸如果真有出現這種共通模式，那應該很可能就是真的市場需求了。
然後到了第2週啦，就拿最關鍵那3個痛點隨手用Figma做幾張mockup吧，真的別再搞PowerPoint，會被設計師笑到翻😆。畫完找剛剛那批受訪者過來，給他們直接反饋。千萬不要插嘴，靜靜看對方反應超有戲。如果有人臉亮了起興奮，嗯這方向沒錯。如果全部都無感…就只好老實說要趕緊回頭檢討。
等進到第3週，「Fake Door Testing」時間啦。簡單說就是先搭個Landing Page，把新feature亮相放好，再加顆「Coming Soon」按鈕看看。不需要系統真會動，只想測到底多少人會去點，也就知道這東西到底是不是表面熱度還是真的被渴望。
最後第4週也滿狂，叫「Build the Ramen Version」。意思其實就是只先開發出超陽春版，可以動但不完整，不要丟臉你都不敢給朋友看才對勁。如果這版成品一出來，你已經興高采烈地大秀四方，那九成都塞了不少沒必要的小功能XD
驗證標準也超直白喔，如果有40%的試用者超熱愛喊「非得不可」，立馬推進下階段！只有20–40%的話，看要微調或刪減東西繼續試；低於20%不用猶豫，直接換主題吧（「Kill it with fire」這句可不是開玩笑）。
另外，他們還推薦了一份「Ultimate Feature Decision Checklist」，真的滿機車卻很務實：首先，一句話講得清楚嗎？再來，有讓核心價值變強？這輪不上線會怎樣嗎？超過80%用戶天天要用才算數喔，不然就是多餘功能而已。另外能兩個sprint完成最好，再不能拆得再細。不是真痛就不用急著上！最後題目超狠，如果賭一千塊美金你敢壓這東西能紅嗎？不敢那算了。
啊對，其實大家常提一句Steve Jobs從沒跑民調問iPhone會不會紅，所以結果根本不是瞎問，而是一步步紮實驗證走過來才能信心滿滿出手！
避免陷入創業常見心理陷阱及盲點
說到這件事喔，他那時候的觀察超有意思，就是很多人很受不了要帶一堆裝置出門欸，手機、iPod、相機，每樣都塞口袋裡，超煩對吧？再講一下，其實當時大家也沒多愛智慧型手機啦，像Blackberry，被批得滿慘。嗯，很多人還是很希望可以無限制上網吧，不想被綁著走。
其實Steve Jobs的重點是在解決「真正的問題」啊，不是丟出一串功能清單給團隊。什麼49個需求說穿了，可能只是真的三、四個根本困擾而已。有沒有搞錯，那些痛點釐清才算抓到關鍵，剩下細節都是雜訊沒必要多管。他用篩選法過濾掉多餘內容，真的專注下去比較有效。
喔講個重點，比方有三項設計做到極致，就是屌打那種又雜又不夠好的三十項啊。「A product with 3 features that work perfectly beats a product with 30 features that work 'okay.'」對這句我覺得你可以記起來，非常有感。
那怎麼執行咧？呃很簡單啦，你乾脆先把所有想得到的功能全部寫下來，包括那種半夜突然蹦出的怪主意都別放過，好像可不可能也沒差。
下一步就是照Priority Score公式去排分數啊，每個條目都排一下就知道啦。基本上拉出前面最亮眼的前三名功能即可，不必堆滿整桌子！
喔接著重要的一步，要做Fake Door Test，就是丟出去看用戶會不會回應那些你覺得特別猛的功能。如果反應低迷，大概是假需求，要換掉就好。
最後步驟很直接，你把經過驗證、分數衝最高的功能搞到最好，再馬上讓所有人能用！不要再拖啦，「Ship it」，行動快才是真的贏家。
其實Steve Jobs的重點是在解決「真正的問題」啊，不是丟出一串功能清單給團隊。什麼49個需求說穿了，可能只是真的三、四個根本困擾而已。有沒有搞錯，那些痛點釐清才算抓到關鍵，剩下細節都是雜訊沒必要多管。他用篩選法過濾掉多餘內容，真的專注下去比較有效。
喔講個重點，比方有三項設計做到極致，就是屌打那種又雜又不夠好的三十項啊。「A product with 3 features that work perfectly beats a product with 30 features that work 'okay.'」對這句我覺得你可以記起來，非常有感。
那怎麼執行咧？呃很簡單啦，你乾脆先把所有想得到的功能全部寫下來，包括那種半夜突然蹦出的怪主意都別放過，好像可不可能也沒差。
下一步就是照Priority Score公式去排分數啊，每個條目都排一下就知道啦。基本上拉出前面最亮眼的前三名功能即可，不必堆滿整桌子！
喔接著重要的一步，要做Fake Door Test，就是丟出去看用戶會不會回應那些你覺得特別猛的功能。如果反應低迷，大概是假需求，要換掉就好。
最後步驟很直接，你把經過驗證、分數衝最高的功能搞到最好，再馬上讓所有人能用！不要再拖啦，「Ship it」，行動快才是真的贏家。
執行四週高效驗證流程確保市場需求
唉，其實產品這種東西啊，真的不要只靠腦袋自己幻想啦。你腦子轉破也沒什麼用，沒數據都是白搭。有數字擺在那裡，用戶怎麼點、哪裡卡關一清二楚。所以與其猜測，不如乾脆根據用戶實際行為直接改比較快吧？光想沒有意思。
隨便說一句，不要老是在那邊磨來磨去，一定要上線的版本才有意義欸。「Ship beats perfect. Every. Single. Time.」不唬爛，每次都是這樣。完美主義太麻煩了，拖來拖去反而錯過時機。喔，你還在糾結的話，很可能都比別人慢了啦。
簡單列一下 - 因為我懶得多講：1，用戶其實自己講不清楚需求，狀況一堆啦；2，新功能多，不代表你的產品一定會好；3，還是得先確定痛點再想解法；4，別亂塞一堆東西，好用才是重點，能做少就少，多了以後再加吧。
反正講半天，不如直接看數據決定事情啊。有問題嗎？推上線測最直接。很多時候第一版很陽春很糗，但你硬是不推，那可能就是永遠推不上去了耶！
算了，我說真的，把你那份feature list砍掉70%好不好？相信我，以後回頭看你一定會感謝現在動手刪除的自己。新創公司本來就是死掉一大堆功能才成功的，有垃圾就要馬上丟啊。「Fail fast, fail often, but for the love of all that is holy, please fail CHEAP.」老話是真的。失敗可以但錢不要亂花哦。
隨便說一句，不要老是在那邊磨來磨去，一定要上線的版本才有意義欸。「Ship beats perfect. Every. Single. Time.」不唬爛，每次都是這樣。完美主義太麻煩了，拖來拖去反而錯過時機。喔，你還在糾結的話，很可能都比別人慢了啦。
簡單列一下 - 因為我懶得多講：1，用戶其實自己講不清楚需求，狀況一堆啦；2，新功能多，不代表你的產品一定會好；3，還是得先確定痛點再想解法；4，別亂塞一堆東西，好用才是重點，能做少就少，多了以後再加吧。
反正講半天，不如直接看數據決定事情啊。有問題嗎？推上線測最直接。很多時候第一版很陽春很糗，但你硬是不推，那可能就是永遠推不上去了耶！
算了，我說真的，把你那份feature list砍掉70%好不好？相信我，以後回頭看你一定會感謝現在動手刪除的自己。新創公司本來就是死掉一大堆功能才成功的，有垃圾就要馬上丟啊。「Fail fast, fail often, but for the love of all that is holy, please fail CHEAP.」老話是真的。失敗可以但錢不要亂花哦。
落實產品精簡思維，只留下真正有價值的功能
1. 你還有打算弄什麼AI情緒偵測暗黑模式嗎？OK啦，想玩就玩。可是欸，先等一下，能不能先好好把一般的暗黑模式處理好呢？這裡真的很拜託，不是隨便講講，是發自內心那種。
2. 作者自己，經歷太多了吧。各種創辦人，一下子腦袋一熱要開發Uber版亂七八糟產品，大概沒有人真的需要，偏偏每次都親眼目睹，全程參與那樣。現在呢，他在AppUp Labs協助別的創業者 - 講直白點，有時候是在幫大家分析哪些想法千萬不要衝動下去。然後啊，有個弔詭現象，就是「判斷哪個不應該做」往往還比決定「到底要做啥」來得更傷腦筋。
2. 作者自己，經歷太多了吧。各種創辦人，一下子腦袋一熱要開發Uber版亂七八糟產品，大概沒有人真的需要，偏偏每次都親眼目睹，全程參與那樣。現在呢，他在AppUp Labs協助別的創業者 - 講直白點，有時候是在幫大家分析哪些想法千萬不要衝動下去。然後啊，有個弔詭現象，就是「判斷哪個不應該做」往往還比決定「到底要做啥」來得更傷腦筋。
