Overengineered software and the Juicero problem
Does anyone remember Juicero? It was a $400 juicer that came with a subscription to special fruit bags that it needed to work. It couldn’t juice the fruit you bought from the supermarket, but it could connect to the Wi-Fi.
Juicero was all well and good (if a bit ridiculous) until you realised that you could use your hands to squeeze the juice from the bags, rendering the kitchen device completely pointless. The product went from a flashy juice innovation to a total flop.
But what could a hyped-up kitchen appliance possibly have to do with software?
Overengineered software
Overengineering is when a product is far more complicated than it needs to be to serve its function. Juicero is a classic example of an overengineered product. It made a simple task —squeezing juice from fruit bags — into an expensive machine that offered no value to consumers.
Overengineering isn’t a problem reserved for juice-related products alone. It pervades every product development sector — and software is not immune.
Excessive future proofing, losing sight of the core function of the product and an all-encompassing drive to launch the perfect software can see developers and designers fall foul of the Juicero problem. That is, they can lead to the production of overengineered software.
No one needed it
Juicero failed at the first hurdle of a successful product: it didn’t solve a problem. The juice bags themselves may have held some interest, but the company put the focus on its juicer — which did the job that anyone with hands could do. (When your internet connection was up, that is.)
So, lesson one to learn from Juicero: your software product needs to solve a problem.
It’s simple, if your software doesn’t solve or simplify a viable problem, it won’t be marketable. If people don’t need the product for a clear reason — just as no one needed the Juicero appliance — it won’t have any market value. There’s no reason to buy it.
Software developers need to remember to keep the problem they’re solving firmly in mind — and conduct market research to make sure it’s a problem that needs to be solved. Creating an MVP (a minimum viable product,) can help avoid overengineered software. It keeps clear the core functions of the product. An MVP can also offer an opportunity for market testing, meaning you can find out if your core product has market value, or if you need to go back to the drawing board.
It over-complicated the problem
Juicero made a simple problem — obtaining fresh juice — into a complex system of fruit bags, Wi-Fi connectivity, and a useless machine. The problem it ‘solved’ was buried in gimmicks, pointless features and bravado. It pledged to ‘innovate the food delivery model’, yet the only potentially useful aspect of Juicero was its $5-$8 fruit bags. And even then, buying a bottle of juice was cheaper.
So, lesson two to learn from Juicero: the software and its features need to be necessary, not gimmicky.
Overengineered software is plagued by feature creep. The desire to provide and release a competitive product sees more and more features added, in a bid to accommodate even the most obscure of customers.
As a result, the overengineered software ends up stuffed full of features, and the core function of the product is all but forgotten. In other words, overengineering sees your software become far too generic to be useful to anyone. (Which is exactly what happened to Juicero.)
So, software developers need to have a clearly defined product goal and target audience and stick to it. Write user stories to help keep these goals and customers clear. It’s important to question every feature and every function to avoid overengineered software.
Avoid the Juicero problem
Overengineering burns time, money and developer dreams. So, research your market, and question your product, features and functions at every turn. Avoiding the Juicero problem in your software development is about keeping the core problem your software is solving in mind.
Ask yourself two questions:
- Does this product solve a problem?
- Are the features in it core to that problem resolution?
If not, you’re making overengineered software and potentially following Juicero in its fabled fall.
