So, I’m not sure about breaking things, but building fast is always a good idea. You just have to go about doing it sensibly.
12/12

I’ve often released a small thing devoid of most of the features and bells and whistles I thought I needed, and the feedback was “this is great!” At that point, I’m done. Those bells and whistles were cruft. Build the thing that alleviates the most pain first, then get feedback.
11/12

The most dramatic speed improvements come from not building entire features that nobody wants. Work very small to get code into your customer’s hands as quickly as possible, and then get feedback from them in a continuous conversation. Why build things nobody cares about?
10/12

You do not need an architecture or infrastructure that supports 100,000 users until you have 100,000 users. You do need an incremental-friendly architecture--one that can evolve as it scales. Eminently doable, but it’s a learned skill.
9/12

If you have 100 customers, for example, you probably don’t need a database—a flat file with JSON in it will do. You almost certainly don’t need that slick UI (you need a good UX, but you can often get that with a very simple UI).
8/12

Whole-team development—where all the skills needed to get something out the door are available within the team—eliminates dependency delays.

The next set of speed improvements comes from not building infrastructure you don’t need.
7/12

The first is to change the way you work. Traditional Lean thinking—remove waste; work on one thing at a time (reduce WIP to 1)—cuts development time in half or more. Working collaboratively (e.g., mob/ensemble programming) eliminates coordination and integration overhead.
6/12

Also, buggy systems drive customers away. No startup can afford that. Buts erode trust, and attempts to regain that trust by releasing a slightly less buggy version in a month are doomed. People have long memories.

There are constructive ways to move fast, though.
5/12

Every change to buggy code is painful (and time-consuming), particularly when you have no tests because you have “no time to write them.” You have no time not to write them. The best way to move fast is to increase quality and be serious about testing.
4/12

Fast gets you two essential things: you get revenue sooner, and you get the feedback you need to ensure you’re building something the market actually wants.

“Move fast” doesn't mean: get low-quality buggy garbage out the door faster. That slows you down.
3/12

Even if you’re a startup, though, breaking things makes no sense at all unless you’re talking about breaking the status quo in a moribund product space. Who has time to fix broken stuff?

"Move fast” is more interesting.
2/12