Using the Agile Methodology to Develop Physical Products: An Interview with Alex Brown

What is an agile product strategy?

In a perfect world we would have a crystal-clear vision of what our end product needs to be. But that’s not what happens – the market changes as we develop. So an agile product strategy needs to be able to move with these changes.  Some key elements of that include: 1) delivering the new product in progressive, incremental iterations; 2) structuring each iteration as a series of deliberate experiments to test what the market is looking for, and; 3) building rapid feedback loops into the process to channel that learning into the next design iteration. These structural changes and the underlying mindset shift help you stay on top of market evolution and adjust your approach rapidly, as needed. 

Why would someone use an agile product strategy?

In my mind it’s embodied by that moment of intellectual honesty you sometimes get when you begin developing new products and realize that neither you nor the customer can know what the market truly wants when you first set off on the journey. It’s the spirit of Henry Ford’s famous quote “If I had built what customers asked me to I would have built a faster horse,” or Steve Jobs saying, “The customer is wrong.” The market doesn’t even know what it wants so how can developers have a clear sense of what that product needs to be to serve a nonexistent market? So if you can have that epiphany, it fundamentally changes the way you would go about designing a new product.

Is agile product strategy strictly applicable to software development, given agile’s original purpose?

Absolutely not. The Agile community traces its origins back to the Toyota new product development process in the same way the LPPD community does, so Agile principles attempt to describe a more universal truth than just software development. It’s true that Scrum, XP and other agile methodologies really come of age in a software environment, and because of that there is definitely some terminology more catered to software. However, that doesn’t mean the same thinking can’t be used in physicalproduct or service development. In fact, we see Scrum, in particular, being used increasingly in major industrial product and service contexts like the aerospace industry.  There’s certainly value in establishing feedback loops in a physical product’s development cycle. The cadence may need to be longer to account for physical fabrication time, but with a little creativity that cadence is often much shorter than people think and they definitely get the benefits of updating their understanding of the product and the market needs.

How does an agile product strategy differ from what we think of as a “conventional” product strategy?

Good question. Well first I should say I don’t know of too many companies with a product strategy that is truly conventional anymore. But a conventional product strategy depends on the lead designer being overly-confident in their ability to predict the market.  It would typically involve a bunch of marketing folks choosing a market sector that they haven’t tapped into yet, doing a huge amount of customer research up front to determine and document what they want to make, then ordering development of a product, crossing their fingers and hoping that the product is a hit. Market testing happens only at the end of the development process, and only then do you find out what the customer’s perception is. You might be able to make changes at that point, but for the most part you’re committed. And at any rate it’s extremely expensive to make any big, sweeping changes at the end of the cycle. This is the sort of isolated design process that leads to the Edsel.  With agile product strategy, we are talking about a much more inclusive approach.

That’s a pretty convincing case for agile product strategy. In that sense, why don’t we see more companies using it in place of the conventional or semi-conventional strategies that are more common?

I think a number of modern companies do use elements of agile product development in bringing new products to market, such as occasionally asking for intermediate feedback, but they don’t think of it as an integrated approach.  The problem with that is that, like most good strategy, there is a self-reinforcing internal consistency to a complete agile strategy that falls apart of you remove many of the key elements.  So companies fail to achieve what they could with a more thoughtful and deliberate approach.

I think the key reason they don’t implement a full agile product development process is that it takes time and effort to explicitly state your product assumptions, develop and deploy tests of each of these assumptions, and continually update the product vision. It is much easier to use a “fire and forget” design approach, and as long as you don’t get badly burned you don’t know how much value you might have left on the table.  What we do see is that once one competitor in an industry starts to use an agile product development approach, it typically only takes six months or so until we hear from their competitors looking for ways to keep up.

Are there any limitations to using an agile product strategy?

There certainly are. You can try to compress your product development cycle all you want but you will still occasionally need to make some big design bets on how to architect your new product. It is very expensive to come back and change these design choices. For example, you can’t build a skyscraper on the foundation of a two-story home by “evolving,” but you can move the walls around and change how individual rooms are used pretty easily. It is definitely worth taking the time at the beginning of the design process to identify and research these key foundational decisions.

The concepts addressed in this interview were originally published in the post Maxwell Health and Agile Healthcare Strategyby Alex Brown.

Creating New Value and a Lesson in Fundamentals

LPPD is about continuously innovating to find a new and better way to deliver new value. It’s about creating the future. But I recently had an experience that reminded me that not everything should change.

Last month I traveled to Toyota headquarters in Japan with Jeff Liker for a research project. We wanted to learn more about the engineering and collaboration that created the Toyota New Global Architecture (TNGA)the strategy and innovation behind hydrogen vehicles, and how they had adapted and improved their development system to meet the increasing demands of the ultra-competitive global auto industry.


It had been over a decade since I’d last been at Toyota, and even longer since I’d first learned about the principles and practices that made up the powerful system of lean product and process development (LPPD). So much had happened to both Toyota and the rest of the world since then. And so as our plane crossed the Pacific, I wondered to myself, “How much has Toyota and their development practices changed since I first began my LPPD journey?”

Jeff and I were definitely not disappointed with our visit. From the shop floor to the test track, Toyota shared with us its game-changing new products, powerful new methods and breakthrough technologies. But what impressed me most was what had not changed.

LPPD, as practiced by Toyota, is still an enterprise-wide system that creates new value streams. It is not just a scheme for one-off products or a discipline solely for product engineers. So when Akio Toyoda, President and CEO of Toyota committed the company to creating “ever-better products” he was not just talking to product engineering. He was providing a “true north” for the entire enterprise. Directing everyone at Toyota to provide ever-greater value to the customer through their work on new products and processes. This meant improving both product attribute performance and improving the quality or efficiency of all product delivery mechanisms – especially manufacturing processes.

I’d like to share just a couple of examples of how Toyota continues to simultaneously develop products and processes focused on creating ever greater value for the customer.

The first example is how Toyota went about dramatically improving vehicle ride and handling characteristics. One way to improve a car’s ride and handling is to increase body stiffness. Consequently Toyota set an objective of increasing stiffness from between 30 percent to 60 percent depending on the particular car. One way to reach this goal is increasing the number of spot welds on the body. However, this can significantly increase cycle times and/or drive costly investment in the assembly process. In many companies this conflict would result in cross-functional battles, compromised product and process performance, and far less value delivered to the customer. But Toyota PD and PE engineers worked together to improve product geometry and develop Laser Screw Welding (LSW) technology that requires less than half the cycle time of conventional spot welding and less plant-floor space, yet still delivers the required body stiffness. Nothing less would have been acceptable. LSW also has the added benefit of being far more flexible than traditional spot welding for launching additional new products and can weld multiple material types.

Another product priority for Toyota is to reduce weight to increase fuel efficiency. One way to accomplish this is to engineer parts out of high-strength, lightweight materials that can replace multiple part sub-assemblies and be thinner gauge – thus reducing vehicle weight. However, some of these materials have to be superheated prior to forming. Traditionally, this has required very large, dedicated gas ovens that heat steel blanks in large batches, plus an added operation to remove the layer of oxidation caused by the heating process. While this might be an acceptable compromise for many companies, working in batches and adding operations in TPS is a non-starter.  Once again, Toyota PD and PE engineers collaborated to tailor blanks and create a joule heating process that heats blanks one at a time, in 5 to 10 seconds – and with no added operations required. While some companies are satisfied with improving their products with added costs passed on to their customer, the LPPD system embedded at Toyota enables them to deliver lighter, safer vehicles AND at even lower costs than their predecessors.

These simple examples illustrate Toyota and LPPD at its most fundamental. Leveraging collaboration, learning and innovation in product and process development to deliver solutions that maximize value to the customer.

So what did I learn on my journey? That in the midst of continuous improvement, Toyota is still grounded in the strong fundamentals that make up LPPD and focused on delivering “no compromise” value to their customer.  And by continuing their drive to deliver ever-greater customer value through both product and process innovation, Toyota can achieve improvements far beyond those possible by “product only” solutions.

So, is your organization collaborating to develop both product and process solutions in creating new value for your customer, or settling for compromise?

For me LPPD embraces both a driving passion to make great products and an absolute reverence for the ability to make them well. This is still the most fundamental, and perhaps most powerful way of creating new value.

Best Regards,