In the chapter on Result Delivery, I illustrated the difference in focus between outsourced teams and internal teams. Outsourced teams will always be interested in selling more hours. That’s the outcome these companies seek, allocating more hours to their clients, including you and your company, which is a different outcome than what you are looking for.
You and your company are not seeking to hire more hours of software development. You aim to achieve your strategic objectives while solving problems and meeting the needs of your customers. This misalignment of objectives is what leads me to advise against using outsourced teams. You can use them, provided that you have a clear understanding of this difference in objectives and know how to manage the effects it may cause.
The monthly accountability report, which comes with the invoice we must pay, includes a breakdown of the number of hours worked by each allocated professional and a list of delivered features. While I have seen some demonstrations of delivering results for the company or the client in reports from software development outsourcing companies, this is quite rare.
Once, I had the opportunity to help a client make the decision to switch from an outsourced team to an internal team. Since the average monthly cost per person for the product development team tends to be similar, the switch would be justified simply by having the people on the internal team highly aligned with business objectives. In this client, one of the business metrics we tracked was the number of sales generated by this product development team.
It is interesting to note that while the team was partially outsourced, the number of new sales did not increase, even though it was clear that this was one of the team’s main objectives. Only after a few months with the team being predominantly composed of internal staff did the metric of new sales begin to grow.
When I was at Lopes, I chose to bring in an outsourced team from a consulting company with extensive knowledge of software development, ThoughtWorks, to help me implement the principles I discussed in Part 2 of the book (Principles). It was a short-term project, lasting 7 to 9 months, with the objective and timeframe clearly defined from the beginning.
This article is another excerpt from my newest book “Digital transformation and product culture: How to put technology at the center of your company’s strategy“, which I will also make available here on the blog. So far, I have already published here:
I’ve been helping companies and their leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) bridge the gap between business and technology through workshops, coaching, and advisory services on product management and digital transformation.
At Gyaco, we believe in the power of conversations to spark reflection and learning. That’s why we have three podcasts that explore the world of product management from different angles:
Do you work with digital products? Do you want to know more about managing a digital product to increase its chances of success, solve its user’s problems, and achieve the company objectives? Check out my Digital Product Management books, where I share what I learned during my 30+ years of experience in creating and managing digital products:
