Connecting the Dots: My Journey with Lean Product and Process Development

It was October 13, 2021, when I presented my talk at LPPDE, North America. This was a significant moment for several reasons:

• • It was the moment that I realized that I had been accepted into a community that I had admired for years
  • It was also the moment that I realized that there was a need to bridge academia and industry
  • Last, it set off a chain of events that would lead to my return to industry and joining the LPPDE board

My journey into LPPD begins with a single course taken during my master’s program which introduced me to the world of structured product development methods.  Wide-eyed and bushy tailed, I joined GE Healthcare with a genuine desire to work on product development process methodology, to which the response was “Go away kid, come back when you have 10 years of line experience”. Undeterred, I did what any rational person in that situation would have done, I decided to pursue a PhD, thinking (naively), “Then they will have to listen to me!” Two years into my PhD program, however, I took a leave of absence and joined Hewlett-Packard’s Laser Printing business.  Before you question my fickleness, I eventually finished my PhD and after 7 years of product development work, I joined the faculty at RIT, where my focus was systems engineering and product development. Three years ago, I returned to industry to work at A.O. Smith to lead their efforts to integrate lean principles into product development.

As it turns out, I believe that it was only through this journey that I could have arrived in the place I now find myself. That one course changed the trajectory of my whole career.  Had I not had the experiences that I had at GE, I would not have had the grounding nor the context necessary to guide my doctoral studies.  At GE, I was struck by the fact that the success of projects seemed so heavily dependent on the specific project manager.  At the time, I thought that success or failure should be independent of the people.  I was both right and wrong about that notion.  The “wrong” part was thinking that success or failure would be independent of the people involved, the “correct” part was that it can be less dependent on specific people.  A fundamental tenet of lean is that it is all about the people. So yes, sound processes are crucial, but so is an environment where people can be their authentic and best selves.  Process and environment must both be in place.

Had I not returned to HP, not only would I have not been able to study an actual development environment, I would not have honed my product development skills.  While at HP, I was fortunate to have held a variety of roles in different functions, but always with a cross-functional lens and always with product development in mind.  My first manager had the foresight to loan me to the product development organization, even though I was a manufacturing engineer. My second manager allowed me to integrate supply chain and warranty considerations to influence product development decision-making.  In my last role, I was explicitly integrating marketing considerations into product architecture decisions. Not only did I get an end-to-end view of development, I saw first-hand the value of making decisions from cross-functional and life-cycle perspectives.

Had I not become a professor, I would not have had the opportunity to think as deeply about product development as I have.  My experience as a researcher at RIT afforded the opportunity to deepen my understanding of systems thinking, systems theory, systems engineering, product development and lean principles.  My time to think deeply about each of these allowed me to appreciate the beauty of the interconnectedness between all these concepts. Coupled with my industry experiences it also allowed me to see why Lean Product and Process Development Principles truly are a superior approach AND why they are so difficult to implement in practice.

And finally, had I not returned to industry, I would not have been able to put those ideas into practice to test what works and what doesn’t. So what have I learned? What can I share about the value of these transitions and experiences? The first thing I would say is that there is a lack of appreciation for the importance of what happens at the interface between “things”, whatever those things are.  Whether it is at the interfaces of subsystems, between functional departments, between hierarchical levels, or between organizations, the most interesting stuff (and the greatest disasters) happen at these interfaces. The second thing I would highlight is the lack of appreciation for the need for cognitive diversity on teams. I credit Doug Wilde for illuminating this in my doctoral studies. I will simply highlight here that I believe three types of thinker are needed for successful product development teams, those that are:

• • reductionistic – that is those that see the world bottoms-up and are excellent problem solvers in their domain
  • holistic – that is those that see the world tops-down and are really good at seeing the big picture, driving vision, and asking the right questions to drive the solution of the right problems
  • both holistic and reductionistic – these are the people that are true integrators and also very rare, but when you find these people they make all the difference in the world

These are two reasons that I believe that LPPD is a superior approach. A major benefit of the LPPD principles is that they explicitly bring attention to the interfaces and interactions.  Practices such as compatibility before completion, the use of cross-functional development teams, and the capture of knowledge expressed as tradeoff surfaces and feasible design regions contribute to this. The power of cognitive diversity is harnessed in a variety of ways. The insight that the project needs a visionary leader with strong technical skills, and market insight – the entrepreneurial system designer (ESD) – is a powerful insight.  The ESD provides the project focus, drives integration and helps resolve ambiguities and tradeoffs.  As valuable as the ESD is to a team, they must be balanced by a team of functional experts, with towering technical excellence (a term borrowed from Jim Morgan that I love).

Clearly there is more to LPPD than this, and the magic of LPPD goes beyond these two observations, but they help to illustrate why LPPD is so powerful. Product development is hard, and it is counterintuitive, largely because it is a complex sociotechnical system. As a system, LPPD helps to effectively deal with the hard and the counterintuitive.

As Steve Jobs reminded us, "You can't connect the dots looking forward; you can only connect them looking backwards." As you reflect on your own journey with product development, what dots can you connect? How do these insights lead to improved product development performance?  How have you seen these insights manifested in LPPD?

Group Discussion Page