Startups and software engineers have hijacked Lean principles from the manufacturing and engineering industries, and swamped them with their own esoteric terminology.

However, maybe there is something for teams that manage a lot of repeatable processes to learn from them about their own Product-Market Fit?

Lean belongs to manufacturing?

I first read about ‘Lean’ back in 2007, before it was re-purposed for technology companies by the Lean Startup movement.  

I started with James Womack and Daniel T. Jones’ Lean Thinking, followed by Jeff Liker’s The Toyota Way and the inimitable book on the related subject of the Theory of Constraints, The Goal, by Eliyahu Goldratt.

At the time, I was just embarking on my own professional journey in manufacturing, and these books helped to shape how I understood processes and, in particular, the concept of waste.

Skip forward almost a decade and the Lean Startup movement was well underway in the startup world when we started Unifize.  It was amusing to read how Eric Ries and Steve Blank had applied lean manufacturing principles of waste to startups and ‘customer development’.

However, they also introduced a new concept in the form of a refrain to startup founders that confused and intrigued me: “Your product is not the product”.

At Unifize, we eventually understood that it meant your product was not just the piece of software on the cloud that the customer interacts with, but the sum of all parts of the entire business model.

Could the same principle apply to other processes and companies?

Communication & Information Flow

As we started developing our own software solution at Unifize, we were surprised by the speed and fluidity at which information flows from the customer / user to the product team to engineering to a release.  This could often happen several times a day, compared to the weeks, months and even years in physical product development.

We also discovered that the management concepts and processes were remarkably similar to manufacturing and physical product development, although some of the terminology changed.  

For example, software engineers would talk about ‘bugs’ while we would talk about ‘non-conformances’ in manufacturing.  However, both would talk about ‘customer feedback’ and ‘releases’.

Ultimately, we found that the only major difference was the speed at which releases, problems and feedback were implemented or addressed.  

If only I had been able to develop and release working prototypes several times a day, or identify, dispose, root cause and implement a corrective action on a non-conformance in my own manufacturing shop floor as quickly and effectively as we were able to while developing software at Unifize.

[Non-Software] Product-Market Fit

“…we have paid tremendous attention to the flow of materials through factories or the entire supply chain. But all too seldom do we sit down to analyze the process by which we plan for the information flow. These processes are stuck in the 1950s, and are based upon the organizational hierarchies we inherited even earlier than that.”

Let’s be clear: Digitization is not the same as Digital Transformation– Trevor Miles, Kinaxis

By speeding up this flow of information from the customer through the organisation (and back again), software companies seem to be able to iterate through their product development cycle more quickly and effectively.

Eventually, if they don’t run out of money, they achieve what they called Product-Market Fit, which is a (mildly irritating?) way of explaining that they have developed something that customers wanted to use and, in some cases, buy.

This exposure to the Lean Startup world and software product development left us wondering about the differences between how software and physical products are designed and manufactured.  

If we apply the same principle that ‘your product is not the product’ to physical products, and understand how information flows throughout their entire life-cycle, it might help us understand why product development takes so long and possibly how to improve it.

A representation of the core communication processes at a Build-to-Order manufacturer

The above diagram is an overly simplified representation of the core communication processes (information flows) at a single BTO manufacturer to process a single order from a single customer of a single product.  

The business process on the right hand side is relatively straightforward, which is in marked contrast to the communication processes required to support it.  Note that some of these communication processes are repetitive / predictable and some are ad hoc based on exigencies relating to that particular order at that point of time.

Cut the jargon, what does this all mean?

As we discussed in an earlier last blog, waste in areas like product development and engineering boils down to communication, communication, communication.

Furthermore, this communication waste is not just a function of what happens within product development and engineering teams, but is dependent on how communication flows through the entire supply chain of a given product or service.

To take the analogy to its logical conclusion: a ‘physical product is not the product’, but the sum of all communication processes in its supply chain to the customer.  

By reducing communication waste for these companies, Unifize could enable teams that manage repeatable processes to achieve or to improve their own Product-Market Fit, although we would obviously need to tone down the startup bizspeak.

However, before we could develop a solution at Unifize, we would first need to understand the shortcomings of existing communication technologies in more detail…

Did you like this article?

Get the latest Unifize content delivered straight to your inbox.

Leave a Comment

Sign up to receive our latest blogs!

Get the latest Unifize content delivered straight to your inbox