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.
In my prior blog, I talked about the need for Phase Zero before beginning development. During Phase Zero the team is focusing on three main areas:
- Understanding what the customer wants (and what knowledge, science, technology, and logistics are needed to fulfill those expectations)
- Defining the product (why you are doing it and for whom you are doing it). What is the strategy this product will take to address the wants identified.
- Taking the science discovery out of the development, so development doesn’t have surprises.
Define Product Strategy
Understanding in Phase Zero means understanding the customer’s job and understanding how your new product will fit into his or her use case.
How you define your product strategy depends on multiple factors, such as the competitive landscape, the maturity of your market, whether this product is disruptive, etc. If a medical device, what is the regulatory strategy? Does the product have defensible barriers in the intellectual property (IP) landscape? Any of these done poorly will cause the product to be a failure.
My experience, in multiple companies, has been with products that are truly innovative, perhaps first in kind. In these cases, even in the absence of direct competition, there is an urgency to get the product out into the market for multiple reasons, e.g., generating income, potentially being first, and getting feedback. The last reason should be the first reason. In this case, it is imperative that you get your product to market as fast as you can. Not by adding lots of developers. Not by inventing time accelerators. Rather, you must cut down the specifications you got from your customer to the bare minimum, a minimum viable product (MVP).
I don’t mean to suggest that deciding which small list of features to focus on is in any way easy. This is an involved process requiring lots of open communication and objectivity, and that can sometimes be a painful experience. But without this focus and understanding, the team becomes disconnected from the problem and development is chaos.
I have worked on multiple developments, where this process can start as a long laundry list. I have done this with teams interacting. In one case taking a list of thousands of features down to a basic dozen or so. This is the power of having multiple team members, from multiple disciplines, really understanding the customer needs and applying ruthless prioritization. As Kimberly Wiefling, author of “Scrappy Project Management”, eloquently puts it, think about prioritizing your own heart, lungs and kidneys as an organ to give up in an emergency.
The next step is to define the product strategy details. What technologies, procedures, logistics or medical device regulatory pathway are needed. I have found creative brainstorm methods conducted in a secluded or even off-site area to be an effective way to do this.
In one situation, I had been invited in as an interim head of R&D to work with a cross-functional team that was late in the development of its first med tech product. Late in the sense that they were supposed to be close to submitting for clearance, and late in the sense they were more than a couple of years behind schedule. Further, the technology was not complete (see next section). Essentially, there were too many deliverables for a first release product. I led the team through a prioritization process from several hundred items to do down to a handful of deliverables and a pathway where we could visualize an endpoint. We bucketed the items not in the first release to be worked on for follow on releases. This, and solving the technical issues (below), enabled the team to get the product submitted for clearance and soon after released to the market.
Take the Invention out of Development
The ability to innovate products involves invention of some new capability or some new technology. It is likely that all the technical feasibility of what is needed is not complete. Some teams assume it can be tackled during the “development” phase. This is a serious mistake. Trying to unravel difficult technical problems during development or even later after the product is released can be very expensive. It is not uncommon for problems to surface with products with customers that should have been resolved earlier. This can lead to huge amounts of time and money wasted in repeating tasks and dead ends.
To avoid this situation, shift the discovery from being concentrated in the middle of development to Phase Zero before development. This should include breadboarding or prototyping pieces of the product technology. I talked about this for medical devices in a previous article: “Taking the Pain out of the Medical Device Development Process”.
Not all new product development needs invention. In one division I led, the VP of R&D led the Phase Zero team of a next generation med tech product through a brainstorm process in which they invited outside vendors to attend. The purpose was to set the technology roadmap that minimized the invention required to get the product to market as fast as possible. It was a multi-day process that resulted in a product roadmap and plan that eventually led to a product that took the market by storm!
Phase Zero is a period of invention, exploration, and discovery that outlines the parameters of your product. Those parameters, in turn, dictate the nature of your product development process (or whether development should proceed at all).
But knowing the “right direction” for your product development does not necessarily guarantee success. You need to build the right team to drive development, which I’ll talk about in my next post. And the team will still need to periodically adjust their heading, swerve for roadblocks, and repair any flat tires throughout the development phase.
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.