Stop Applying Mass Production to Product Development
Manufacturers do Product Development as well, but its NOT done on a Production Line!
Bear with me a little, while we explore the origins that underpin this article.
Back in the mid 2000’s, I had started training software teams in Agile Software Development processes, in the USA and around Europe.
At the time, a new movement called “Lean Software Development” started to surface, spearheaded by some very respectable ex-engineers, the Poppendiecks, and I was captured by their work.
That led me to spend years deep-learning about Toyota, Taiichi Ohno, TPS, Lean Manufacturing, the transition of General Motors and Ford to the Toyota Way, Jim Womack, Gemba Walks, and that then led me to Systems Thinking, Russell Ackoff, Peter Senge, Eliyahu Goldratt and the Theory of Constraints, Edward Deming’s amazing story, and all that stuff. It even led me to Teal organizations and got to the heart of the real dysfunctions in our industry — the organizations — who they are managed by, and how they are managed.
It is a fantastic body of work and scientific insight, figured out long ago by an amazing community of people, and today, I lament that if only more people paid more attention to these teachings, given that nothing significant has really changed since that time in terms of doing creative work the software world.
This whole body of work gave me a solid foundation to go and do good work in tech, which has been mostly focused on building high-performing product teams and product organizations.
Okay, so then in 2011, Eric Reis (from Silicon Valley) put his own mark on Lean by popularizing the “Lean Startup” and heaps of other wannabes jumped on the bandwagon, and an agile industrial complex exploded.
His message, at heart, was well-intentioned, but once again, that intent has been twisted to ratify the idea that “Build” (and by extension, “Delivery”) is the primary, and one, and only important part of Product Development. This is terrible news for many software companies and bad news for their end-users and buyers too! And this mindset has damaged this industry beyond belief.
Even though Lean Startup mentions “Measure” and “Learn” (albeit not as much), those crucial activities are not given much attention, if any at all, in most software companies.
I need to remind you: that the “product work” that is going on in product development companies is wildly different than the “software work” going on in most enterprise companies, who are building software tech.
Yes, both kinds of work apply the same software tools and procedures, but it is not the same kind of work, nor the same processes, and it is that way for a reason. The job is vastly different.
It is now 2022, and most companies “doing” software are still run by ill-informed people who still believe that “Build”, and “building” as many features as possible (as fast as possible) is what you do to attain making great products, and that the “Measure” and “Learn” steps are a secondary and optional pursuit.
Why is that? How can this still be so prevalent?
My take?:
- That kind of experimental and learning work is actually far harder to do than the more straightforward technical delivery work. Finding people who are good at it are hard to find. Finding young developers willing to do what you tell them is easy.
- Dealing with the uncertainty that this kind of work implies is too much to deal with for those controlling businesses. Solutionizing, copying other works, and describing features is far easier work to get done.
- It challenges those control freaks who have dearly held and protected confirmation biases about their own views of how people behave. As opposed to dealing with counterintuitive truths that make them appear to not know what they are doing.
- It costs precious time and money, and that is viewed as directly competing with time spent on the more valued “build” work. A form of teenage “OR” thinking.
- All the negative results in these feedback loops and the resulting re-design work compete with how most finance, sales and marketing-oriented people perceive progress— measured in having more and more things!
“Being Lean” and following in the steps of the Lean Startup sounded cool (back in 2011), and doing M.V.P’s (fancy name for an experiment) and whatnot just strengthened the incumbent idea that “feature teams” of [only] developers should just rush to just “Build” new features and get into market with their creation.
There is no real need for any product strategy, no need to measure customer behavior change, no CX/UX research input and validation work going on in those teams, just writing code and doing it as fast as possible. Many times faster than possible, actually. Customers will simply love it all and buy it based on that merit alone!
Worse, these deliberately constructed “feature teams” would then be driven by supposedly far “smarter” people (in higher positions of authority in the organization) who were doing all the “Learn”-ing (and “Measur”-ing) on behalf of those software teams.
As if that has been proven to work and be effective and efficient — said no one!
The “Product Owner” role (borrowed from Scrum) was then malaligned as a very rough approximation of a proxy/puppet role providing control over the team and its outputs and as a means to channel their “super-smart” stakeholders' superior knowledge and predictions of the market. Who just drove ineffective product ideas to the teams, miles away from them and the actual end-users of the product. (Back then — early 2000s, not many outside of tech had really heard much about Product Managers).
Why would you need to listen to and measure your actual customer behaviors when your stakeholders already have all the answers, and can predict the future of the market?
For many organizations (both startups and enterprises) Build-Measure-Learn, was a cool new way you could claim to be “Lean”, like the Silicon Valley tech giants, and make impressive MVP’s that had customers flocking to throw money at you. All the while, not changing your behavior as a leader and still commanding and controlling those pesky developers to do the bidding of those genius business stakeholders.
If you build it, they will come…naturally!
When this movement started to transpire worldwide (and it didn’t take long to take hold), I decided to retreat away from leading with the words Lean (and Agile) in my tech work in software. Even though, a the time, I was really happy to see an emergence of agile coaches and organizational experts entering the market.
This would have been great, except that the vast majority of them, armed with some psychological tricks, were woefully inexperienced as practitioners in this industry. Many weren’t even seasoned enough at doing the job of those they coached, to direct nor dispense good enough advice to struggling product teams. It was a shit show all around.
In most places (from enterprises to product companies) throughout the 2010s, the harm was already done or being done, and those continuing to harm were now self-certified as agile coaches and product owners.
Nowadays, some 15–20 years later, every week or so, it seems on LinkedIn, one or two more people are re-discovering these deeper bodies of Lean and Systems Thinking work and telling everyone about it, and that is spreading the good word in all corners of our industry, which has to be great news in general.
But yet, gifted, enthusiastic, and creative product designers/managers/engineers are still perplexed as to why the cool companies they work for, cannot allow them to fully apply their craft properly.
Despite all the goodness that is in Lean, Lean Manufacturing, and even in Lean Software Development, there is a GIANT FLAW in many of the “Lean” branded messages agile software people are acting upon, from the self-ordained Lean experts who are pushing them on software people.
This is a flaw that is not so obvious to many, and that leads to the bad management and treatment of software teams all over the world.
Let’s get to the point now.
The process of mass-producing physical products (Product Production), which is done on production lines, and the process of designing and developing those products (Product Development) are NOT comparable in many useful ways! It will be obvious in a minute.
“Product Production” is not the same as “Product Development”
Not in the Manufacturing world, and not in the Software world.
We really need to stop dispensing examples, metaphors, and corollaries that match or correlate these two kinds of activities.
This kind of hyperbole is just naïve and is misleading everybody to think that the act of fabricating/building tech products is like the act of manufacturing products on production lines!
Have you seen a production line?
Product Development is not done on Production Lines, even in manufacturing!
What is Product Production, Then?
Product Production in Manufacturing
Manufacturing production lines are about the mass production of a pre-defined “product unit” from its component parts (raw materials or smaller parts).
Once all the parts are assembled into the final product, they are then distributed to buyers/end-users. Think logistics.
These kinds of physical products are physically “assembled” from other parts. Some of those parts are “fabricated” from raw materials (i.e., cut out, machined out, stamped, milled, or sprayed), and some parts are pre-assembled (by other similar processes). Then all those parts are then joined together with various fixings (i.e., welded, screwed, glued), and thus, the product is “built” as a “unit” of production. A product unit.
Did you ever consider who designed this assembly process?
The completed product unit had to be carefully designed to be assembled by fitting parts together in a pre-determined sequence of steps according to (a.k.a production plan). Those parts had to be designed further to contain additional fixings to do that (e.g. flanges, bolt holes, folds, weld points, etc). This production plan was then encoded into machines and human processes to be followed to the letter (no uncertainty, no creativity, no flare) the same way every time.
The machines and the humans doing this “assembly” were pre-programmed/trained to “create” the product unit in the “right way” — the most efficient way and the only way. The product units are produced in quantities (large or small) in a sequence of steps and then packaged together and distributed (shipped) to buyers and consumers.
If you have ever built anything physical in your life, say: in crafts or hobbies, or cooked a meal or assembled IKEA furniture, AND have done that with more than one copy of the “thing” in the same batch of work, you’d know exactly what this kind of production feels like. Rote and tedious.
Product Production in Software
Now, as a comparison, let’s use a typical SaaS software product to describe the differences in the production and distribution of software products, as opposed to manufactured physical products.
Be aware: In software, we have the term “Production (noun)” which is used often to describe the environment in which our software is deployed and executes (other terms include: ‘staging’ and ‘live’, etc.). Do not confuse this use of the term production with the activity of product production.
“Manufacturing” software products, a.k.a “building” them, looks like: compiling their codebase, and verifying them with tests (on a central machine — a CI server). Then, if successful, versioning and packaging the compiled binaries (merged with some configuration files) into a set of deployable package(s) in some file format.
“Distribution” for software products, a.k.a “deploying” them, looks like: copying these package(s) to a set of machines (usually in the cloud) and restarting those machines to use that new version of the software.
That is, in essence, what production and distribution looks like for software products.
It's manufactured once, and distributed once, and all done by pre-programmed machines.
Incidentally, this process takes minutes to distribute the produced “product unit” to millions of consumers, over the internet!
Incidentally, nobody in the software industry actually uses this term: product production! to describe this process. But it is actually a fully automated production line!
What is Product Development, Then?
OK, so if that is what we mean by Product Production, then what is Product Development?
Product Development in Manufacturing
Let's take a company like Toyota, which makes car products. They are the classic production line company that most lean and agile zealots think they understand, and also, the term “Lean” originated from Toyota way back when.
Did you know that any particular car being assembled in their factories may actually have some unique choices made by the buyer when they order the car to be shipped to them, like: its color and some luxury add-ons like engine size, a roof rack, running boards, leather steering wheel, and power windows, and all that stuff. All of that “product variance” will be assembled into this specific car for this customer by humans and machines on the production line itself. It is a “smart” production line, programmed for each car assembled on it.
But the thing to understand is that those humans and robots (on the production line) that are assembling that particular custom-configured car are NOT doing any research, testing, nor validation of the unit they are producing, nor are they doing any actual design of this specific unit! It was all done prior to this process for them.
There is no design or engineering work going on in this assembly process — it is all production work. This process is by the numbers. It's infinitely predictable, measurable, and tightly controlled in time and money. It is all pre-programmed, and the process repeats itself in the same way for every car produced on this production line. This is product production, not product development!
Despite the fact that the agile process “experts” (in the software world) think that: designing, testing, validating, building, and measuring product development in terms of its features could look like cars going down a factory production line! It is NOT, far from it.
That is the grand flaw in the teachings of Lean Manufacturing in the context of software.
I bet you’ve never seen what Product Development of a car looks like?
So here you are.
Yep, they are designing a new car out of modeling clay with their bare hands and hand tools!
They are testing and validating their hand-crafted designs with 3D CAD tools on computers, in wind tunnels, and in road simulators, and on real people they invite to judge them. Tweaking and refining prototypes before they are satisfied with the final design.
What you see here in this image is just the car's cosmetics. But look down at the bottom of the image. Do you see a metallic prototype of a chassis already in place?
Hundreds of people and months of work have already gone into designing and testing the chassis and drive train, the engine, and other mechanical parts, prior to this process. In fact, those whole subsystems, like the chassis, are often borrowed from other models of cars, gone before! You are not supposed to know that, but it makes sense when you know that the cost of getting a whole subsystem, like a chassis, working right is super expensive. So reuse is inevitable.
Then there’s all the testing and compliance and what-not, you don’t see here, like crash testing, market research, and testing its handling on race tracks, etc. It's a huge and expensive process to design a new car.
It takes months to years to complete the process. Long before the production line enters the picture, and guess what? Some of these designs never make it to the production line! Ever!
The point is that this is product development in the manufacturing world. There is no production line here. The production line is probably in another country.
None of this model of car is being produced yet. This car is still in its design and testing phase!
Of course, the rigor of testing something like a car is nothing like testing software products. In software, we also don’t have all the regulatory compliance to comply with most software products (yet), although hardware products have plenty of safety & environmental ratings to acquire before they can go to production.
This activity of sculpting a car in clay, then refining its attributes, and testing and refining it is far more like what we do in tech product development, with the: Learn -> Build -> Measure process you learned about Lean.
Except that Eric Reis (forgive his developer-biased ego) states that you should start with the Build step — cute.
Product Development in Software
I’m not going to bother to explain in detail how software products are researched, designed, measured, and engineered over multiple iterations and through multiple failed experiments.
Most of those reading this article should already know that world intricately (even if most don’t get to experience all those critical activities— sadly).
I simply wanted to make the point that, like in manufacturing, product development in software is not done on production lines by robots and armies of people doing specialized precision tasks, churning out the same things over and over again, far from it.
But nonetheless, the “process experts” (who have learned something about Lean manufacturing) think they have understood the mechanisms and the benefits of it, and how it came to be, then go on to try to apply that mindset to software development, insisting on forcing us into that cruel optimized production line model. It is a scam!
I’m all for eliminating waste, reducing motion, optimizing the whole, and applying a bunch of other principles of Lean. I’m just not up for being treated as a robot on a production line, performing the same assembly tasks in a predictable and optimal sequence. Just because some manager thinks that’s what should be going on here, who has no idea what is actually going on.
Let’s recap:
- In Product Development, there simply is no production line!
- There are no machines nor humans that churn out identical product units of code (and test it) in a factory line.
- There is no pre-programmed set of instructions on what to build, how to build it, and when to build it
- and there is no master “production plan”,
- and no labor force to assemble its parts under an optimized budget.
None of this can possibly exist in software.
Designing software products is not a linear sequence of predictable planned tasks that can be optimized to fit a budget.
Get over it, “process experts”! You cannot have that certainty.
It’s about innovation and experimentation, and it's about change and adaptation over long periods of time, by smart creative, and innovative people who work together in non-optimal ways to create new innovative things that change the world.
Yes, you can have conventions, standard procedures, good practices, techniques and tools, and all that.
But there is no standardized process to follow that works no matter what the product is.
You cannot turn developers into dumb robots, and neither does the introduction of AI.
Stop the Line
Still don’t believe me? that product development and production lines are not comparable?
OK, ask yourself this.
Question: When a problem occurs with a robot or a machine or a person on a manufacturing production line, that has the effect of stopping production (i.e., a machine breaks). What do they do in the factory?
Answer: They stop the production line and rush over to fix the problem, wherever it is broken, and however it is broken.
Yes, yes, yes, they may only shut down one of many parallelized processes that are now broken to prevent the whole factory from stopping (but that is irrelevant!). The point is that they stop the work, identify the issue, and then fix it right there and then.
The robot/machine/person is “fixed”, restarted, and the process continues as it was before. Sometimes, if the machine/person is broken, they are replaced with a new working one too!
How are they able to do that so efficiently?
Because they can fix it, there is generally a known fix for all possible problems that could occur, as there is only “one way” being used to assemble a part of a car in a production line— the most efficient way.
It breaks -> you stop -> you fix it -> you resume.
That is how it works in a manufacturer’s factory. Now, if you have smart, empowered people on the front line who are able to do that any time, and have been doing that for a long time, then you have “Lean Production”.
Now, let's compare this with just the “Build” step of software development, never mind the “Measure” and “Learn” steps. We will spare you the gory details when those are in the mix.
Question: what happens when a problem is encountered in software development when those problems stop the process of getting the software written?
For Example, a developer is not able to solve a complex problem in the coding of the design? Perhaps they don’t exactly know how to solve it (lack of knowledge/experience), or don’t know the technology well enough (lack of skill), or cannot find the problem/defect that is preventing them fixing a specific problem (lack of understanding)?
Answer: They simply continue their work by “working around” the problem and “selecting” another solution.
Yep, you heard me. They work around it! — as they totally should.
They certainly don’t want to stop their work and sit on their hands doing nothing. They find another way! Sometimes they ask their teammates for help (peer review). Other times, they just change tack themselves, and change the design. Sometimes, they stop, investigate, and innovate new ways of proceeding. Sometimes, they get hyper-focused and go down a rabbit hole for days, not communicating, eating, or solving the problem!
That creativity, that ingenuity and that adaptability is what we pay them to do, and why we hire smart capable people. People to get things done.
How can they work around the problems they face in the first place?
Because in software, there is always “more than one way” to implement any solution in software. Their “next way” may not be the most optimal way right now (or it may be equally optimal), but that’s not going to stop them from trying to get the job finished.
They just find “another way” to solve the problem. And we love the fact they can do that. Because the alternative to that is orders of magnitudes more expensive than that!
It is called “soft”-“ware” for a reason — you know!
You can’t do this on a manufacturing production line. No manufacturing production line does that. It is far too late and far too inefficient in a production run.
So, in software development, we don’t stop the line since there is no line to stop since there is NOT only “one way” to proceed. There are many ways to proceed.
As Mik Kersten deftly illustrates in his book Project to Product, in software development, we don’t behave as the workers/machines/robots behave on a linear production line. We behave more like we live in a network of interconnected and related solutions.
Like: the network of airports across a country.
If we are flying from one place (say Dakar, top left) to another place to another place (say Brazzaville, bottom right) on a multi-hop journey, and one of the airports on the way that we want to land at is closed for bad weather (say Bamako, or Libreville), we simply bypass that airport (workaround) and continue our journey via another airport close by (like Conakry).
You can only do that when you have multiple options at hand. Sometimes you can even create alternative options when you need to, too! That’s one of the major benefits of the adaptability of software.
Product Development (of any type) is not a linear sequence of planned activities, it is a series of activities on a graph of possibilities, some planned, other unplanned.
This means that product development in software is not and never will be a linear sequence of predefined tasks that are predictably strung together to create any part of a product. Therefore, it can’t ever be a production line.
Forget it!
You are fooling yourself, and likely causing harm to those who practice and execute this kind of creative process.
Where Does It All Go Wrong?
So many people these days get into software late in their careers, particularly senior/middle managers and non-technical startup founders.
They haven’t yet learned and understood the fundamental non-linear processes required to design and make and refine software products.
The agile process “experts” (many of whom have never written a line of code in their lives) are often culpable of this too, in their bid to seek organisation-wide “agile” homogeneousness, where everyone must do agile the same way, their genius way!
Then unchecked, these people go on to define, manage and optimize these processes as if they were executing a sequential, linear production line that spits out features and fixes that must be predictably delivered on time and on budget.
Why?
My guess? is that their underlying mental model of how they see the production of anything in the business world stems from examples from the past:
industrial revolution -> mass production -> running an optimized business -> scheduling specialists to get things done to a plan
That’s how they think Product Development works, too, because all they’ve ever seen in the business world are examples of Product Production, and that’s what worked there.
So it's kind of understandable that this is the only mental model they have seen of fabricating anything in the business world.
So, when it comes to business, the go-to mental model for the process of fabrication of products to them is: manufacturing a car from pre-fabricated parts — rather than the process that goes into designing that car from scratch.
Perhaps, if they had had first-hand experience of using their own hands to make things in the world (design and craft from scratch for another person), they may better understand this complicated discovery and design process. They may come to realise it in time, but not until it is explained in detail and demonstrated to them.
More likely, most of these people have not crafted anything substantial in their careers, and no one ever told them that doing Product Development is more like the craft of woodworking or goldsmithing. Or more like designing and sculpting a car in clay models instead of assembling ready-made cars from parts with robots. So, they’ve never given it a second thought.
Perhaps, they see rooms full of programmers sitting at workstations today, and think that it looks like a modern-day software factory line? Who knows for sure?
AND, it is so tempting, when under financial or market pressure, to try and reason about how to simplify these complicated creative processes and redact and reduce them to predictable simplified linear processes that anyone should be able to execute — like they did in the mass production sweat shops of the 1900's.
That’s just NOT how designing and engineering great software products work. Folks! No, not at all.
