Outsourcing Core Competencies

I work exclusively with commercial software product organizations.  Organizations that must create products and services that thousands or millions of users must make an independent decision to use or buy.   This is in contrast to custom software companies that create software purely for internal use.  But since many companies have moved from custom to product software I often find companies with behaviors and practices inherited from their prior life as a custom software company, but one practice that really deeply bothers me is when I find a product organization that is outsourcing core competencies.

Don’t get me wrong, there are many things that can be effectively outsourced no problem.  I’m fine with using outside firms for supplementing QA, or for getting help with SEM or SEO, or for managing events, or for dozens of other activities which are not really core competencies of the organization.  But there are three things that I consider absolutely essential to build capabilities in-house if you are trying to become a world-class software product organization:

– Product Definition
– User Experience Design
– Site Architecture

Unfortunately, I have seen each of these three situations, but rarely with a happy ending:

– the company decides to use a firm to come in and define a new product or service
– the company decides to use a firm to design a new product or service
– the company decides to use a firm to build a new product or service

First I should emphasize that I’m talking here about products or services which are central to your business.  There are often some things that are not central.  By “central” I mean that if the service were to have a serious outage for some reason, it wouldn’t substantially impact your business.  It might inconvenience some people, but things would keep going.

A good example might be your company’s corporate blog.  It’s not the end of the world if the blog looks like it comes from another company, or if it doesn’t use the same user authentication system for entering comments versus logging into your customer service help desk, or if you can’t fix bugs in the software because you don’t have access to the source code.   In fact, this is often a good example of outsourcing because there are several companies that can create and maintain this blog software better than you can, and this lets you focus on the things that really are central to your business.

I want to talk here about the opposite problem.  This is when something is absolutely central to your business, but someone believes it would be better to hire a firm to do this work for you rather than build the capability internally.

I have two big problems with outsourcing core competencies.  The first concerns the consequence for the customer experience.  The second is the consequence for the long-term viability of the company.

In terms of the customer experience, the main consequence is that it typically ends up ranging from weak to awful.  But why is outsourced product software usually so bad?

– it is inconsistent – the site looks like it’s been grafted together from several sources (because it has).

– it is incongruent – because the firms didn’t really understand your customers or users at all (by the time they started to develop a bit of an understanding the contract is typically over).

– it is orphaned – there is no real accountability and ownership – the firm was just doing what someone told them to do in a contract or statement of work.

– it is unreliable – when something goes wrong, there is no single throat to choke; “we just are responsible for this one part and we think the problems are with that project you gave to another firm.”

The recent article “Holistic View of Product” describes how we avoid these issues in general, but this is a much more severe issue when core capabilities are outsourced.

But firms outsource for a reason.  I see four common reasons:

1) Because management is not really considering this a core competency and just viewing the web site or mobile device as just another “channel.”  The only way I know of to address this is to educate the senior management.  It’s really not a hard sell anymore as all you have to do is look across your industry.  Unfortunately, sometimes this requires a substantial loss of market share or revenue before they get it and take that hard look.

2) Because someone in management (mistakenly) thinks this will save money or at least they have budget for third-party contracts but not for direct hires.  In too many companies, especially large companies, the tail can wag the dog and businesses make poor decisions for the wrong reason.  If the company is lucky enough to have an active and enlightened CFO they can often help to correct this, otherwise it’s back to educating management as above.

3) Because the engineering organization is perceived to be so slow and/or the backlog is already so large that management believes they’ll never get this done if they have to wait for their own team to do this.  This is more complicated because it might be true that the current organization is moving too slow, but the only real fix is to correct this.  But very often the fault of the slow movement lies not inside the engineering organization but in the group that is continuously sending a firehose of features at them, and/or in the proportion of product to engineering staff.  Often the architecture is old and dragging the team down as well.  In any case, this can and must be fixed.

4) Because management does not believe they have the talent in-house to do the necessary work.  This is the hardest of all to correct.  Management’s perceptions may in fact be correct.  Maybe you don’t have the level of product management, or user experience design, or engineering capability that is required.  But of course it’s management top responsibility to develop a strong team, so this is probably more a symptom of weak management.  But this is the situation where I am most supportive of using outside resources, but using them to help develop the internal team and capabilities; not to just go create something and throw it over the wall.

Again, you can certainly supplement your team (especially user experience design, engineering and QA) with external resources, but never in the sense that you hand the keys over to other companies and you just play a project coordinator role.

To succeed long-term your company simply must get good at consistently innovating on behalf of your customers, and defining, designing and building products and services that your customers love.  It should be obvious, but hopefully everyone can agree that the product organization absolutely must become the expert on your customers, or you’ve got no real chance to do either of the first two (defining or designing).