Prioritize

This is the part I explain worst and the part that most decides how everything ends up.

Building something small and building the least that answers your question look like the same thing, but they aren't, and confusing them costs months.

The difference that gets expensive

A small but complete product, with its sign up, its settings and everything else, can't be thrown away because it cost too much, and can't be kept because it isn't good enough. You end up maintaining something you no longer want, and that's worse than having started late. Adding hours doesn't fix it.

The least that answers your question is a different thing. It's the smallest object you can put in front of somebody to find out whether your assumption holds. It can be ugly, it can be half finished, and it can require you to do by hand behind it what the system would do later.

The first is built to last; the second, to answer a question and disappear. That's why one ends up tying you down and the other doesn't.

Write down what would make you stop

The only thing that has worked for me is writing down, before starting, what result would make me stop. One sentence is enough: if fewer than this many of the people I show it to have already done something about this problem, I drop it.

If I write it down beforehand, it's a decision. If I think about it afterwards, it turns into a negotiation with myself that I always win, because by then I've grown fond of it and any result admits a kind reading.

That's what makes all the advice about killing your darlings useless at exactly the moment you need it: by then the cost of stopping looks enormous, and what makes it look enormous is precisely what is already lost either way.

The date as a tool

A date helps too, if you treat it as a limit that doesn't take argument. I don't mean it as pressure, but as the most honest way I know of deciding what stays out.

Scope with no date expands until it fills the time available, and since there's never a moment where you have to choose, you never choose. With a fixed date the conversation changes: it stops being what could we add and becomes what fits.

What I cut first

What I cut most is everything that exists because a product is supposed to have it. Sign up, profile, settings, password recovery, admin panel. None of it answers your question and all of it costs weeks.

Then, any case that isn't the central one. The user who does things in a different order, the one with a large team, the one who needs to export. They all exist and none of them matters yet.

And last, automation. If you can do it by hand behind the scenes for the first few weeks, do it by hand. You'll move more slowly, but you'll learn much faster.

Why it resembles tending a garden

The whole thing resembles tending a garden. You can't make anything grow by force of will: you prepare the conditions and remove what is competing for the space.

It works the same here. You can't make anybody want what you made, you can only keep taking away what is in the way. And of what you take away, almost none of it's ever needed again, which is the part that surprised me most the first few times.

Questions people ask about this