Working in corporate taught us that products should be launched feature-complete, zero-bugs, sound architecture, scalability in place and with all the bells and whistles.
This was also my thinking until I read Remote: Office Not Required and Rework by the duo behind Basecamp — David Heinemeier Hansson and Jason Fried.
It's in one of these books, where I first encountered the expression "build half a product, not a half-assed product".
The thing is that most of the friction related to product development has the following roots:
- everybody wants clear requirements
- they also want requirements that don't change
- everything should be predictable all of the time
- all information should be provided on time, all the time
But nothing of what I listed above happens that way. And don't think it doesn't affect us.
It affects everyone, from stakeholders to implementors, middle-management and whoever is in-between!
When you're stretched too thin, and you set out to develop a monster of a product, while your account balance tends towards zero, you start to sacrifice things. And you end up with a mess.
But you get launch feature-complete...
Know that it's pointless, if half the features don't work as expected or are glitchy and inconsistent.
The best place to sacrifice things is in the planning phase.
Here's an expression that's very popular in the writers circles:
Kill your darlings, kill your darlings, even when it breaks your egocentric little scribbler’s heart, kill your darlings.
It is attributed to Stephen King, who urges writers to get rid of the parts of their work which they love, because they're perfectly written. Those shouldn't end up on the publisher's table. They will confuse the readers.
This applies to software 110%.
You might have features you're very proud of, because you are the one who thought of them, you architected and hand-coded everything. But it doesn't mean that they will be meaningful to the end-user.
If you need more context, let's pair Stephen King's quote with an amazing dramatic principle called Checkhov's gun put forth by the great Russian playwright Anton Checkhov, which states the following:
Remove everything that has no relevance to the story. If you say in the first chapter that there is a rifle hanging on the wall, in the second or third chapter it absolutely must go off. If it's not going to be fired, it shouldn't be hanging there.
Basically, if you have a feature that doesn't serve the immediate purpose of your user — not yourself — you should remove it from your product.
This removal process is best applied in the planning phases, when no actual work has been put into developing features. This will keep you safe from two very nasty decision-making biases: the sunk cost fallacy and the escalation of commitment bias.
Let's be honest with ourselves, for a second. We have to admit that many of the features in an application shouldn't even be there in the first place. They provide no value for the user and are just used to fill in the blank space. Or they're things we've fallen in love with, because they were interesting to think of and build.
Design principles tell us that whitespace is important, and with every little thing we add to a design, we reduce the breathing room of the other elements.
By breathing room, we can understand anything from exposure, visibility to actual space.
Outro
Hopefully the experiences shared in this article will resonate with you and you'll be able to build half of your product, well enough, and ship it to your users, instead of endlessly working on shipping the whole thing, and realising you've put in features your users don't need or that whatever you added doesn't work properly.
If you have thoughts about this, reach out through the contact form or send an email, and get your contributions in.