The Rise and Fall (and Rise again!) of Outsourced (Lean) Product Development


In their book The Lean Product Guide, Linda Luu and Paulo Caroli provide a short list of principles and practices that guide lean product development. This article looks at these principles and practices to gauge the extent to which lean is meaningful in the context of Outsourced Product Development (OPD). Outsourcing an extra dimension to product development, and its understanding may make redundant or require alteration to these principles and practices.
A strategic product road map guides the development teams.

A road map helps – “autonomous teams adopt and evolve the vision by validating hypotheses with customers and stakeholders”. Here is the first hurdle, in the outsourcing context the stakeholder access is often restricted to the Product Owner. On occasions, there is access to other stakeholders, such as, architects, designers and so on (if they exist), but the one stakeholder to whom there is no access is the products customer (the end user). This is understandable in the outsourcing context; in the context of product development, customer engagement is more than just about UI. It needs an understanding of the product market, competing products, and most importantly the customers pain points. Accept in rare (very rare indeed) instances the skill set required to deal with such a customer engagement does not exist or is outside the price bracket as an outsourced commodity.
Consequently, the product evolves far more slowly than the product owner would like, because of the time latency introduced by the elongated communication cycle. The more complex the domain or the more bleeding edge the technology, the slower the progress.

Focus on delivering thin slices customer and business value, released early and often.

But for the points raised above regarding “strategic product road map”, this should be a good exercise in agile product development. As mentioned in the book, this slicing is also affected by the context of the product life cycle. The real issue is that both business value and customer value is an unknown to the outsourced team. It can only be transferred over a longer period of engagement. In the short term, the lack of customer (end user) engagement means this slicing has to be performed by the product owner. His involvement cannot be a distant hands-off one; the more complex the domain, the more his involvement has to be scaled up.

Embrace learning over following a static list of features.

If the product life cycle is at the early start up level, then for an outsourced development team the learning will be accordingly steeper. But, the real issue is whether the product owner has discounted this into the product development. And, to what extent this discounting is biased by his own evaluation of the complexity of the product domain/technology. Creating a sustained (or sustainable) learning environment in an outsourced development team requires a great sacrifice of time and effort on the part of the product owner and other stakeholders. If outsourcing is seen only as a cost saving and not a long term engagement of building a self-sustaining remote product team. The exercise will not be fruitful, and what you will have is a mind-set of an hourly contractor delivering feature by feature in as many iteration as is needed to compensate for the lack of learning.

Everyone is responsible for the Customer experience.

After all that has been said above, this is like punishing the undeserving. Since the customer engagement is routed through the product owner and other stakeholders, it is only fair that any shortfall in the customer experience should be apportioned to them and not the outsourced development team. The best of products have a stickiness that makes the customer conclude is the way to work. Good customer experience is to when this stickiness has been achieved. This is a tough task for a remote team without the benefit of direct customer engagement.

Decisions are made “just in time”.

Yes, but not in general by the outsourced development team, except where it impacts the sprint or the delivery.
Teams are accountable for solutions, not just the delivery of features.
You cannot ask for accountability without giving responsibility. Without possessing the authority to make decisions, there is no responsibility. This does not mean that there is no blame attributable to the outsourced team. It just means that the blame is circumscribed by the work they actually perform; in this case it is the coding, delivery, and any associated design decisions.
The decisions made by the team members are influenced by the decisions made by the stakeholders from the customer engagement feedback. Since this data is removed from the teams (both geographically and by time zone), by necessity it will introduce increased work cycles then necessary.

Decisions are backed by data, not the loudest voice in the room (or the highest paid person in the room)

The loudest voice (even at a distance) is that of the product owner and the other stakeholders. Of course, one would want to hope for it to be otherwise, but this is to deny the prime motive in outsourcing, and that is cost. Much of the data (feedback or otherwise) to manage the progress or direction of the product is too remote for the team. The only data the team is intimate with is burn down and velocity, as they are both used as punishment rods.


Firstly, the book “The Lean Product Guide” is highly recommended, as it provides an excellent introduction to lean product development. As far as outsourced lean product development is concerned, it is not possible to do exactly the same and have a successful outcome. The model has to be tweaked, applying the principles verbatim from the book will not lead to the outcome in the same fashion as in non-outsourced development.
Some new solutions have been tried, such as, relocating one of the stakeholders (product manager, product architect) to collocate with the outsourced team. As temporary measure this will yield good results, but as soon as the stakeholder leaves the knowledge vacuum will slowly but surely re-establish itself. Although, some lasting improvement may linger, but this is not a sustainable long term solution.

About KM Mukku

Kick-start, build and manage teams in product development (particularly in the financial domain), and enjoy all in adaptive case management, business process design and business process improvement. Currently holding the position of CTO at coMakeIT.
This entry was posted in product development, product outsourcing. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s