Startup Priorities

Links

Geoff Ralston:

One of the most difficult tasks for a startup founder is deciding what to do. Where should the tiny number of people working on a brand new company spend their time? Choosing wisely can place your company on the road to success. Spending too much time on the wrong things can condemn the startup to an early death. How do you know whether you are making the right decisions in time for your company to not die?

Usually, my answer to founder questions such as “how should I be spending my time?” is spectacularly simple. Choose a key metric to track and focus exclusively on making that metric grow. When deciding what to do, choose the activity that you believe will directly result in increased growth of your chosen metric.

This is simple and sometimes enlightening. Although making those decisions is still never easy. That is one of the reasons startups are so difficult. Even choosing which metric on which to focus is often the subject of great debate. It is best to pick a metric you are pretty sure you know how to increase. But it is equally important that that metric matter. And by “matter”, I mean its growth will be a good objective measure of how your company is doing, for example by an investor.

There is also a special case where you are trying to decide what to build. Usually you are concerned with metrics around how many users you have and how engaged they are with your product. For simplicity I call the former b for breadth and the latter d for depth. This leads to a rudimentary but surprisingly helpful way to think about how to prioritize product decisions. If c is the cost of building a feature (in whatever unit, engineer days, time to completion, etc., you like), then you can create a simple ranking with the equation:

(b * d) / c

b tells you how many of your users, current or new, will be impacted by a new feature, d describes how important that feature will be to the average user, and c gives you how hard it is to build the feature.

The application of this simple formula tends to arrive at a blindingly obvious conclusion: first build the features that affect lots of users as profoundly as possible, and which you can build quickly and cheaply. It is surprising how profoundly hidden the obvious can be and how enlightening it can be to bring it into focus.

Breadth = % of users using, while Depth = key usage per user

Basically, this formula takes how many users will benefit from a feature (breadth, aka b) multiplied by how much it will improve their experience (depth, aka d) divided by how long it will take to build (cost, aka c).

This is handy for working out your priorities in a startup, and is a useful formula to keep in your toolbox.