Six rules for getting things done

However big and frightening a piece of work looks, it's a sequence of small ones. You can't build a platform in a single release, but you can build the first useful slice of it, then the next and the next, until you look back and the big thing is done.

When a team is paralysed by the size of the work, motivation usually isn't the issue. They need help breaking it down. Cut the work into pieces small enough to ship this week. Every other rule here depends on this one.

The smaller version of a feature is the quickest way to find out what to build next. Real users with a real product will teach your team more in a week than a quarter of planning.

When the team has two options and can't decide, the smaller one is nearly always the right call. You learn sooner, and it costs far less if you turn out to be wrong.

Chasing perfect is usually a polite way of being slow. Polish added before anyone has used the thing is a guess about what matters, and guesses are expensive.

Ship something real, watch what happens and let the product show you where the effort belongs. The teams that improve fastest treat each release as a question they're asking users.

Get it working end to end before you make it elegant, and make it elegant before you make it quick.

A lot of engineering waste comes from optimising code that doesn't work yet, or polishing the architecture of a feature nobody has validated. Make it correct first and worry about speed later.

One of the most valuable decisions a product team can make is to ban bespoke work. Nothing gets built for one customer unless every customer can use it.

Each capability built on shared foundations costs less than the one before, and no single client owns any part of what you make. It sounds dull, but it's why small teams can move like much bigger ones.

When someone can't find a button, misreads a label or abandons a flow halfway through, treat it as feedback about the product. It points at something you can fix.

Blaming the user ends the conversation, while treating their confusion as a bug keeps it going. It's the cheapest and most honest feedback your team will get.

Good product work comes from hearing what people can't quite put into words, more than from taking orders. Customers describe the solution they've imagined, and the job is to find the problem underneath it.

Sometimes people just need to feel heard. Sometimes they don't know how to explain what they need. Picking up on the gaps and pauses is one of the hardest skills on a team, and one of the most worth protecting.