How small should your MVP be?

Three classic answers from YC, Paul Graham and Steve Blank on scoping a first version that ships in weeks, not months.整理 YC、Paul Graham 和 Steve Blank 的三個經典答案：第一版就該小到讓你有點不好意思。

Every founder asks this at some point: how much do we build before we show anyone? The three essays below have answered it for a decade of startups, and they agree more than you would expect.

Start from the launch date, not the feature list

Michael Seibel’s YC talk flips the usual planning order. Pick a launch date a few weeks out, list what one specific user needs to get one specific job done, and cut everything that does not fit. The MVP is whatever survives that deadline. Scope serves the date, never the other way around.

Do things that don’t scale

Paul Graham’s point is that your first version does not need to serve a thousand users, because you do not have a thousand users. Recruit users one by one, onboard them by hand, and let the unscalable work teach you what the product should automate later. A tiny product plus heroic manual service beats a complete product nobody asked for.

Perfection by subtraction

Steve Blank frames the minimum feature set as a test of your riskiest assumption, not a smaller product. You are not building less because you are lazy; you are building less so the market can answer one question quickly. If the first version does not embarrass you a little, you waited too long.

What you need before you start

One sentence describing the single user and the single job the first version serves
A launch date within six weeks, treated as fixed
The one assumption that kills the project if wrong, written down
A way to talk to the first ten users directly, by hand
A list of everything you decided not to build, kept visible

The takeaway

An MVP is what survives a fixed launch date, not a feature list
Manual, unscalable service is a feature of the MVP stage, not a flaw
Ship when it still embarrasses you a little; that is the signal you are early enough

每個創辦人都問過這題：做到什麼程度，才能拿出去給人看？下面這三篇文章回答了十年來無數新創的這個問題，而且答案出乎意料地一致。

從上線日期回推，不是從功能清單出發

Michael Seibel 在 YC 的分享把常見的規劃順序整個翻過來：先訂一個幾週後的上線日，列出「一種特定使用者完成一件特定任務」需要什麼，其他全部砍掉。MVP 就是活過那個死線的東西。範圍配合日期，永遠不是日期配合範圍。

做不能規模化的事

Paul Graham 的重點是：第一版不需要服務一千個使用者，因為你根本還沒有一千個使用者。一個一個把使用者找進來，親手幫他們上手，讓這些不能規模化的苦工告訴你，產品之後該把什麼自動化。小產品加上英雄式的手動服務，勝過一個沒人要的完整產品。

用減法逼近完美

Steve Blank 把最小功能集定義成「對最大風險假設的一次測試」，而不是縮小版的產品。你做得少，不是因為偷懶，是為了讓市場能快速回答你一個問題。如果第一版沒有讓你有點不好意思，代表你等太久了。

開始之前，你需要準備的東西

一句話說清楚：第一版服務哪一種人、解決哪一件事
一個六週內的上線日期，而且當作不可移動
寫下那個「如果錯了整個案子就不成立」的假設
一個能直接、親手接觸前十個使用者的管道
一張「決定不做」的清單，放在看得到的地方

總結

MVP 是「活過固定上線日的東西」，不是功能清單
手動、不能規模化的服務是 MVP 階段的特色，不是缺陷
在還有點不好意思的時候上線，那正是「夠早」的訊號

How small should your MVP be?MVP 到底該多小？