It is useful to view offshoring in the light of the evolution of the Indian IT industry, in order to understand what makes it work, and where it is headed. In the 80's, IT had just begun to emerge, with mostly in house software development, and government / public sector organizations accounting for most of the jobs. In the early and middle 90's, this exploded into the services area (disparagingly referred to as body shopping), to later evolve into offshoring towards the end of the decade. The end of the decade also saw the Y2K squib causing a ballooning of the industry to include anyone who could use a text editor. This decade, the first of the 21st century, has seen offshoring mature with solution development, and embrace product development too in a bigger way. This, in parallel with the growth of the BPO industry.

However, the spectacular failures of offshoring in the recent past have been in the product development and certain BPO organizations. There are some interesting parallels that indicate how offshoring will evolve in the future. These relate to the logical distance between the points in their value chains. Some banks, realising that their customers perceived service levels as not being high enough with these being remotely provided, moved these back to their countries. Similarly, software companies that could not establish the continuity between requirment generation, software development, and integration back into the receiving systems had to scrap their offshoring initiatives.

Ultimately, the differences between software products and solutions spill into the offshoring space. There has been substantially higher volume and success as far as offshoring solution development is concerned. On analysis, the fundamental difference in a product scenario is the continuity of the core ideas, and the growth of those in relation to the natural market for the product.

In other words, to offshore a project, you need to transfer the requirements across cleanly, and you are mostly done. In case of a product, the history of requirements, original design, technical implications of changes, current requirements, implications of what needs to be done and how, all need to be transferred offshore. This makes it quite complicated to execute successfully, and without a strategy around it, it is doomed to failure as seen in the recent past, where high profile product companies have closed their Indian software development arm.

Hence, a strategy that works is definitely going to require substantial investment of time in such a way that all the above information gets transferred. A better way to view this compared to just transferring engineering, is to do it as knowledge offshoring. The remote office must be seen as a place where knowledge of the product is built up over time, ultimately resulting in the ability to execute more and more functions around product management offshore.

A structured approach to this can be divided in the following phases, covering the following areas:

- What the product does

- How the product is built

- Maintaining the product

- Extending the product capabilities

- Implementing the product

- Understanding the product market requirements

It is obviously not necessarily to get into all of these areas sequentially, or even at all. Ultimately though, for many of the products on the market today, India itself will end up being a significant consumer, leading to many organizations having to get into all of these areas.

Initially, familiarity with the product is a no brainer for everybody. What is less obvious is that organizational functions that are linked to this may be instituted as a starting point for a remote office. Specifically, starting off by creating an offshore testing group lends itself well to the seeding of knowledge of the product at the remote office, and can evolve further into a technical support function and product implementation over time.

This creates an environment where an engineering team can now be trained initially on functions of the product without using the parent organizations time and effort. A purely engineering centric transfer would now be possible. Of course, initially this should be directed at the design and architecture of the product rather than requirements, to give the remote team a foundation.

A guided maintenance phase following this allows an offshore team to learn how to walk before they are made to run. At this time, a fair amount of involvement from the parent organization on development activities is still required, and much knowledge transfer is expected to occur even at this stage, since it involves a high percentage of corner case usage of the product.

Development of new features can require varied degree of involvement from the parent organization depending upon how well the offshore team is by now equipped to handle the requirement, and the nature of the coupling of the requirement to the existing product.

A sufficiently high volume of testing, engineering, and technical support in the remote office, establishes the ability to deliver implementations of the product at customer locations. Apart from this it creates both the need and ability to drive additional product management functions such as documentation to the remote office.

As the number of customer engagements grow, ultimately the remote office is now operating in territory that should be viewed from the business viewpoint as potentially being a market in its own right. At this stage, product management by a way of being able to evolve requirements based on utilization of the product with various customers is now possible.

An organization reaching this stage with its remote office, is at the point where it has created an offshore business rather than simply cut engineering costs by moving effort consuming tasks to achieve the location. This is the next level of value as far as off shoring of product engineering is concerned - where the remote office ends up being a profit center serving the regional market.