Thin Slice
The goal of v1 is not to cover every feature. It's to let one real person complete one full thing once.
- 做了三周,还没有任何一个流程能从头走到尾
- 页面画了七八个,没有一个能真的用
- 越做越大,迟迟不敢拿给人看
Slicing horizontally is the most natural and the most dangerous approach: finish all the UI, then all the APIs. It sounds orderly, but until everything's done, you have nothing you can validate. Slicing vertically is the opposite—as soon as the first slice is done, someone can use it, and real feedback starts coming in.
How to cut
Cut along one complete user task, not along technical layers.
| 这样切 | 第一片是什么 | 做完之后能验证什么 |
|---|---|---|
| 按用户任务(竖) | 记一笔账,从打开到存下来 | 这个流程顺不顺,人愿不愿意再来一次 |
| 按技术层(横) | 所有页面的静态界面 | 什么都验证不了,只能看好不好看 |
| 按功能模块 | 整个「记录模块」的全部能力 | 能验证记录,但用户没法完成一件完整的事 |
How small
The bar isn't "few features," it's "can run end-to-end once." The cuts below are safe to make.
What you can't cut
- The main thread's completeness can't be cut. You can drop a few entry points, but the path from start to finish has to work.
- The four states can't be cut. Empty, loading, error, normal. Your first users all hit the empty state — cutting it means cutting your first impression (see All Four States).
- Data reliability can't be cut. Fewer features is fine; lost data is not.
- The hypothesis you're validating can't be cut. The whole point of this slice is to test it — cut it and the work was for nothing.
Note for the AI
我要做:[产品一句话] 第一版我想验证的假设是:[比如「他愿意每天花十秒记一笔」] 请帮我切出第一个切片,要求: 1. 沿一次完整的用户任务竖着切,不要按前端/后端/数据库分层。 2. 列出这一片包含的最小页面数和最小数据字段,能砍的都砍掉。 3. 明确列出这一版不做的东西,以及为什么现在不需要它。 4. 单独确认这几项有没有保留:主流程能否走完、四种状态是否齐全、 数据会不会丢、关键操作能否撤销。 5. 估一下这一片的工作量级(小时 / 天 / 周)。如果超过一周, 请再切一次,告诉我怎么切更小。 先给方案,我确认后再写代码。
The fifth line is the key to preventing scope creep. If the AI's plan comes out as "week-scale" from the start, it has probably padded in a bunch of extras for you.
