When to Outsource Software Product Engineering?

Taking it from my last post that talk about ‘why to outsource product engineering’ it only makes sense that we now discuss ‘when to outsource product engineering’. A lot depends on different elements though. To begin with one has to think through following elements while engaging with a vendor / partner (more of an internal check list):

• How ready am I (as a decision maker)?
• How mature is my organization (including others who would be interfacing)?
• What's the size of risk taken, what's Plan B (mitigation included)?
• Shall I share my core IP to ensure non-core part of the product is well integrated?
• Which phase of PDLC shall I engage to get maximum benefit?

As a product manager one has to plan forward and identify gaps which need to be plugged across the lifecycle. Have seen engagements where complete product ownership is with a vendor; having said that, majority engagements are part product development. Recall a scenario of an ISV where development team was with vendor A, and testing and release management was with vendor B. This arrangement created chaos during initial builds and there was a healthy competition. Over a period of time the vendor driving triage was calling shots. However, ISV was spending lot of time managing both vendors. Product companies bring in OPD vendor / partner across different phases listed below:

• Market requirement document (MRD)
• Product requirement document (PRD)
• Proof of concept (PoC) development
• Alpha release, private release to selected initial customers
• Beta release, release candidate (RC), Gold release
• Integration across more tools / platforms
• Scale the product to address more customers during growth phase
• Porting across multiple platforms to increase customer base
• Supporting end-customers, integrating with custom tools for high profile customers
• ....and the list goes on till End of Life / sunset of the product

Mature individuals (those who have benefited by outsourcing over multiple projects) tend to take calculated risks based on their experience. Recently, while meeting a long time customer (engaging a team of product developers for more than 5 years to build and release different versions of NAS product), I asked if he is open to share his best practices (of working with offshore vendor) with other product managers in his own company. He said, "I have been doing that for a while and would be more than happy to share it with your customers".

One important point that apparently seemed important during our conversation was - Culture. Product Company’s culture is typically adopted by vendor's engineering team engaged for a product. That said, if the vendor's team for the product is bigger (or going to be bigger over a period of time) than that of an ISV - culture of vendor prevails (most of the time). For a person who is outsourcing for the first time, this might be hard to digest.

I have seen ISVs engaging services of a vendor across different phases, solving variety of problems. Nonetheless, first time is always a challenge. One is trying to understand the other (post basic diligence), as most people do during dating. Quicker they pass through dating phase, better it is for both (this is keeping in mind - both are equally committing time and effort to make it happen).