In computer networks, there are two ways of measuring speed: Bandwidth is how much data comes down the wire. Latency is how long you have to wait for a single message to go from your computer to another computer.

If you put hundreds of hard drives in your car and drive to a friend’s house 20 minutes away. That is high bandwidth (potentially petabytes/hour), but also high latency, because it takes 20 minutes for a hard drive to arrive. Conversely, old school text messages are low latency (you get a response in milliseconds!) and low bandwidth, because you can only send 140 bytes at a time.

There is a fundamental lesson here for everyone: you can always add low-latency connections to get more bandwidth, but you can’t add high bandwidth connections to get lower latency.

Bringing this back to our previous examples–you can use two phones to send SMSes in parallel to get more bandwidth, but two cars full of hard drives going down the highway won’t get to your friend’s house any faster.

“You can add low latency connections to get more bandwidth, but you can’t add high bandwidth connections and get lower latency.”

You should optimise for latency over bandwidth

In principle terms, you should prioritise shipping the most important thing as fast as possible over optimising the total number of features shipped.

In practical terms, this means once you identify the most important thing, you should dedicate more resources to it until building it can’t go any faster.

Latency doesn’t only refer to the speed you ship new features or products. We should all make decisions faster. Mongooses hunt snakes and win, solely because they react faster and every startup should be reacting to customer feedback faster.

There’s an old joke that Paul Graham likes to quote:

How to paint like a master:

• Become a master
• Paint whatever you feel like

It’s troll-y, but there’s a kernel of truth in there. When you paint like a master, you just do what feels natural, with no studying or analysis paralysis. If you internalise all of the information you need to do your job, you can make decisions much, much faster. They may not be perfect, but quoting George S. Patton, “a good plan executed violently now is better than a perfect plan executed next week.” Of course, this is only applicable to two-way decisions. Be more careful on one-way decisions.

Ratchet

A product is never perfect. What you want to do is to make it better every day. How? Have a long term vision, and then make incremental progress towards that vision. Try not to deviate from that long term vision and you will make progress. This means you have to put your foot down pretty hard when you think a proposed change makes the product less good.

Hill climbing algorithms can only find local maxima, not the global maximum. It’s fine to go downhill in search of the global maximum, but it’s not okay to go downhill because it’s expedient to the current problem.

Aim high. But, touch grass

In general, many companies don’t aim high. They don’t think about a ten year vision, or what the ideal end state looks like at all. Many companies think “given where we are standing now, what is the next move we should make?” They’re thinking (at most) one move ahead.

Instead, figure out the long term vision first, and then based on that, figure out what your next move should be.

My general algorithm for designing solutions is:

• Determine the ideal first, ignoring all constraints such as money or time
• Figure out whether the ideal is achievable with all constraints in place
• If not, figure out what the second most ideal solution is

In addition to thinking about your ten year plan, you also have to stay alive. You can’t navel gaze all day, you need to make money and survive all of the challenges you’ll face. Staying alive is a part of any successful long term plan.

You’re here to make money, not features

The goal of any startup isn’t to ship features, it’s to have a functioning, profitable business. The ideal business is to own a literal money printer. No customers or products, you just push a button and money comes out.

If you have to have customers and products, the best business is you have a single product, it’s very simple to build, it’s easy to sell, every customer wants exactly the same thing and it makes lots of money. The worst business is one where you have lots of products, they’re all complex, they’re hard to sell, every customer wants custom work and you make very little money on each sale.

Yes, we live in a fallen world and there’s value in having solutions to many customer problems.

Given a choice where two hypothetical futures have the same LTV / NPV calculation, the one where you make fewer products and features is likely better, because it’s less code, fewer bugs, less maintenance, less polish needed and a more focused team and strategy. Code, product lines and features are all liabilities until they start making money.

What does this mean in practical terms?

• If you can optimise revenue without building new features, you should do that
• You should optimise for revenue per product
• You should optimise for customers per product
• You should optimise for revenue per employee
• You should agree on a ‘get out of bed’ number for building a new product

The way you do one thing is the way you do everything

If you are building a global business with live customers and products, everything you ship is public and must meet a minimum quality bar in terms of security, UX, polish and performance. The reason for this is fundamentally about customer trust. If you ship half-baked features or poor UX, it implies you don’t know what you’re doing, and your customers might re-evaluate their relationships with you.

You still have to iterate and ship end to end slices, but that doesn’t mean you have to release a first draft of new features or products! You can deploy ten iterations to production, but maybe the first five are only accessible to employees, and then there are iterations with one pilot customer, then a few beta customers, and then finally general availability.