Nearshoring on the rise?

I've been seeing a lot of articles lately about how IT and technology companies are pulling back outsourced projects from India and are looking nearshore, to places like the midwest, Canada, or even local providers in the same town. People point to the rising wages in India as the main driver - as salaries, especially for senior talent, get closer to US salaries, and it becomes harder and harder to retain talent in India, some companies are starting to feel like it's no longer worth the overhead of managing a team halfway around the world.

What I find interesting is that, for the past 5-10 years, in the software industry, outsourcing = offshoring = India. The three were (and still are in some circles) synonymous. What's happening is the industy is maturing, and realizing that India isn't the answer to everything. What I see, at least anecdotally, is software companies taking a closer look at their outsourcing mix, and asking themselves questions like - could some of this work be done better somewhere else in the world? How do I structure my teams and processes to be able to have a truly distributed team, with team members in 5 or 6 different sites wherever I can find the right talent? What additional value can I gain from outsourcing? What is truly core in my business?

The software industry, which is relatively new compared to other industries, lags behind in outsourcing maturity. Generally speaking, other industries like Pharma, Electronics, and Automotive, have more mature outsourcing strategies. They use a best-of-breed approach, where they deal with a portfolio of partners, each with their own specialty, to deliver parts of the product or perform R&D. They have a world-view, rather than a focus on one particular region. They depend on their partners to innovate - bring new ideas and new efficiencies, rather than simply "do X, Y, and Z" for a lower cost.

Nearshoring is on the rise, but we're going to see a rise in outsourcing to other locales as well - Eastern Europe, Vietnam, non-hotspot US cities, and Latin America are places my customers are talking about more and more. Overall, in the next few years we will see software companies use a more diverse outsourcing mix.

And if you don't beleive me, chew on this: last year Branham did a study on outsourcing that looked at outsourcing trends across industries in the US. The primary destination for outsourcing for US companies was... (drumroll please)... the US.

Facebook, innovation, and short feedback loops

I attended a very interesting event last night. BayCHI put on a great program called Learning to Create Engaging Apps for Facebook: What Works and What Does Not. This was my first time going to a BayCHI event, but apparently the audience was 2x the normal attendance, which tells you a bit about the Facebook phenomenon.

The speakers were the profs and students of the Facebook class at Stanford. What they accomplished and what they learned was remarkable. The students teamed up in small groups to create Facebook apps - some created several in the semester. Through iteration and experimentation, they found which practices and concepts worked and what doesn't.

Here's the astonishing part - some of the apps grew to 5 million users (and are still growing) in a matter of weeks, and were generating thousands in ad revenue.

A couple of examples:

Hugs: an app created by the teaching assistants using the best practices learned by the class. When I checked out Hugs, I found several of my friends in Canada have already installed it. The app was developed and launched merely weeks ago, so that tells you the reach of Facebook Coincidentally, this app had the biggest adoption in Canada, but they weren't sure why. I guess we're a nation of lovers, not fighters.

Send Hotness: An app that lets you indicate to your friends that they are hot. This app has over 100,000 daily users.

Love Child: My favorite among the lightweight fun apps - it lets you pair up with friends to create a virtual child, which grows and takes on characteristics depending on how you interact with it (dicipline it, hug it, buy it stuff, etc)

Not all of the examples were, ummm, totally inane:

Save the Rain Forest: A fun little vocabulary game that donates the ad money it generates to buying plots of Amazon rain forest.

College, The Numbers: I think this is one that has the most legs long term. This group teamed up with Kaplan to create an app that anonymously compares your SAT scores to other students applying to the same college.

So what did they learn? What were the best practices? What was really cool to me is that this experiment highlighted the best practices we preach at Macadamian to the extreme. The viral nature of Facebook greatly amplified "normal" adoption rates, and cause and effect, so the groups were able to see the results of their actions in a matter of days or weeks.

• Keep it simple. The simplest concepts caught on like wildfire. On the other hand, when a group put a lot of thinking and upfront design into their app, the app generally had very low adoption rates.
• Keep it simple #2: Simplifying the UI had huge effects on adoption. When a group made a revision to the user interface of their UI that made it easier to use and understand, their adoption rates shot through the roof.
• Measure: The class set up very comprehensive tracking systems using Google Analytics, so they could measure results of their changes in real-time.
• Iterate: Fail quickly and keep a very tight feedback loop. All of the teams were iterating and experimenting daily - finding out what works and what doesn't. Many of the groups that initially had low adoption rates released new versions of their applications that were growing into the millions by the end of the class.

I can't think of another pre-Facebook scenario where you could learn so much about design, social networking, and viral marketing in 16 weeks. With most products or applications it takes months to see the real-world effects of your design decisions. What a cool class! I have a feeling enrollment rates for this course will be through the roof next semester.

How to choose an outsourcing partner

One of my favorite questions in our Outsourcing R&D event was around how engineering leaders go about finding and choosing an outsourcing partner. The answers revealed some best practices, and also confirmed some anecdotes from my own one-on-one conversations with VPs of Engineering

In terms of finding a partner in the first place, first and foremost, companies tend to look to partners with whom they've worked with in the past. Sounds obvious, right? It's worth mentioning because sometimes we get caught up in the need for change; we forget how much we invested with our current partner in learning how to work together, and how much they've invested in gaining domain knowledge about your business. It's often much more efficient to work through whatever issues you're having with your current partners than to change horses.

Second, the panel advised you ask your network, both internally (have other groups used outsourcing successfully) and externally.

Finally, if you need to resort to Google for finding potential partners, take the time to do reference checks. Ask for references from companies of a similar size as your own, and ideally, in your home town, so you can get a sense for how they treat companies of your size, and how they work with companies in your region (how responsive are they, are time zones an issue, do they have someone "on-the-ground" and so on)

In terms of choosing the right partner, the panel had a number of good tips and tricks:

• avoid hot spots like Bangalore, where it is becoming increasingly difficult and expensive to find and retain engineering talent
• conversely, make sure your partner is in a region with good infrastructure - first-mover advantage in a remote location comes with high-infrastructure costs. When working with a partner, you don't want to be paying for basic infrastructure (PCs, Windows licenses, broadband, etc)
• use a local agency or consulting firm to help narrow down the field of choices
• match your partner with your company size; if you're a startup, or a small group within a large company, work with a relatively small (around 200 or fewer people) partner, where you can still have the attention of their senior management

Another tip I'll share from a similar panel discussion I organized in Boston - the RFP process is your surrogate for the actual experience of working with that vendor. How the potential partner behaves in the proposal and sales process is a good indicator, or at least the best you have, of what they'll be like to work with. Here are some tips for using the proposal process to pick the right partner:

• If you're not a Big Design Up Front (BDUF) company, don't do a BDUF request for proposal. Leave out some details on the project, so that you see if your potential partner can read between the lines, and if they ask the right questions. The quality of their questions is a great indicator of their domain knowledge and experience
• Do your own estimates, so that you have an idea of how much the project should cost and how long it will take, however, bear in mind that most studies show an outsourced partner, at least for the first project, will be anywhere from 50% to 80% as productive as your internal team.
• This one's tricky, and since I work for an outsourcing company, I have trouble advocating trying to trick your partner, but one tactic is to put an unrealistic deadline in the RFP and see how your potential partner reacts. If they come back with a proposal that meets the date, barring some miracle time-saving device, you should question their estimates.
• Beware of proposals that either have too little detail, or an unrealistic level of detail given the information you've provided.
• Finally, how responsive were they during the proposal process? Were communications open? And did they meet the proposal deadlines?

Hopefully these tips can help take some of the anxiety out of choosing your next partner, or at least help make for a more predictable outcome.

Deciding what is core

This post continues my report on our R&D outsourcing event in Ottawa. The next question asked by the moderator was "What can be outsourced, and what not?" The question triggered a sidebar on one of my favorite topics - what is core to your business, and what is not.

The panel had great answers to help guide you in deciding if something is core:

• If it's something that you can articulate as a difference between you and your competitors, it is definitely core.
• If it's something that needs to have very high quality, or will be consumed in high volumes, it is core

I find the first rule to be the most useful - it's simple and bullet proof. Every business has something they concentrate 80% of their effort on improving, and something they do better than their competition. It may be a technology - for Google, it is their relevance engine; for a gaming company, it might be their 3D engine. In the case of the gaming company, they definitely don't want to outsource the design and engineering of their 3D engine. But, they could easily outsource all the context pieces: the software that lets users build levels in the game or customize the characters, the portal that links the community of players together, the network engine that enables multiplayer play, the VoIP software that lets players communicate by voice while they play, and the e-commerce engine that bills people for connecting to the gaming network. These pieces are all important - you can't release without them, and some of them are very complex, but they are context - you need them to be as good as the competition, but focusing your internal resources on making these pieces better than your competition is not what's going to propel you to the top of your market.

Generally speaking, I find it harder for ISVs to articulate what is core and context, and decide what pieces of product development could be outsourced. For a telecommunications company, or a medical device company, the lines are clearer - the package design could be outsourced, the software is context so we can outsource that. It could be because ISVs tend to have technical founders, and some see outsourcing in R&D as a failure of their engineering team. In other knowledge-instensive industries however, like pharma, telecommunications, and consumer electronics, over 90% of companies use outside firms in R&D, and rely on a supply-chain of co-developers and outsourcers to develop products. In software, at last count (2006) about 30% of ISVs leverage 3rd party capabilities in product development. But this is changing, at about 10% a year, and I have no doubt it will catch up as the industry gets more and more competitive. I'm even starting to see a few isolated cases of software companies that have decided that marketing and product design will be their core competency, and who outsource the entire product function end-to-end, but this is rare.

One of the key takeaways from the panel is you need to know what is core, and what is not, and that your outsourcing strategy has to tie in directly into your product strategy.

Next post I'll wrap up with my notes from our R&D Outsourcing panel, and reveal how technology executives go about choosing an outsourcing partner.

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.

Designing for people with disabilities isn't a "special case"

I was sitting on the shuttle bus at San Jose airport the other day, and I looked across to see the wheelchair seating. What I saw truly floored me.

Nestled in the complex array of straps, hooks, and tiedowns was a sign that outlined the 14 steps (in paragraph form, no less) to securing a wheelchair on the bus.

Just reading and interpreting the instructions took me roughly 5 minutes. I'd say that strapping in a wheelchair is probably a 10 minute exercise, and that's after you've negotiated the wheelchair inside the bus in the first place, which would be no small feat. 15-20 minutes is an eternity for a shuttle bus that leaves every 5 minutes and makes a 10 minute roundtrip.

It was clear that they retrofitted the design of the bus to accomodate people in wheelchairs, but like any time design for people with disabilities is treated as a special case or afterthought, the designers failed miserably.

There are only a few things that stick out from engineering school (obviously money well spent), but I had a great course on design and human interaction. One thing that has always stuck with me is that, as an engineer or designer, if you consider how someone with a disability is going to use your product upfront, all users will benefit.

Quiz: Which is easier to navigate for someone pushing a stroller: an escalator or an elevator? Stairs or ramps? Which is easier to use for people with arthritis: those stupid, stiff, round sink taps that turn off when you let go, so that you have to try to hold with one hand while you rinse the other, or taps with long handles for leverage? Know anyone who has kids and has pushed a stroller? How many people have arthritis? Are they a special design case?

Back to the bus - it's also cramped, narrow, and high, so it's egress is difficult for anyone with luggage, especially the elderly. Do you think there might be people with luggage on an airport bus?

How does this translate to software design?

Using low-contrast between labels and buttons, or controls and background, like the trend to "metalize" a UI, may look hip, but it makes it much harder for people with even the slightest visual impairment to use. For example, I'm red-green color blind, which is a very mild color-blindness - in a nutshell, colors don't have quite as vivid contrast for me. When someone uses dark blue against black, the interface is almost impossible for me to use. Careful use of high-contrast makes it easier for everyone, but especially those with vision problems (know anyone who wears glasses?)

Another example in web design - using ALT labels correctly in images makes it possible for screenreaders to tell a blind user what the image represents, but it also makes it easier for the rest of us to know what the image will be while it loads, or search engines to index the page.

So, like me, if you take one thing away from this post, when you design a product, whether it be hardware or software, think about how someone who isn't quite as able bodied as you will use it, and you'll make it easier on all of us.

Customer satisfaction in Outsourcing

Two articles came across my inbox this morning that caught my eye, because we've been thinking a lot lately at Macadamian about how to bring customer service to the next level.

The first was an article about how recent polls show that customer satisfaction in outsourcing has decreased (ouch).

The second was a white paper from Tholons titled "Relationships at the Core of Successful Outsourcing Contracts".

Both cite that roughly 70% of organizations are dissatisfied with their outsourcers. The Tholons white paper highlights something interesting though - around 80% of respondents in their study beleived their outsourcing provider were meeting their contractual committments. Huh? How can you be meeting your obligations yet still have an unsatisfied customer?

Therein lies the kicker - the big secret that's sure to raise the hackles of anyone in legal - in a successful outsourcing deal, the contract doesn't mean squat. It's all about the relationship. Case in point: last year I put a panel together of VPs of R&D in Boston to discuss outsourcing best practices, and the panel agreed - if you get to a point in the project where both parties are pulling out the contract and arguing about what's written and what the obligations are, you my friend are in deep doo doo.

Contracts focus on meeting service levels and specific deliverables - or as the Tholons paper puts it "a fixed unit of utility at a fixed unit price for a fixed time period". If this were taken literally, quality takes a back seat. In reality, the customer expects flexibility when priorities shift mid-project, expects the outsourced team to treat the product as if it were their own, and expects continuous improvement. Often, especially in a fixed-price project, the contract is at odds with these goals.

The survey from the Outsourcing Center, cited in the Tholons paper, sums it up well - in the reasons for outsourcing relationships to fail, the majority is attributed to unclear expectations, poor communication, poor governance, and misaligned interests. Poor performance accounts for a small fraction.

In my own experience, the best projects I've worked had a clear and open line of communication between the outsourcer and the customer. Both show give and take and both feel comfortable picking up the phone at any time to tackle an issue head-on. Conversely, projects that didn't go well boil down to a misunderstanding or a gap in expectations. Sometimes, in a new relationship, people are reluctant to ask the tough questions up front. Either you don't want to ruffle feathers so soon or you're in a rush to get started. Often a frank conversation up front about what everyone expects of one another, how we will judge the project a success, and what makes it a win-win for both parties will save a lot of headache down the road... especially near release-time, when anyone who's worked in product devleopment knows, this is not the time you want to be having a conversation about misunderstandings and mismatched expectations.

On the subtle differences

My second blog post and I'm already off-topic.

Since moving to California from Ottawa, I'm slowly adapting to the subtle differences in the culture in which I'm now immersed - back bacon is Canadian bacon (or sometimes just "ham" - I haven't figured out if there's a difference but it all tastes good with pineapple on a pizza), a bathroom is a washroom (or is it the other way around?), and I now conduct my financial affairs in plain view in the bank (quite the opposite of Canada, where your bank manager leads you down a hushed narrow hallway to her office and locks the door behind you).

But the part I'm enjoying the most, and having to adjust to at the same time, is... it's OK to be frank. Especially in business.

This morning I was in LA at the Growth Capital Conference. Question period rolled around, and naturally, the moderator asked people to be brief.

In Ottawa, this means the audience member who gains control of the microphone has full licence to monopolize the next 10 minutes of the 300 other people in the audience by a) blathering on about their business - "Hi, my name is so-and-so and we're a leading provider of blah-blah to to Fortune 10000 companies" b) compliment the panel and c) pontificate at length about their views of the subject, before d) making a veiled attempt at a question that is really another comment.

And everyone listens politely and doesn't interrupt because that's what good Canadians do. We're so darn nice.

This morning however, you were strictly prohibited from touching the microphone, so that it could be yanked away should your lips start flipping off-topic. A few people were brave enough to start their question with "My name is X from company Y" before the moderator blurted "Could you get to the question PLEASE?"

If you're from Canada you're probably thinking "How rude!". Maybe... but it was certainly more respectful of my time. In the end, the Q&A was one of the most informative, insightful, and productive I've ever attended. And we got out on time.

Ramping up product development for Startups

A couple of days ago I participated in a panel moderated by Sean Murphy at the Startup Epicenter in Mountain View on Scaling up Product Development. Also on the panel was a VC and two serial entrepreneurs, and we talked about how to scale up from the original founders and gurus to a full-fledged engineering team.

Key concerns from the audience were how do I maintain my culture, and how do I compete for the best talent against guys like Google and Yahoo? The answer from the panel was pretty unanimous - before you start hiring, draft up a one-pager that captures your goal, your values, and your vision, and hire people that fit that mold. Sounds simple, but it's hard to do when things heat up. If you've taken a bit of time to write down your values and culture, you'll be able to verbalize that to prospective hires and to your network. You will start to attract people who want to work in that environment. From personal experience, when we figured this out at Macadamian, we were able to scale up faster. Word got around to the development community around Ottawa that when we say we want to build software the right way, we actually meant it. We're using the same approach in Cluj, Romania, to attract talent in a competitive market.

Some of other takeaways:

• Someone has to be wearing the product management hat from day one, whether that's one of the founders who has a talent for talking with customers and understanding their needs, or someone you bring in early on.
• Once you get beyond 5 developers, what should be your next hire? The panel agreed, QA. Get someone on staff who lives and breathes software testing.
• If you don't need the domain knowledge long-term, outsource it.
• Resist the temptation to hire a specialist in some particular technology because that's what you need today. You'll be turning on a dime, so hire people that are flexible, and are great engineers. Hire for raw mental horsepower.

Special thanks to Peter O'Blenis at TrialStat and Terry Cass at Thirdbrigade, who have both successfully scaled up world-class product teams and lived to tell about it, for spending a few minutes with me before the panel so I could learn from their experiences.