Plan backwards from the impact you want

Stop planning features from a blank page. Start from the specific impact you want, then work backwards into growth, MVP scope, and daily decisions.別再從功能清單開始規劃，先說清楚你要創造的影響力，再往回推導成成長策略、MVP 範圍與每天的選擇。

Planning from a blank page invites noise. Planning backwards from impact forces you to say who should care, how their life changes, and what proof would convince you it is working, before you touch a roadmap.

Start from the growth curve you actually want

Paul Graham points out that startups are defined by growth, not by having an app or a launch date. When you start from the impact you want, you can translate it into a concrete growth pattern, for example a certain compounding weekly growth, and then ask what behavior must change to support it. Planning backwards is choosing which small, real behavior change today could plausibly compound into that future line.

Design your MVP as the smallest proof of impact

Y Combinator describes an MVP as the simplest thing that lets you start the learning loop with real users. If you plan backwards from impact instead of forwards from features, your MVP becomes a sharp question: what is the minimum product that can create this one measurable change in someone’s life. The scope is no longer a wishlist, it is a test rig that either produces the impact signal or proves your assumptions wrong.

Use constraints as a filter for what really matters

Marc Andreessen argues that almost every strong startup is constrained by something, usually time, cash or distribution. Planning backwards from impact lets those constraints cut scope instead of cutting ambition, you keep the impact target, but you aggressively simplify how you get there. Under hard limits, the question becomes which one or two product moves create most of the desired impact for this specific audience.

Your pre roadmap checklist

One sentence that names the user, the problem, and the change you want in their behavior
A simple metric that would prove the impact is happening, written with a number and a time frame
A guess for the smallest interaction that could move that metric, even a manual one
A list of things you will explicitly not build in the first version, and why
A growth story that connects your early impact to a plausible compounding curve

The takeaway

Start from a concrete impact and implied growth curve, then decide which behavior must change
Define your MVP as the smallest reliable way to produce and measure that impact
Let constraints shrink the path, not the ambition, and cut everything that does not move the metric

從空白頁開始規劃，很容易被功能清單推著走。從影響力往回規劃，會逼你先講清楚誰應該被改變、他的生活要怎麼變、要看到什麼證據才算成功，之後才輪到 Roadmap 出場。

先說清楚，你要的是哪一條成長曲線

Paul Graham 提醒，新創的本質在成長，不在於「有沒有做出一個產品」。如果你從想要的影響力出發，就可以把它轉成具體的成長型態，例如一個合理的週成長率，然後反推要改變哪些使用行為才有機會達到。以終為始在問的其實是：今天可以促成哪一個小小但真實的行為改變，未來有機會複利成那條曲線。

MVP 是「最小可驗證的影響力」

Y Combinator 把 MVP 定義為能讓你開始和真實使用者進入學習循環的最簡產品。當你從影響力而不是功能往回推，MVP 就變成一個很銳利的問題：要讓某個人的生活出現哪一個可以量到的變化，才證明方向值得繼續。範圍不再是願望清單，而是一台測試機，要嘛打出清楚的影響訊號，要嘛幫你提早推翻假設。

把限制當成篩選器，保留真正關鍵的東西

Marc Andreessen 指出，多數厲害的新創都被某種限制卡住，通常是時間、資金或通路。從影響力往回規劃，可以讓這些限制切掉的是「做法」，而不是「野心」，你保留目標不縮水，改成無情簡化達成路徑。在壓力之下，真正的問題會變成：對這一群人，哪一兩個產品動作就能創造最多目標中的影響力。

開 Roadmap 之前的準備清單

一句話講清楚：是哪一種使用者、什麼問題、你要改變他的哪個行為
一個能證明影響正在發生的指標，用明確數字加上時間區間寫出來
一個你猜測可以推動這個數字的「最小互動」，就算是全手動也可以
一份你決定第一版「絕對不做」的清單，外加為什麼不做
一個把早期影響力連到可想像成長曲線的故事

總結

從具體影響力和隱含的成長曲線開始，再決定要改變哪個行為
把 MVP 定義成「最小、但穩定可產生並量到影響力」的東西
讓限制縮短路徑，而不是縮小野心，砍掉所有不會動到關鍵指標的功能

Plan backwards from the impact you want以終為始：從你要的影響力往回規劃