Do you want your build to be good, fast or inexpensive?
You can only choose two!
Whenever we make something new there is a trade-off.
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 chose 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 that we want to attempt to treat as fixed, it’s useful to flip the language. Good, fast and inexpensive all sound like desirable things. But the combinations of any two of these, 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). However, this means we’re choosing the expensive option - both in terms of the cash we spend immediately and the value of the equity we retain in the long run.
Maybe we think we can cut some corners on quality in order to make the build faster and cheaper. However, this just means we’re leaving debts to repay in the future (this is actually sometimes the correct decision, in some specific circumstances).
But let’s not pretend we can have all three! That always comes back to bite.
People rarely remember how long it took you to do the job, but everyone remembers how well you did the job.
— James Clear
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?1; what can customers actually do with it?; what’s it for? In my experience this is nearly always what gets compromised when the pressure comes on, in the name of trying to work within the other three constraints. 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, more often it’s just the easiest thing to compromise on.
I have joked that the job of a product manager in a startup is to manage infinite lists.
I wasn’t really joking.
In a startup there is only business-as-usual. We are never finished.
It’s a difficult adjustment to make. When we’re building something new we really only have two options:
- Understand and accept the trade-off between good, fast and inexpensive;
- Be impatient.
I appreciate the first option isn’t very popular these days. In fact, it’s almost old fashioned.
But I also know that everybody I’ve seen who has built something worthwhile has ignored all of that and focussed on quality and efficiency, and on sustaining themselves through the longer-than-we-think that it actually takes to make something remarkable.
So, breathe.
In through the nose. Out through the mouth.
Deal?
Header Image: Sydney Opera House.
Designed by Jørn Utzon, who in 1957 won a competition to select an architect. Construction was finally completed in 1973. The total cost was $102 million, over 1,300% more than the original budget. In April 1962 it was estimated the build would be completed within three years at the latest. It actually took 11 more years. Utzon quit the project in 1966.
The completed Opera House is iconic and widely considered a masterpiece of architecture.
-
Sometimes technical people call this “functionality”. But, that’s a word I’ve discovered is meaningless to most non-technical people.
It’s nearly always better to talk about what the user does rather than what the software does. ↩︎