Seven years into running a services business, we’ve recently recognized a pattern across several of the projects we’ve done. The pattern is that the customer wants to outsource the initial development of a product but also wants to bring subsequent maintenance engineering and feature enhancement in-house.
This pattern doesn’t apply to all customers or all projects, but I’ve now seen it repeated by three customers in three pretty different industries. Not being the sharpest knife in the drawer, it’s taken me that much iteration to see the logic behind it.
I think there are four reasons this strategy can make a lot of sense:
First and most obvious, building the 1.0 version of a product often takes a larger team than maintaining and enhancing it. In this case, the merits of outsourcing the first version are clear: The customer gets the product to market quickly, without taking on the liability of a larger permanent staff.
Second, there is sometimes a gap between the expertise a company has and the expertise needed to get a new product built. When you hire a team that has the deep technical knowledge you need, they should — if they are good — educate your in-house staff at the same time as they work with you to build the first version of the product.
Third, there is often a benefit to be gained by performing brand-new development offsite, separated from the distractions that can occur at company headquarters. I call this the skunkworks rationale after Lockheed’s famous World War 2 era project of the same name. You want the 1.0 development team completely isolated and heads-down on their work.
On the other hand, it’s often best if the team performing enhancements and maintenance is in frequent communication with other groups within a company, such as sales, customer support, and marketing — so it makes more sense to have this team on-site.
The fourth and final rationale is a little more touchy-feely. I’ve come to believe that the personality type and skill set needed to successfully lead a 1.0 product is different from that needed to successfully drive it forward after the initial product launch.
The 1.0 team lead is often someone who has a broad technical background, which enables him or her to select an appropriate approach from amongst a huge range of options. Engineers working on a new product need to be comfortable with uncertainty and change because a blank whiteboard is sometimes a bit daunting, and a lot of times you’ll learn and adapt your approach during the development process.
The new product team also needs to be comfortable with imperfection, because even for the best products, the features you are able to get into the 1.0 product are merely a down payment on when the product will ultimately become.
Meanwhile, the team responsible for enhancing the product should have an exceptionally deep technical understanding of the specific technology areas appropriate to the product. This team normally needs to be detail-oriented and good at talking to, and interpreting the needs of, the product’s end-users. (Normally when you’re building the first version of a product, there are no end-users to talk to, so a lot of times you need to make educated guesses about what they need.)
To stereotype the two personalities, the 1.0 team is filled with generalists who are comfortable with uncertainty and willing to invent the process as they go along. (Even for a 1.0 product, it must be said that there are certain points — such as writing down requirements and a high-level design, and setting and then meeting a schedule and budget — that should never be skipped.)
Meanwhile, the ideal enhancement team is led by a detail-oriented specialist who is good at organizing chaotic processes and moving them toward repeatability.
I want to be clear that I don’t see either one of these personality types as better than the other, but I think they are different. And savvy business leaders can profit by identifying the differences and utilizing people in ways that maximize the overall organization’s success.
If “outsourcing just the 1.0” is a strategy you want to pursue, I recommend communicating that to your engineering services partner as soon as possible. Doing so should allow both sides to ensure a seamless transition between the two engineering teams.
Howdy Pierce is a managing partner of Cardinal Peak, with a technical background in multimedia systems, software engineering and operating systems.