Why Not Outsource? The Burning Questions Continue

This is my second post related to the "Outsource Product Development" roundtable we hosted in Ottawa this month.

After we asked the panel "why outsource?" we asked them "why not outsource"? The panel was comprised of companies of outsourcing beleivers, people who were actively leveraging outsourcing in R&D, so this question gives us an idea of what experienced managers see as the risks and potential pitfalls:

• It could have an impact on your own team - you have to be careful which parts of the product you outsource. Another panelist noted that this risk can be mitigated if you make it a point to integrate the in-house and outsourced team
• The risk of failure, and the costs of failure. Contrary to what some beleive, it's simply more difficult to manage an outsourced project. It requires at least as much follow up, if not more, than an inhouse project.
• It's difficult to forsee the hidden costs, such as management overhead, or the cost of bringing the product back in-house to be maintained once it has been developed.

The next question, what should you not outsource, spawned a good discussion about what is core and what is not core, which I'll cover in my next post.

Why Outsource? And Other Burning Questions Answered

Earlier this week we teamed up with Fidus and OCRI to host "Outsourcing Product Development, How to Minimize Risk and Maximize Rewards". I couldn't make it back to Ottawa for the event, but my esteemed colleague Francis took great notes. The roundtable consisted of engineering executives from Alcatel, Teradyne, Liquid Machines, and MXI. All have been directly involved with outsourcing in R&D.

In my next few blog posts I'll report on some of the questions asked by moderator Jim Roche, starting with my favorite:

Why outsource?

• To augment capacity, and deal with peaks and valleys.
• To reduce costs, and blend the cost of outsourced resources with your internal resources
• And the answer I liked best: Tap new ideas, inject new blood and innovation, and challenge your own practices.

The last answer was from one of the companies with the most outsourcing experience. To me, that answer indicates you've reached Outsourcing Nirvana, or the highest level of maturity in outsourcing. You're looking beyond the bottom-line cost savings and asking yourself "How can I use outsourcing to increase my top line? How can I use my partners to create better products?"

Another good answer came from a panel I organized in Waltham, MA: to let us do things we wouldn't otherwise be able to do. In other words, the panelist looked at outsourcing as a way to free his team to do tackle opportunities rather than being reactive.

Coming up: Why not outsource? What is "outsourceable" and what is not?" Stay tuned.

Here's to the next 10 years!

This month Macadamian celebrates it's 10th year in business. A major milestone makes me retrospective, and I can't help looking back to see how far we've come.

We founded the company in the midst of the bubble, when incredible amounts of money were being thrown at every crazy idea under the sun. When I joined, we were 8 people working out of a bare-bones industrial complex. I think that's one of things that attracted me most - it felt like a startup, in the positive sense. The founding team was passionate about what they were doing, and my interview was a very lengthy and serious affair, in stark contrast to other interviews I was having ("Pulse? Breathing? Good - expect an offer from us tomorrow"). I'm proud to say that a stringent hiring process is a value we've kept to this day. Like any decent startup, we wore a lot of hats. I was hired as the Web Developer/IT guy/Network admin/QA. One day I was building a Linux firewall (which I'm proud to say ran without incident for 5 years) and the next day writing a test plan.

We grew to 40, scaled back in the bust, and hunkered down. It wasn't the most fun time. Actually, it wasn't fun at all, but I think it matured us. Those two years were like a crash-course in business. Competition was intense and opportunity was scarce. It forced us to focus, and more importantly articulate why we're different.

In 2003, the R&D tap turned back on and since then we've grown to 130, added user experience design as a key capability, opened labs in Eastern Europe, and set up an office in California. We're doing less team-extension far more end-to-end projects, where we're being asked to help flesh out requirements, design the product, build it, test it, and deliver. We're still in the same industrial complex, but with much nicer furniture and paint on the walls. And I now wear two hats - a 50% reduction in hat swapping, which is a good sign we're growing.

What a ride! Here's to the next 10 years.

Palm dumps its hyped-up Foleo

I'm sure everyone will be blogging today about what Palm did wrong, that they saw it coming, etc. etc. etc.

What I found interesting about this news is that it highlighted how much it costs to build a flop. Palm is taking a $10M hit. Obviously, they believe that's only a fraction of the cost of actually releasing the product, which is why they are canning, or at least delaying the launch. The information they have, their gut, or both, is telling them the product won't be a success as-is.

We've been talking a lot about this lately at Macadamian, and our CEO Fred has written about it in his blog (so as usual, I'm taking his idea, rewording it, and passing it off as my own; what is it they say about imitation and flattery?).

Actually, it's more than talk- we're gearing our business model to help companies improve their batting average at product innovation. That's why we acquired Maskery, and why we're working hard at integrating the two teams and building an end-to-end method for creating software products. Macadamian has always been good at building products - helping people get good quality products to market faster and more reliably. What the Maskery team is bringing to the table is experience in helping a client make that product more successful commercially. How? In a nutshell, they know how to talk to users, and what questions to ask. And not "would you buy this product" questions; their strength is in things like user research and rapid prototyping - finding out early what aspects of the design will be an impedement to adoption and what will stop people from trading their hard earned cash for the product, before you spend $10M on development.

Think about it. In the past few years R&D teams have been outsourcing what they can to places like India. Most of the data says that, over time, you will acheive a 20% cost savings. Significant? Yes. Do you need to do it to be competitive? Absolutely. Macadamian has labs all over the world, and we'll continue to keep opening new ones in new locations as we scale. But lets suppose that, as an R&D manager, you are seeing a 20% cost savings through your outsourcing. How much more effort will it be to save 21%? It's more likely that next year, you will save only 19%, because of attrition and rising labor costs overseas. After a while, trying to squeeze out another 1% is diminishing returns.

At Macadamian we decided to change the game. What if you could cut another 20% to 30% of your product R&D budget? Think about it - if you are really really good, a few of your products exceed market expectations, most meet them, and some are total flops. What if you could cut your loss on your Edsels sooner - at the idea phase, rather than just before release when you've spent 10M greenbacks? Or what if you could improve your success rate, so that a greater percentage of your products met or exceeded their market expectations?

My favorite example is our collaboration with Imasight, who engaged Macadamian to build the software and design the interface of their medical imaging product. By visiting target end-users, and by going through our user-centered design process, we uncovered things like the fact the early prototype was difficult to use in a lab environment, because the buttons were to small and tightly spaced to be used with medical gloves. We went through a few iterations and redesigns early on, and now the product is out to market, and getting rave reviews from early customers. What if we had skipped that step, dove headlong into engineering, and released a design like the early prototype? Would anyone have bought it? Perhaps, but I can guarantee they wouldn't be bragging to their colleagues about it.

So did Palm do something wrong? Beats me. I wasn't in their boardroom, nor do I know anyone on the design team. I can tell you that you can avoid the same fate.