PDMA Blog

Two years ago, I heard a presentation on Lean Product Development at the PDMA conference, and it was all about Lean Manufacturing applied to product development. Today, I attended a panel with Michael Kennedy, Dantar Oosterwal of Sara Lee and Dan Shoenhair of Ping, alongside Sandy Munro and Mark Adkins. Dantar has been at the forefront of this work since he began working with Allen Ward when Dantar was with Harley Davidson.

If you attended this session, you may remember that I tried to help things along by asking someone to explain who Allen Ward is, and why his name kept coming up. I didn’t ask the question as well as I would like, and we didn’t get a good answer so here’s mine: Dr. Allen Ward was a professor at the University of Michigan who led a research program to study Toyota’s product development system. Together with his grad students, Durward K. Sobek and James Morgan, Allen sought to understand how Toyota’s approach to new product development contributed to their success with fast time to market, lower cost and higher quality. Dr. Ward began writing and working with corporate clients in the early 00’s, including my former employer, HP, to help U.S. companies adapt Toyota’s product development system to their own NPD environment.

We lost Dr. Ward in 1994 in a tragic accident. Since then, a few folks like Durward, Michael, Jim Luckman and myself have done our best to fill the very big shoes he left behind. Earlier this year, the Lean Enterprise Institute published his book, Lean Product and Process Development with Durward’s help to edit the raw manuscript. His voice and vision for new product development comes through on every page.

Today, Dr. Ward’s vision proved itself to be alive and growing. The only mention of Lean Manufacturing was a brief one, to emphasize that Lean Product Development was not Lean Manufacturing tools applied in product development. With that said, we moved on to more interesting topics, like how Ping increased R & D capacity and Sara Lee increased revenue from new products through their adaptations of the Toyota Product Development System. Sandy Munro provided his unique perspective on how pain creates breakthrough innovations and Mark Adkins shared his experience with moving a group from five phase gates to two, and in the process eliminating a lot of wasteful documentation in exchange for a leaner, faster PD process.

This panel showed that Lean Product Development is more than just “flavor of the month” – this is one change that produces sustainable results.

Cross-posted at Katherine Radeka’s Product Development Field Notes

Today at the Product Development Management Association’s Annual Conference, Marissa Mayer described Google’s unique use of iterative product development to enable breakthrough products.

She described the difference between Google’s approach to innovation, and the traditional “castle-building” approach. Castle-builders close the curtains, go dark for awhile and then release a produce when it is perfect (or nearly so). Google, on the other hand, will often release features very early, then rapidly iterate the product based on user input until it is perfect enough.

As a Web service, Google is uniquely positioned to make the most of this strategy. Ms. Mayer described Google’s sophisticated system for tracking usage data to provide hard evidence to answer such questions as “Which user interface is more effective?” that help them identify and fix problems. They can set their servers to redirect only a small number of users to a test site for a new version, and when they want to roll to the next one, it is as simple as rolling code into their production environment, a process they have honed.

One criticism of such an approach is that it leads to only incremental innovation. Ms. Mayer showed how Google uses this to lower the hurdle for riskier, breakthrough products. If something doesn’t work, they can just change it or kill it with little risk to the rest of their business. With a little creative thinking, other services companies can directly leverage the central principle to release imperfect products to small numbers of customers early and then perfect them with direct user experience input over time.

This is obviously much harder to do when a product consists of much more than lines of code on a server. However, creative use of rapid prototyping technologies may make it easier for us to get user feedback earlier in the process than we do now, which will make the development and launch processes go more smoothly.

How early do your customers start using your new products? How can you get them to do it earlier – maybe much earlier than you do now?

Cross-posted at Katherine Radeka’s Product Development Field Notes

I spoke to a gentleman yesterday who worked in a corporate office charged with aligning the various engineering teams within a large company that had grown by acquiring a couple of dozen smaller companies, all producing similar products. The company hopes to realize synergies by developing comprehensive solutions that draw products from multiple subsidiaries. However, most of the companies were founded by entrepreneurs, had home-grown processes at best, and could barely communicate about the basics of product development, much less actually collaborate on a new product.

This is an example where a high level, lean stage gate process makes a lot of sense. It’s nearly impossible to avoid the waste of reinvention in such a setting. A standardized, high level framework for product development helps by creating a common vocabulary and structure. When I call and say that I’m working towards my first proto tooling release and could use a little of your expertise from the product you just released, you know what I mean.

The risk is that such a process will lead to bureaucracy. In a large company, the temptation is strong to add in everyone’s pet action item and report, causing the lifecycle to eventually collaspe under its own weight. However, it seems that this company has avoided such pitfalls.

The teams have the ability to improvise within this framework to create a product development process that balances the needs of the corporate parent with the needs of the specific product’s customer. They are not overburdened with proscribed administrative reports and checklists to complete. Teams are not arbitrarily required to batch their work until after they pass a specific milestone, causing reinvention and time-to-market to increase.

How does your standard product development process balance structure and flexibility?

Cross-posted at Katherine Radeka’s Product Development Field Notes

In the afternoon, the conference had an Open Space session where the attendees “design their own conference.” Diana Larsen of Futureworks Consulting got us going with a description of the process and the ground rules, while we sat in one giant circle.

People nominated themselves to be session hosts, simply by writing a topic on a piece of paper, choosing one of two times and a location then posting it on the “Marketplace” bulletin board. Then we chose the topics we most wanted to discuss. “Butterflies” chose to work by themselves rather than join groups, but Diana claimed that butterflies would tend to cluster and I did see that happen. “Bumblebees” buzzed from session to session, pollinating one session with ideas from another.

For the first time, I participated in a lively discussion on “Cultural Change for Collaboration” where we talked about the importance of getting senior leaders to behave collaboratively themselves to foster collaboration in the rest of the organization. To do that, we need to make sure that people understand the relationships between collaboration and decision-making, which can take many forms.

I was a bit of a bumblebee in the second session, drifting between topics like Cultural Issues in Global Collaboration, How to Get Anti-social Engineers to Collaborate, and Collaborating with the “Man on the Mountain.” This final topic was an interesting lesson in collaboration, because the people drawn to it talked for at least twenty minutes before I observed that we all had a different picture of the “Man on the Mountain” – who he was and why he was up there.

I”ve organized conferences and I’m a bit of a control freak so I wasn’t sure how Open Space would work. But the topics were interesting, the session hosts and participants brought their passion into the room and the discussions were interesting and fruitful – much more so than an endless series of passive slideshows.

Cross-posted at Katherine Radeka’s Product Development Field Notes

In the morning, I attended a break-out session on Collaboration in Innovation by Bryan Jobes of Boeing’s Commercial Airplanes Division. He was a senior manager for the new Boeing 787 Dreamliner.

Here’s the thing that struck me: commercial aircraft designers have to balance trade-offs for a range of customers and end users from passengers, pilots, flight attendants, ground crew, airport infrastructure managers, passenger experience managers (or whatever they call those people who decide that those in Coach don’t need much legroom), capacity managers, bean counters, etc. plus a worldwide network of regulatory agencies. That they can do this and deliver an innovative aircraft in a reasonable (for the industry) timeframe seems like quite an accomplishment.

Collaboration is a given in this environment, and he provided a nice example of how Marketing, Product and Technology roadmaps work together to provide direction for a team making literally thousands of trade-off decisions.

Cross-posted at Katherine Radeka’s Product Development Field Notes

I’m at the Oregon Product Development Management Association and Program Management Forum joint conference today.

The keynote speaker was Sam Lawrence of Jive Software, speaking on Collaboration 2.0. He had a great but not very deep message about how today, it’s all about Web 2.0 – it’s all about collaboration, people, openness, participation. As a keynote presentation, it was perfect – broad in scope and entertaining in tone. While he didn’t offer any new insights, he did set up the deep dives in the break-out sessions very well.

I was most impressed with his use of presentation software (PowerPoint® is the most popular but I’m not certain that was the one he used). Most people use these things to present bullet list after bullet list, perhaps punctuated with a complex diagram. He used it completely differently. Most of his slides consisted of one word or phrase with an accompanying image, delivered alongside a rapidfire monologue. The slides provided a bit of an ironic twist to his words sometimes – think Steven Colbert’s The Word. Most often, they punctuated his main points like exclamation marks.

I still have the usual problem with slidesets – I cannot remember much of their content. But with this presentation style and the purpose of his talk, that did not matter quite so much.

Cross-posted at Katherine Radeka’s Product Development Field Notes

NPR is running a series of segments called “This I Believe”, where people submit essays about their beliefs, some of which are aired. Many are good to excellent, especially as food for thought about life in general. One recently has a connection to product development. It was on Oct. 9 2006 by Jon Carroll titled “Failure Is a Good Thing”. To read it or to listen, go to:

http://www.npr.org/templates/story/story.php?storyId=6196795

It rang very true to what I believe about product development. His comments about success and first time successes versus failures especially struck a chord with me:

“Success is boring. Success is proving that you can do something that you already know you can do, or doing something correctly the first time, which can often be a problematical victory. First-time success is usually a fluke. First-time failure, by contrast, is expected; it is the natural order of things.”

In product development, learning ‘early and often’ really can lead to greater success. Unfortunately sometimes quality programs and program management techniques can be misinterpreted or misused, discouraging the valuable ‘failures’ needed to learn. ‘Do it right the first time’, ‘Zero defects’, and low risk tolerance are some I have encountered being misused.

Sure, we don’t want to repeat mistakes that can and should be avoided. … Businesses do need to be financially successful overall. … Yes, the acceptable risk tolerance levels will vary over a program and the product life cycle. For example, it makes sense that less risk would be desired for changes near a product launch date. Such things should not be confused, though, with the failures related to learning, especially when pushing forward in new areas or stretching capabilities to new levels.

Many organization’s cultures not only discourage the type of ‘failure’ that promotes innovation and learning but go to the point of blaming or hazing persons or teams for such things. Similarly, they may reward or idealize the 1^st time success that may be those ‘problematic victories’ Carroll mentions. Both approaches can result in hiding of learnings, ‘dressing up’ how work is presented, reduced visibility of needs and issues …

Some companies are trying to have a different culture such as Google, where failures are accepted as necessary, and even thanked. See for example the article in Fortune:

Chaos by design. The inside story of disorder, disarray, and uncertainty at Google. And why it’s all part of the plan. (They hope.)

Adam Lashinsky. October 2 2006: 10:46 AM EDT

http://money.cnn.com/magazines/fortune/fortune_archive/2006/10/02/8387489/index.htm

Now look at Toyota as another example. Outsiders don’t see a lot of failures but it is an organizational culture that encourages learning and sharing the learning. They certainly have pushed ahead on many fronts. They also don’t take a lot of risk, at least when it comes to the actual product that goes out to market. Learning is one of the key fundamentals to the success and high productivity of the Toyota Product Development System, which is reported to produce 4 times the number of products with fewer resources. ‘Failure’ is translated into learning and is accepted in certain situations. Moreover, communicating it is encouraged; someone apparently will get in more trouble if they don’t share the learning than for making a mistake.

So there are different approaches and a balance to be had. Time will tell whether Google has found it and whether Toyota can translate its approach to a more virtual world. I’d wager, though, most companies are too far the other way – where they are not really learning, not supporting the sharing of learning, and therefore repeating mistakes and reducing success.

So cherish the bumps, bruises, scars, ups and downs! Acknowledge and recognize their value! Use them as you and your products move forward so you get the value out of them!

What are your organizations doing to succeed through failure? What are the impediments to sharing learning?