In Product outsourcing, Core vs Context is a red herring

Sivaram Karuturi

The growth needs of a product company cannot be served with a project-centric mindset, which is precisely what traditional IT service providers are offering.

I recently came across a blog post from a leading IT service provider, suggesting that core IP development (for software products) should be retained in-house, and only non-core and contextual activities should be considered for outsourcing.

The blog used a 2×2 matrix to paint business criticality (from non-critical to critical) vs internal capability (from low to high), and proposed that any activity that is ranked high on these factors must be considered core, and further stated:

Core is something that delivers competitive advantage by leveraging relative internal capability that the team brings. Everything else could be considered as context; some may even be important and highly valued but could be considered context if it does not create differentiation or competitive advantage.

I strongly disagree with this myopic perspective, as it is at best a self-serving proposition, that not only does gross injustice to the genuine needs of software product companies, but also devalues the cutting-edge innovation capabilities and maturity of the numerous world-class providers serving this industry segment.

myopic.jpg

I intend to present a pointed rebuttal to the views expressed in the above cited blogpost, and offer an alternative framework that software product companies can use to make strategic and informed choices for achieving their business goals.

Core IP must be dictated by business value, not by internal capability

Gone are the days when one can offer a differentiating product or functionality, and exploit the first-mover advantage. We now live in a fast-paced world, where a nimble-footed competitor or a disruptive technology can dislodge even established market leaders, and make them irrelevant in the blink of an eye. In today’s connected landscape, the core customer or business value is no longer static, but is dynamic and continuously evolving.Therefore, the core IP of a product company must be dictated by the totality of the business value delivered, and not by internal capability.

Market demands excellence beyond IP

Even a cursory glance at the current technology landscape will reveal that to survive as a product company, mere IP doesn’t suffice, and excellence in every facet that contributes towards delivering customer value is a prerequisite for success. As my colleague Gurava Induri pointed out recently in a superb article on Growth strategies for software product companies:

Over the past two decades, successful digital unicorns such as Facebook, Amazon, and Google have conclusively proved that it is possible to excel in all value disciplines of operational excellence, customer intimacy, and product leadership. In fact, an unrelenting focus on delivering business value through a combination of value disciplines, helped them attain and sustain market leadership in an enormously competitive business landscape.

In the pre-digital era, it was widely accepted that to be competitive, an enterprise must be competent in all three value disciplines (the minimum threshold), but to be a market leader, an enterprise must excel in just any one discipline. As we have seen in the recent past, those days are gone. In the digital era, it is no longer sufficient to excel in just one value discipline, but excellence in all value disciplines is a necessary pre-condition for success of a product company.

Related  Software Offshoring - Keeping It Right

Core vs Context is a red herring

The earlier cited blog also suggested that certain activities such as product assurance and non-functional aspects of a product can be considered contextual and non-core, and hence can be outsourced.

This attempt to define what is core and what is contextual is a red herring, as it is a debate framed with control as the defining characteristic and has no relation to competency or value. And when it comes to delivering value, everything about a product is core.

We now live in an increasingly global economy with unprecedented freedom for movement of people, capital, resources, and services. If control is paramount, it can be safe guarded with appropriate policies for IP protection and market access. The right framework for this debate should be from the perspective of who is best suited to handle which activity, and what is the specific skill/expertise that they possess.

Traditional offshoring is passé

I think the root cause for this muddled proposition (core vs context) is the cocoon from which traditional IT service providers are operating. They are peddling an anachronistic model which was designed to serve the IT needs of an enterprise, to product companies that are trying to compete in a dynamic business landscape which thrives on innovation, speed, and agility.

Yes, the IT offshoring industry has evolved, matured, and grew exponentially over the past few decades, and in fact has emerged as one of the key drivers of global economic growth. But, it has also allowed many unsavory practices to creep in, which could pose an existential threat. As my colleague Kiran expressed in an insightful blog, Threats to traditional offshoring:

We cannot use tools of yesterday to solve the problems of tomorrow. I have no doubt that software offshoring industry will die, if it persists with current business model of maximizing profits at the expense of the customer. The industry must transform itself, adopt a business model based on collaboration and distributed innovation, and truly become an integral part of the customer value chain.

OPD = developing products as projects

I also believe that the inherent flaws in the traditional offshoring model get exponentially magnified as they are utterly deficient in serving the genuine needs of product companies. Even the Outsourced Product Development (OPD) service providers largely function with a mindset of developing products as projects.

 This is the crux of the problem, as product development must not be handled as a project. Product development is not only a continuous and iterative process, but is also evolutionary in nature. Fast-changing market dynamics, competitive pressures, evolving customer expectations, and disruptive technologies – all of them have a cumulative impact on the trajectory and evolution of a product.

crux.jpg

Lessons from the Toyota Way

 There is a lot that the technology world can learn from pioneering manufacturers such as Toyota, in terms of how to build long-term, trusted partnerships with (component) suppliers/vendors. Through its unique Toyota Production System (TPS), Toyota invested significant time and resources to train all its tier-1 vendors (such as Denso, Aisin, and Araco), and practically replicate its DNA to achieve comparable levels of quality, productivity, as well as a continuous culture of learning and improvement. The manner in which its vendor ecosystem (including tier-2 and tier-3 vendors) responded and helped Toyota overcome the crisis of a major fire accident (fabulously captured in Toyota Group and the Aisin Fire), and keep its assembly lines running without a hitch is a tribute to the effectiveness of investing in building long-term, reliable partnerships.

Related  Mobile App Development: Own Team or an Offshore Partner?

 Product companies need Co-Innovation partners to deliver continuous value

 Product companies must realize that it is in their long-term interest to invest in building strategic relationships with innovative partners who can deliver continuous business value. They shouldn’t get trapped into making artificial choices between Core vs Context, which can have disastrous consequences in a landscape that demands holistic, software-enriched user experiences.  Product companies must reject traditional IT service models and seek Co-Innovation models that offer:

  • A strategic, long-term partnership based on trust, transparency, and collaboration
  • An engagement framework that puts them (product company) in control of outcomes
  • A partnership model that provides named resources and dedicated teams for retaining domain expertise and knowledge continuity, which are critical for product development
  • A model that offers flexibility, scalability, and risk-sharing

Download the e-book: