How ‘good enough’ became the mantra of tech design
Every successful product begins with an idea. A way to share photos online. A portable music player. A modular phone. Next comes an MVP — a minimum viable product — or perhaps an MMP — a minimum marketable product. At this point, if the idea is good, it will become a real product. We’re at the beginning of a journey. Oh, the places we’ll go. The possibilities, the excitement.
Right now, we have a clear road map. We made the minimum viable product so we could get something built quickly, and it’s obvious what to do next — make the product less minimum. People want to do things with the product that it can’t yet do, so it’s obvious what the improvements are; we just need to find the time and money for them. The screen could be a higher resolution; the processor could be faster; if it’s an app, it could allow commenting on pictures; and so on. Each time there’s a new release, everyone is excited as the new features bring new opportunities. The users can do more stuff that they want to do.
At this point, there are more ideas than there is development time. Features have to be prioritized, and each new release brings some of those improvements. Oh, there’s a new iPhone, and now it has a fingerprint reader so I don’t have to enter my PIN. Next, it scans my face so I don’t have to touch it. The processor is faster, the camera is better, new features are rolling out one after another, and everyone is happy. There’s singing and dancing in the streets (or camping outside Apple stores in curbside capitalist favela).
But, as time goes on and the releases keep rolling, the to-do list of ideas starts to get shorter. Sure, there are plenty of bugs and tweaks. But you’re not going to get people putting up a Cotswold Outdoor tent in the rain to get some bugs fixed, are you? The processor and camera are better, but these are table stakes now.
So you look at the backlog of ideas and suggestions. They’re fiddly and only appeal to a small number of users. Some features you can’t add without alienating other users. Others you’re not sure you want to add because they’re so specific to one slightly strange use case. One of them is from that annoying guy who keeps writing about wanting to import XML. Who uses XML anymore?
A shift has occurred: You now have more development time than ideas.
As the product has grown, the number of workflows and features for it has increased. The cyclomatic complexity has gone up. That’s a great phrase—it sounds so technical. It refers to the number of separate routes through the application. When code runs, there are points where the application has to make a choice about what to do. For example, a developer might write some code to say, “If this app is running on an iPad, have a sidebar; if it’s on an iPhone, don’t have a sidebar.” That’s two paths: one for the iPad and one for the iPhone. Then the devices could be portrait or landscape. Now that’s four paths: portrait iPad, portrait iPhone, landscape iPad, and landscape iPhone.
Every time there’s an option or a condition where the code branches, the cyclomatic complexity increases. Over time, it becomes harder to add new features because making a change somewhere breaks something in a separate path. Large apps may have tens of thousands of paths through the code, so you can see how a developer might miss one.
Back to our list of ideas for the product. Now that we have built so much, adding in new features becomes harder. The toolbar might be full, or the new ideas might contradict features already implemented.
Looking through the list of ideas, you can’t see any obvious improvements that will make people rush to upgrade. The low-hanging fruit has been picked, and what’s left is high up or filled with wasps. A shift has occurred: You now have more development time than ideas.
At the product meeting, someone says, “Right, so what are we going to put into the next version?” Rather than suggestions for enhancements, there’s a pause and someone says, “Um.” That um is a problem. That um signifies you have reached the good-enough plateau.