I really enjoyed this fable of the product that’s built too quickly. I’m sure it’s extremely familiar to many of you.
It’s the story of a startup that aims to build a next-generation oven. They get funding on the back of a pitch deck, then build the prototype. It’s a long way short of perfect, but is good enough to demonstrate.
And then comes the uncomfortable discovery: if the oven only does two of the three things (bread, cakes, or pizza), the algorithm fails just 5% of the time. The engineer brings the proposal to the founder: let’s sacrifice one market and have a product that works. The founder gets angry. He promised the VCs 10% of Spain’s oven market. The entire market. “We can’t sacrifice any of them.”
Next up is the hunt for sales. They quickly realising that the money comes from the enterprise market. And enterprise sales are based on promises, not on what the product actually does. So the feature requests stack up, every one of them urgent, in order to bring in the next customer.
The founder swallows hard. The ticket has been sitting on the kanban board for a month and a half. It’s not that nobody saw it: it’s that every week something jumped ahead of it.
And then they lose their biggest customer …
And the worst part isn’t losing Pepepizza. The worst part is that the changes made for the rotating base will haunt the oven’s design until the end of time. The customer leaves now. Their rotating base stays forever.
I see two lessons in this story.
The first is mentioned in the tale itself - when everything is urgent, nothing is. I read somewhere that, in Latin, the word “priority” is singular-only. There is no plural. “Priorities” do not exist.
The second is that every single option you add in brings an explosion of complexity. 1 option has 2 states - that’s doubled your testing regime. But 2 options have 4 states, 8 options have 256 states. And that’s assuming binary switches. Automated testing can help here (at the cost of time and processing) but will you really catch all the combinationsI guess that’s the point of property-based testing?
The real issue is, in 25-odd years of being a professional developer, I’m not sure what the solution is. Without sales, you die quickly. But the rush of tickets, the inability to stop and breathe, mean you die slowly.