The Perfect Product Myth

(how manufacturing and software are nothing alike)

Published in

Future Feed

10 min readAug 12, 2017

The beginning of the software revolution occurred a long time ago. It started with basic ideas involving “computing engines,” and it usually involved creating specific and simple algorithms to accomplish some exact purpose — mostly having to do with calculating using large numbers. Back then, the perfect algorithm and perhaps the perfect software might have made maybe a little bit more sense. In the beginning, things were simple…

1822

In 1822, Charles Babbage developed the first non-human computer. Called the Differencing Engine — it really served only a basic purpose which was to automate a few simple mathematical operations on several sets of numbers. It was what we would refer to as purpose-built. It wasn’t until 1837 that Mr. Babbage proposed the first general purpose mechanical computer.

It’s notable that people were computers before computers were computers. Perhaps this was an early shot across the bow in the future war for work that humans and non-human computers have been waging ever since. Does this mean that we launched a first-strike assault, for which we have been paying ever since? Maybe…maybe not. Regardless, humans have been winning the war for quite a while. The main losers have been in different species of non-human computers for the better part of the last 3 centures — with the fully mechanical computer being slowly but surely replaced by the fully electrical computer. That said — this is completely tangential to the topic, so maybe back to that?

Ada Lovelace kicked off software by helping Mr. Babbage with that 1822 prototype, by the way. Perhaps this should be remembered as we contemplate the current war of the sexes in software development. In any case — it all began with simple things. We want to calculate an essential sum. We want to perform some multiplication. We want to figure the difference between some large numbers. We might even want to perform some long division. The future of massively complex social graphs was not even a glimmer in the eye of Ada Lovelace and Charles Babbage.

1837

Babbage, as noted perviously, next concentrated on the Analytical Engine. Huge improvement there — the first Arithmetic Logic Unit (ALU), some basic logical flow control, punch cards and memory were integrated together (well at least in theory). Funding was a problem for Babbage and this device never came to fruition in his lifetime. That said — what’s interesting is that the punch card idea was still in use as late as the 1980s — so Mr. Babbage was clearly on to something, if perhaps a little ahead of his time. Being right for 143 years is some kind of record.

1936

It takes literally another 100 years really before we get to do more than basic calculations though. And so, Konrad Zuse sits in his parent’s living room and starts the first war for the future — turning out an electro-mechanical computer that can be programmed for more than those basic calculations. And then instantly we go to traveling salesman problems, right? Well — no. Complexity is still a problem for the future.

Perhaps a moment of silence for the mechanical computer species though… Fully mechanical started to go the way of the dinosaur right about this time (although, perhaps like the birds descended from the dinosaurs, we are seeing the rise of robots right now — so dinosaurs became birds and mechanical computers have evolved into robots.)

Fast Forward…

Sometime in the 50s, computers stepped out of the world of theory, science and advanced engineering into some more practical uses like tracking the sensus and running calculations for insurance companies and codebreaking for the US Military. Still, most of these uses were pretty straight forward iterations of earlier calculating engines in the sense that we weren’t asking them to do very complicated things. Until…

Modeled after the Cambridge University EDSAC computer, the president of Lyons Tea Co. has the LEO built to solve the problem of production scheduling and delivery of cakes to the hundreds of Lyons tea shops around England.

So — scheduling for Tea shops. This is where things start to get messy. Have you ever tried to schedule a multi-location activity wherein a vehicle or a person are expected to follow a route, optimize the time spent in transit and meet delivery goals so that what’s being delivered doesn’t get wasted? It’s a surprisingly complex thing to do.

Today…

Notably, Lyft and Uber do the aforementioned route optimization sequence millions of times a day around the world along with many other ride-sharing companies using digital apps and mapping software. On the one hand — a single point to point route isn’t really all that bad. You don’t really have to do much more than make sure that you know which of several routes are likely to be quickest. No small feat of course, but not as daunting as scheduling a route with multiple stops, a maximum time limit for each person who’s jumped in to the car to be in transit for best user experience, and a goal of not going seriously out of the way somehow along the multi party path. Elevators do this every day all the time — but the vehicle in question only goes up or down along a straight path. It’s not a big deal. But, Lyft Line and Uber Pool do something much more complex. Practical trials will show you on a personal level which company is doing a better job of it so far.

The Roaring Voice of Complexity

This is where I think the problems start. As we make our way forward — from the 80s to the 90s to the 00s to the 10s where we are today — the world of computing and the world of software used in computing changes drastically. We evolve away from simple problems and simple algorithms. We dive deeply into complex problems and complex algorithms. But we still bring forward our manufacturing mentality of the past. We build with the end in mind as if there is a true end.

As managers, leaders, entrepreneurs and investors — we expect to be able to describe what we want and then magically it appears — exactly the way we imagined it — with bells, whistles, and a roaring hum like that awesome rocket to the moon that we have listened to in countless videos. But software isn’t like that.

In the world of software — unlike the world of rockets — we have an endless supply of ideas about what we want our software product to do. In rockets — we want the rocket to go up (unless you’re Elon, in which case, we also want the rocket to come back down, land safely, take an ocean cruise, stop by the cantina for a latte and maybe do a little dance). In software — we want the software to dance sideways, change appearances like a chameleon, know what we are thinking and answer our questions before we ask them, sleep when we aren’t looking, wake up when we are, walk backwards, walk forwards, sprint, jump, speak, think, predict the future, tell us where the nearest fire hydrant is for Barksley our fabulous puppy, and more — frankly, thinking of all we want software to do is as exhausting as reading this entire sentence in one go.

So, where does that leave us? Well — I’d argue that at a minimum — that leaves us with tremendous complexity.

So, what do we do about it? Maybe — let’s agree that we aren’t great at figuring out massive complexity beyond a certain point — and then if you’re with me on that — perhaps we agree that we should try and keep the whole thing a bit simpler — and if you’re still with me even after that — then let’s stop looking at software like a product.

Hmmmm — Product Owners, Product Managers and Product Marketing Managers all around the world are shaking in outrage. Well — to be fair — I’ve played some of these roles at work — so I want to make a few remarks on that. What I’m not saying here is that we don’t need to have an end in mind. I’m also certainly not saying that we shouldn’t release something that people can use. But doesn’t the whole word Product have an implicit problem with it?

Consider a tire. A tire is a product. You come up with a design, you prototype the design, you test the resulting prototype, you decide the prototype works, you finalize the design for mass production, tires are mass produced, and you sell some tires. Great. Awesome. It’s a product. Better yet — the tire goes on a car — the car rolls with 4 of them and they last a period of time.

What if a tire were software. Ok — we found out there’s a flaw in the tire. We need to take all the rubber off. We need to replace the steel belt. We need to put all the rubber back on. We need to release this as a hotfix. We also need to squeeze in some new composite rubber into the rubber we are putting it back on. It’s better. It allows customers to do more cornering on streets. It’s faster. It’s more optimized. We also need to put some sensors in the tire that report back to the factory when the rubber is too hot or too cold. A bunch of our customers told us on “user voice” that they really want their tires to be skinnable in different colors. They also want to put their own unique logo on the tire. The tire needs to work for cars but also they need the tire to work on their trucks. The tire needs to work in snow, hot desert, on sand, in mud, under water and really — it should allow us to fly too.

Ok. Maybe the flying comment was a bit much…

But — something that’s not a bit much is that software continuously evolves. At least — that’s what we expect of it today. We are accustomed to apps on our phones and now on our TVs and certainly on our tablets that keep getting updated.

Some more examples… A song is a product. It has a fixed beginning, end, form along the way and it doesn’t evolve. Once it’s produced, it’s fixed in time. A movie is a product. A computer is a product. A car is a product. The headphones I’m using right now are a product. Software though? Software is not a product. It’s more of an emergent phenomena, continually evolving over time. Sure, people create product releases — but let’s just remember a time in the past where software was not so human friendly and you had to wait 3 years for all critical improvements you really needed in the software to get put in so that you could install a new copy and so that you could have a sigh of relief, finally, that thinks worked pretty well. That — was the 90s.

Software — An Emergent Phenomena

Ok — so if software is an emergent phenomena — what does this mean for software development and for managers of software development and for companies that rely on software to run their business, as the basis of their business or to help them get business? It means that we have to stop looking for perfection. We have to start looking at software as something that evolves.

But what about Agile and Waterfall and everything else. What about managing releases and delivering something people want to pay for and making things that businesses and consumers get value from? Well that’s the beginning and the end of it, right? Value… Everything that we create should be organized around value. The purpose of releasing software isn’t to create a product — the purpose of releasing software is to create value for someone. Sometimes the value is in the form of solving a problem. Sometimes the value is in the form of improving how something works. Sometimes the value is in creating a fun experience. The value can even take the form of causing distraction or downtime so as to unlease creativity. But — the only thing that matters is creating value. With that in mind — manage things however works for your team — but manage things in a way that is value driven.

And where complexity? Ask yourself this — does making something big always create value? If you were to look closely at any piece of software today — I’d argue that there’s a point where the complexity of what was created crosses a line of diminishing value. Feature bloat, crossing the need line, excessive integration — all of these are representations of this problem. Sure — create a word processing program. But if you just keep adding features without having a serious think about whether the value added is worth having — I’d say you’ve gone down the wrong path and that you may be pursuing complexity for complexity sake.

From Minimum Viable Product To Minimum Viable Release

So — here’s what I’m going to propose — let’s stop calling it a product. Let’s stop thinking of software as a product we can perfect. Let’s stop thinking that it’s one and done. Let’s call a spade a spade. Software as an emergent phenomena should be high value, low complexity and release based. It’s not something we manufacture, it’s something that emerges from need or want.

If there’s one thing that the world of apps should be telling us — it’s that wants and needs can come from anywhere and that its better to create something small, simple, easy to use, and purposeful that can interact with other small, simple, easy to use and purposeful things than to try to create a perfect product.