I’d like to tell you a story. It’s a bit abstracted from the details, but it’s a pattern I’ve seen on a number of occasions. I’ve assembled it as a fable with details drawn from the times I have seen it occur. While I describe it as a failure mode, my intent is to describe it so that you can identify it and make deliberate choices about the detailed trade-offs in your situation.
Our story has two protagonists – Alex, an engineer, and Blair, a product person. They’re talking over lunch, and they come up with a great idea for a feature. They develop the idea, and hack out a prototype, test it out on some people – yep, it’s great. It’s an A+ idea. Let’s get it road-mapped.
Alex does a breakdown of the engineering work required to deliver it – not the hacky prototype they came up with for the demo, but evolving the software and system architecture compatibly with long term plans, and with all the cross-cutting concerns done right. This is a lot more work – in a large system it usually, in my experience, means some amount of rework to generalize components across a broad surface – uplifting across the whole system.
Alex knows that Blair is going to have trouble resourcing this. It’s a great idea, and they have some objective data to show that people will like it, but it’s a lot of work. It’s important to be agile. Maybe their expectations about the appeal are wrong? Maybe by the time they’ve made it the market will move? Maybe a new cross-cutting concern will emerge which needs a lot of work? Maybe other parts of the business will want aspects with adaptations Alex and Blair didn’t foresee.
So Alex does what engineers do – they figure out an incremental path to value. They come up with the A- version of the idea. It has a lot in common with the A+ version. Where they overlap, the engineering work to achieve them is common. Where A+ has significantly more work, there are clear bulkhead abstractions that can be used to deliver A- without significant rework to add the additional components needed for A+.
Alex and Blair get back to together in order to talk next steps. In the course of this discussion, they realize that A- – purely at the feature level, looks really like another system we might call B+. In the implementation details, they’re really quite different, and B+ is significantly less work than A-.
When this happens, B+ often shares implementation details with the prototype that kicked off the work. Sometimes B+ excludes a particular cross-cutting concern which is more costly to implement in this approach – it will be increasingly hard to scale, or secure, or port, or such. It is not necessary for B+ to be poorly engineered – it’s just different, with a set of trade-offs that make the first version cheaper to deliver, by increasing the cost of future change.
Choosing between A- and B+ is hard. You really want some future knowledge to make the right choice. Your hand might be forced by the realities of resourcing. The decision maker, let’s call them Campbell, comes along to approve the project. Campbell’s organisational remit is broad, and they don’t spend time in the details unless they need to. Campbell is likely to be very focused on the observable features of the project. From their perspective, A- and B+ are basically the same, but B+ is less work. They may be aware A+ exists, but that’s not the choice presented to them, and Alex and Blair may be playing it down since they know it is too big to build just now.
The choice is clear: Campbell approves making B+. The team builds B+. Users love it. Customers are paying for it. People are likely to recommend it to a friend or colleague. Alex and Blair and rewarded for their efforts.
Campbell comes back to Alex and Blair to ask “What’s next?”. A+ is in the zeitgeist. The cost delta from A- to A+ was known and planned, Alex thought deeply about this evolution. Campbell naturally asks “Can we get A+ for that cost increment?”. Unfortunately, the answer is no – at an engineering level, B+ is nothing like A-. Almost all the work done for B+ is unsuitable for A-. B+ was an excellent choice if your goal is the common feature set of B+ and A-. If your goal is A+ however, then B+ and A- have completely different value.
Everyone gets grumpy, and A+ gets put on the “maybe one day” shelf, and one day never arrives.
What went wrong? It’s too simplistic to say “the team should have built A-”. With the benefit of hindsight that’s true, but there are other outcomes. The early user research was incomplete, and users don’t like it enough for A+ to be worth the investment. Maybe a competitor drops their product before A- gets out, and gains first mover advantage.
I think there is a clear lesson here – make sure that Campbell is aware of the distance between B+, A-, and A+. In my experience, the Campbell’s of the world are busy, not stupid. It’s easy to mistake B+ for A- when you are looking at a projection of the information needed to make a decision. Surface the choice you are actually making, and at worst you’ll agree you collectively made the wrong bet. However, perhaps, Campbell can rejig other resourcing, or bring in other experts to shift the landscape, or be ready to accurately describe a more costly speculative project as that in a context where the organization has appetite for such risk.
I like a geographical analogy here – imagine you wanted to drive from Sydney to Cairns (A+). You want to stop off in a big city on the way, so you plan to drive from Sydney to Brisbane (A-) and thence on to Cairns. That’s an eleven hour drive from Sydney to Brisbane. If you just want to get to a big city, why not drive to Melbourne (B+) – it’s only a nine hour drive from Sydney to Melbourne. If you’re not familiar with Australian geography, a map makes very clear why this isn’t a great choice if you decide to go to Cairns: Brisbane to Cairns is about twenty hours of driving, whereas Melbourne to Cairns is more like thirty hours.