Flailing

The Sydney Opera House was designed by Jørn Utzon, who in 1957 won a competition to select an architect for the project. In April 1962 it was estimated the build would be completed within three years at the latest. It actually took 11 more years - construction was finally completed in 1973. The total cost was A$102 million, over 1,300% more than the original budget. Utzon quit the project in 1966.

The completed Opera House is iconic and widely considered a masterpiece of architecture.

On time and under budget

Whenever we make something new there is a trade off. Do we want our build to be good, fast or inexpensive? ¹

Perhaps we have a fixed timeframe to complete the work. Perhaps we have a limited budget to spend. Perhaps there are pre-agreed quality standards we have to meet.

But we can’t have all three of those things. We need to choose two.

Actually we can choose two at most. Often when we try to build complex things we won’t achieve any of those three things. We don’t have to look far to find a long list of ambitious projects that are delivered late, over budget and with poor quality to demonstrate this.

When we pick the two it’s useful to flip the language: good, fast and inexpensive all sound like desirable things, but the combinations of any two at the expense of the third are much more difficult choices:

Maybe we have lots of money to throw at the problem, so budget isn’t a constraint. This is a common choice for many startups after they have raised a large amount of capital, for example. However, this means we’re choosing the expensive option, both in terms of the cash we spend immediately and the value of our equity in the long run.

Maybe we think we can cut some corners on quality in order to make the build faster and cheaper. This is actually sometimes the correct decision: it all depends on the payback period. There is no value in a high quality solution if we run out of time or money before it’s finished. If we can complete more experiments and generate momentum sooner then perhaps we are willing to pay the greater long-term costs associated with a quick-n-dirty solution.² However, this means we’re choosing the crappy option and leaving debts to repay in the future.

But let’s not pretend we can have all three. That is impossible.

To make this choice even more difficult there is also a fourth variable which is sometimes entirely overlooked or obfuscated: scope.

Scope is often conflated to include aspects of all three of the variables above. But it’s actually a separate thing. It’s the line we draw in advance to define our expectations:

• What are the anticipated features of the thing we’re making? (technical people call this “functionality”, but I’ve discovered that term is meaningless to normal people)
• What can customers do with it?
• What’s it for?

Scope is nearly always what gets compromised when the pressure comes on, to work within the other three constraints. Again, sometimes this is appropriate. It’s nearly impossible to define scope specifically in advance, and when we eventually discover the flaws in our assumptions it’s usually better to adjust the plans than to be stubborn. But it’s often just the easiest thing to compromise on.

It’s better to be clear about what aspects will demonstrate value to paying customers. Then extrapolate from there based on how people use it. Implement a subset of features really well, rather than partially building the whole product and ending up with a lot of compromises.

Startups frequently talk about building a Minimal Viable Product (MVP). When technical people hear that many will imagine something like the original iPhone from 2007. And it’s true, as with any product, the team at Apple building the first edition iPhone had to make a lot of compromises: a small touch screen (the resolution was just 320x480 pixels, about 20% of the size of current models, and with only one-third the pixel density); no front-facing camera or video recording; no third-party apps or App Store; no GPS or 3G connections; and many missing software features we now take for granted like copy-and-paste.

But the context is important too. They were building on the massive success of the iPod and the legacy of the Mac and MacBook products. Most startup teams can only dream of those advantages. A more relevant example is to rewind to when Apple was itself a startup, and consider the original Apple I computer. It looks much more like an electronics kitset than a computer. Our definition of MVP depends a lot on the resources that we have, both time and money, and we need to set our scope accordingly.

Ideally we want customers to do more than “use it” - we want them to “buy it” then “love it” and eventually “tell their friends about it” - but “use it” is the first step on that continuum and much harder to achieve than most founders realise at the beginning of a venture, so start there.

Remember when I said that the job of a product manager in a startup is to manage infinite lists. I wasn’t joking.

In a startup there is only business-as-usual. We are never finished.

When we’re building something new we need to fight our impatience and accept the trade-off between money, quality, scope and time.

Freestyle

Here is some unusual advice I give to anybody working on a startup, or thinking about it: swim.

Most Kiwis think they can swim, because they had some lessons when they were a kid and perhaps spend time at the beach every summer.

But I’m not talking about a cheeky couple of lengths of a swimming pool or a refreshing dip off the side of a wharf.

Try to swim a kilometre or two in open water.

For example, in Wellington, imagine starting at Freyberg beach and swimming around the lighthouse at the point - that’s 2.4km; or in Auckland, think about the Viaduct to Bayswater - that’s 2.9km.

It highlights the important compromises we need to make when balancing schedule, budget and quality.

Swimming for any length of time requires technique. We can have all the strength and fitness in the world, but without good technique most of our exertion is going to be completely wasted. The best swimmers are the ones who get the most forward motion out of each stroke. Even then, a world-class swimmer is only about 9% mechanically efficient (that is, 9 out of 100 calories expended produce forward motion).³ For somebody like you or me it’s probably less than 3%. Small improvements in technique can produce significant improvements in performance.

We also need to stay calm. The combination of getting physically tired and holding our breath with our head under water can quickly cause swimmers to panic and lose form. This is accentuated when we’re swimming in close quarters with others (what triathletes call “the washing machine”).

To swim a long distance we need to relax and take the time to breathe properly. Unlike swimming in a pool there is no black line to follow. We need to set our own course, and that means we need to stick our head up on a regular basis and have some fixed landmarks to aim at. And we’ll likely end up with a mouthful of salt water from time-to-time, which will make us want to throw up the first time it happens. Taking a moment to regain our composure in those situations is to be expected.

Last but not least, it helps if we can swim with the tide rather than against it. If we can catch a wave as we get towards the finish it helps propel us along while we turn our mind to getting the blood back into our legs, so that we don’t face-plant when we try to stand up.

Likewise with our startup…

We might have a superstar team and a big bank balance, but we still need to work out how to spend our time and money on things that make customers happy and grow our sales, otherwise we’ll just be flailing. Too often the reason why we end up over budget and behind schedule is because we spent that time and money building the wrong things.

In the beginning, everything we do will be horribly inefficient, so we need to quickly determine what pushes us forward and what is wasted effort. We need to identify our constraints. Are they obstacles we can remove or do we need to live with them? We need to focus our energy where it makes a difference.

The pressure of working on a startup can be all-encompassing. We’re often pulled in many directions at once, and need to do everything ourselves. In those situations it’s even more important that we stay calm and keep focussed on the things that we have decided will help us, rather than getting distracted by the noise all around us. Winners often don’t make the biggest splash.

These are the things I encourage founders I work with to do, all inspired by swimming in the ocean.

Instead of focusing on inputs like how long we worked, or how full our calendar was, measure progress based on outputs. We can ask: what did we create or learn in the process?

Schedule time to think about what we are doing and not doing, and what we could do differently. And when we get that time, be brutally honest about what’s working and what’s not.

Be patient. Understand the trade-off between good, fast and cheap. Consciously choose a direction and go at it. Be careful that we’re not just blindly following somebody else, who may or may not be heading most directly to where we want to be.

Remember, a positive industry or technology shift to push us along, such as the move towards mobile or software-as-a-service, can accelerate our venture just as much, if not more, than any of the things we do ourselves.

Everybody I know who has built something worthwhile has focussed on quality and efficiency, and on sustaining themselves through the longer-than-we-think that it actually takes to make something remarkable. Maybe even iconic like an Opera House.

Very few people will remember how long the job took, but everyone sees how well we did it.

We just need to keep our arms turning over and keep breathing.

In through the mouth. Out through the nose.⁴

Deal?

Related Essays