Guest blog by Russ Singleton
I’ve been fortunate, living in Silicon Valley, to be able to meet and talk with Russ Singleton, a very experienced R&D executive from whom I’ve learned a lot about how to structure an organization for successful product development. For those of you who can’t meet with Russ in person, I’ve asked him to author this series of blog posts describing his experience in developing highly complex, innovative new products—from semiconductor manufacturing equipment to molecular diagnostic systems to surgical robotics. I hope you’ll enjoy these conversations with Russ as much as I have.
-Aaron Joseph
Too often the post-mortem of a major product development results in a few hours of PowerPoint presentations. But a productive post-mortem or retrospective is more than just another meeting. And the real value is in reviewing the development process and creating action points.
The Basic Post-Mortem
The main concept of a post-mortem is to capture the learning of the team at the end of the project and use that as a resource for future product development. The purpose is to gather knowledge and insight that will improve the overall development process–to learn from went wrong and what went right. You will need to either record the meeting or assign a scribe to capture key points and list action items.
A successful post-mortem focuses on the cross functional integration of multiple areas rather than any specific technology or feature. It’s not about what happened in the lab or what occurred in R&D. The post-mortem should encompass the entire product development process and the entire product development team. Consequently, this meeting will likely be much longer than normal. I recommend having an agenda to walk the team through the different pieces and aspects of development.
Critically, the meeting should also provide space for team members to voice any issues or concerns. There’s no point to having a post-mortem if people refuse to openly discuss the development process and offer honest feedback. A post-mortem is often the only instance when people bring up certain issues. And it’s imperative that the team addresses them directly. Done right, a post-mortem can be an excellent team building exercise.
The Ideal Post-Mortem
A post-mortem can be a few hours, or an afternoon or over the course of about a day and a half. It may come with some kind of celebration afterwards to reward the team for both completing product development and committing the sufficient time for a post-mortem. This length somehow should be related to the complexity and duration of the project.
I worked with one company that promised a trip to Hawaii for the whole development team and their families if we launched the product by a certain date. Offering incentives for hitting benchmark objectives is nothing new, but this was an admittedly incredible bonus. Note that this development took four years, including the Phase Zero component, resulted in a complex automated capital equipment system, and created a whole new business for the company.
To make the trip tax-deductible, the company ingeniously scheduled the post-mortem to be done over the course of a handful of afternoon sessions in Hawaii. We also brought in an outside consultant to lead some team building activities prior to the post-mortem sessions. We debriefed the team, went through every aspect of the project and, because this was done as part of the post-launch celebration and as a team building exercise, everyone was at ease and eager to attend the meetings. It was never a stressful or rushed conversation. The team wasn’t afraid or hesitant to openly discuss what happened.
During each post-mortem meeting, different team members would present their perspective and particular piece of product development, eliciting feedback and introspection on a variety of areas. You don’t want one engineer only talking about the engineering aspect for the entire post-mortem. Presentations and discussions should be not just cross-R&D but cross-business, including marketing. Otherwise, the team is not effectively addressing all the issues involved with developing the product. What was the experience from a customer perspective? What was the development experience from a sales perspective?
Throughout the post-mortem, and for each section or aspect being discussed, someone should be recording action items, just as you would in any other well-organized meeting. At the end of post-mortem, review the list of action items and sort them into short-term, mid-term, or long-term actions. These points are not necessarily about what the next project will look like. They may address structural issues within the organization or difficulties within the development process.
Post-Mortem Pitfalls
The four most common pitfalls I’ve noticed are:
- Not creating a safespace for open discussion – A post-mortem cannot provide as much information and insight if the team is unwilling to talk to each other or unwilling to divulge their perspectives on the development process. This might require you to invest in some team building activities.
- Not committing a sufficient amount of time – More typical of startups, some companies choose not to afford to take everyone offline. But if the whole team is busy firefighting or dealing with customer problems, that’s all the more reason to have a post-mortem.
- Not recording action items – The end goal of a post-mortem is to have actionable knowledge to improve future product development. A team building session is great, but proactively improving the company’s product development process is better.
- Not following up on action items – There should be some mechanism to ensure action items get executed in some timely way. For example, build it into manager’s objectives or into a CAPA system in a medical device context.
Summary
Successful post-mortems cover all aspects of the product and all functions of the development. In the same way that a good product development team is greater than the sum of its parts, good product development is far more than just technology or R&D–it’s the culmination of a multitude of complex parts.
Development of complex products requires an understanding of your customer needs, understanding of the parameters of your product, forming teams based around effective leadership, risk-taking, flexibility, dividing large stretches of work into small micro projects, frequent cross-functional communication, and no small amount of gumption.
About the Author
Russ Singleton is a results-oriented high-growth and transformation executive with experience across MedTech, Healthcare IT, Genetic Sciences and Semiconductor Equipment sectors. He has a passion to maximize results for startups and global, mid-sized businesses. He does this by transforming culture, driving customer-focused strategy, and leading market-oriented technology innovation.
As interim VP of R&D at Medrobotics, a surgical robotics startup, he was hired to jumpstart stalled efforts to secure CE Mark for a surgical robotics product. After successful approval, he joined full-time to lead transformation of the R&D organization. Prior to Medrobotics, Russ has extensive experience including CEO, COO, General Management and VP R&D.
Russ holds a Ph.D. and M.S. in electrical engineering from the University of Illinois and a Bachelor of Engineering from the Pratt Institute. He is also a graduate of the Management of High Technology Companies program at Stanford University’s AEA Executive Institute.
Pingback: Successful Product Development: A Tale of Two Companies - Sunstone Pilot, Inc.