Micro Projects and Other Practices

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

In previous posts, I have explained the importance of Understanding Your Customer, Phase Zero, and Structuring Your Team for successful development. Now for development of complex products with multiple subsystems, I will discuss some practices I have used in several companies to ensure better outcomes. Some of these can have a huge impact on your New Product Development.

Micro Projects

Relying on a single system integration at the end of development is always a risk. Without regular check-ins with each other, departments tend to drift apart. And without regular customer feedback, the entire project could drift away from addressing core customer needs. I have used instead a series of smaller, bite sized chunks of development throughout the product development phase to help identify the problems before they become too big. Or, “micro projects” for short. This is analogous to sprints in agile software development.

You still need to do the same things you would do in traditional development (a schedule, a Gantt chart, a swim lane, etc.) but the difference here is to break the big blocks of work with deliverables into micro projects just long enough that each one produces a measurable deliverable and short enough that you can visualize how you will get there. It could be 2 to 8 weeks in duration. It should be focused on verifying a critical part of the development path for the subsystem, including the different technologies involved. These could be cross functional, electrical/optical/software or biochemical, etc.–pieces with an endpoint that can be measured and demonstrated.

A benefit of this approach is that if the result of the micro project doesn’t work, i.e., you miss the functionality you are after, you need to learn from this failure and then repeat. This is the concept of iterations with the intention of learning on each cycle.

Prototypes with Customers

Complex products typically have subsystems, or even pieces of subsystems or partial subsystems. These partial subsystems will be the aggregate of many micro projects. As much as possible, the team needs to be building prototypes of these partial subsystems to work to demonstrable prototypes. These prototypes can be hardware only or software only or a combination of both, to test out the limits of your design.

And you also want to be sure that what one subsystem is doing will fit with what another subsystem will do. This, of course, is the concept of integration. Except that you want to be doing small integrations during the overall development long before the complexity becomes overwhelming. You should be setting up how you will test these outcomes, as those tests will be used again in larger integration testing.

At appropriate points, with subsystems sufficiently built and demonstrable, you should be getting customer feedback on these prototypes. You want to be sure you’re spending time and money developing something that actually provides value to the customer, not just a really cool piece of technology. Not all micro projects need to be tested with customers, but certainly ones that have a feature or a component that is relevant to their experience should be.

I worked with one company that had their departments essentially siloed. The mechanical team never communicated with the electrical team, for instance. This made it infinitely harder to test product iterations throughout development. Until a bigger integration later, the teams did not really know whether their integrations would work. And many times, they didn’t. By definition, the whole point of micro project subsystem integration checks is to identify weaknesses in how the pieces come together significantly before the whole system comes together.

Customer and Market Check in

Remember that a key aspect of Phase Zero was to understand the customer needs. That shouldn’t be the last time you check in on your direction. The market is always changing. You should be doing periodic check ins of the market dynamics, especially if you are in a competitive sector. Periodic reviews can also help teams pivot more quickly when it’s clear the current product is not going to satisfy customers. >Certainly, for long developments, say over 3 months, the product development team should be doing reviews on not only the status of the development, but the status of the market.

In one company I was in, the project team did periodic reviews. They had the right design, they defined the right parameters, and they did all the market research, and they were progressing nicely on the development. But the market changed and suddenly they weren’t making the right product. Now normally this is the sad part of the story where development is cancelled and a bunch of people are laid off. What happened instead was fairly remarkable. We did shutdown product development. The company had a portfolio of projects waiting for manpower. Because of this, we were able to pivot and deploy the team to initiate a new development.

Summary

These are some ideas to be able to catch problems earlier in complex product development, rather than wait for the finale of a big integration. These big integrations can be challenging. Break the large stretches of work into small micro projects. When possible, build prototypes in these micro projects and demonstrate to customers to get feedback. Importantly, when subsystems are sufficiently built, integrate them with other subsystems early in the development. If all the subsystems have been vetted along the way in micro project chunks, the testing and customer validation of the whole system is really a repeat of a lot of pieces built and tested already. A series of small hops is much more manageable than one big leap of faith.

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.

Comments from LinkedIn

Teijo Laine Systems Engineer at Reaktor

“Integrate early, integrate often, remember [to communicate] the value streams = win-win-win?”