If you’re a developer, you’ve heard about the argument of delivering the Tractor vs the Cadillac.
If not, here it is in condensed form.
Tractor – rock solid, gets you from A to B with little fanfare, doesn’t look great, does the job, never falls over, stable as a rock.
Cadillac – it looks really pretty, it’ll give you the smoothest ride from A to B (when it works), it has all the bells and whistles (but doesn’t always work).
So the question becomes when debating the delivery of a new feature is whether you want it to be solid and simple or unstable but looking pretty.
However, there is an oft-used trap used to reduce delivery expectations and time by “hiding” behind the tractor and not delivering what is really needed by the customer because it goes into the “Bells” class.
For example, if it takes 4x as many clicks to start the tractor vs the Cadillac, it doesn’t mean that adding in this functionality will make it a Cadillac, it means that it will be a more usable tractor for the customer if you can reduce this to 1 or 2.
Adoption of any feature you build is key, no one wants to work on the functionality that no one will ever use. Seriously, no one wants to hear that their work is never seen by the customer – what a complete waste of time to have worked on something no one uses it.
This is why, when designing your tractor in early iterations (good, focus on the tractor first) there is always room to ensure that the tractor runs better than the Cadillac. It’s not a bell or whistle that you are adding, it’s an easier way for your customer to get from A to B to increase adoption and be ready to use the Cadillac when it comes around the corner.
