Onshore Product Leadership – Offshore Product Development… What can this mean for our project model?

This posting is in response to a discussion started on LinkedIn. In that posting the question posed is how product manager's can effectively deal with onshore/offshore project dynamics through improved communications and methodologies. While I would certainly advocate the use of various product management methodologies for the product strategy and design stages, it is my belief that a product manager's responsibility extends well beyond just that phase. This posting discusses the types of situations that have arisen on various offshore projects that I have worked.

Let me start by providing some background... I have been in product management roles with divided development teams (some onshore and some offshore), completely offshore development projects where the employees were part of the same organization and completely offshore development projects that were performed by an outsourced development partner. In each of these situations the perspective of the offshore team was the critical data point that guided my actions. Let me explain a few of the dynamics and then I'll provide you with some approaches that worked for me in each of these situations…

1. The offshore team, based in London, was responsible for building a web-component SDK upon which the onshore team was going to implement a client experience. The onshore team was convinced that they could build a better SDK than the offshore team and was adamant about working on their project in this fashion. The offshore team was convinced that they could build a better client than the onshore team and they too were adamant about working in this fashion. Clearly we would be headed for disaster (time to market, feature set, …) if we could not reconcile roles and responsibilities across the teams.
   
2. The offshore team in another company was based in Austria. It was an amazingly talented engineering team. They could build product faster and with higher quality than any team I had ever worked with. The challenge lay in building the right product and getting the right go to market. When this team saw lackluster sales results from the product there was a pullback in energy and dedication.
   
3. This scenario was with an offshore development partner that was specifically chosen based on their expertise in building similar product integrations in the past. The challenge here was that their social/cultural norm (not giving away the name or location) was to be productive but ask few questions. Our challenge was that what we needed built was not very similar to their previous work in the same space. The challenge in this situation was clear communication of goals and expected outcomes.
   

So, what worked? In each case it took a different strategy and in none of these situations did the approach look the same. Each project was successful in unleashing the potential of the development team and ensuring that the product strategy (feature set, market timing, go to market preparation) was realized. Here's the work that helped resolve these situations:

1. We identified a team leader from each engineering team, as opposed to having a single team leader in one location (onshore). This alleviated the lack of recognition by each team to doing the wrong thing. As product manager, I was diligent in advocating that all product planning, project reviews and decision making was done with both team leads present – in person – at all times. In addition, I spent a lot of time in each location (one week a month) to help support each team leader with their work that leverages the use cases, requirements and design of the overall solution.
   
   
   Keys: get the right team configuration, be present and supportive, don't wait or waffle when you see something going awry like this… it's your product, you are responsible for its success (or failure)!
   
   
   
2. As product manager I spent a tremendous amount of time in the field training the systems engineering team – it was a technically-oriented product for developers that required a lot of on the job specialized learning for the SEs. Getting the systems engineering team ramped up on the product and having that translate into product wins and revenue gains created tremendous momentum with the team. To capitalize on that momentum I would gather the entire engineering team (Dev & QA) for a weekly conference call. With this insight they themselves developed some tremendously innovative product features that allowed us to surpass our competition in the market.
   
   
   Keys: it's not always the requirements or use cases, in this case it was a motivational challenge; seek opportunities to disseminate as much customer and product usage information as possible to engineering – it's amazing what they can do with it.
   
   
   
3. In this situation, the hands-on product manager reported to me and so my role was as coach, not player. We discussed the observations of the work style of our partner after they came and presented their prototype progress to us after a month of work. It was off, way off. The approach that I guided my product manager to was to work with the engineering director to understand why they were so far off in their first take. It turned out that the cultural issues were to blame – the offshore team had the best intentions but culturally they were taught not to ask too many questions when they didn't know something and instead just to make progress. The resulting configuration is that we had them put a development lead onsite in our offices for the entire project. The development lead was a senior member of their team and we mandated that daily meetings would be held with their engineering team to resolve and answer any questions that would ensure that the resulting product was what we wanted. This approach added to the cost of the offshore development contract (roughly 5%) but the result was a product that was what we wanted and would be well received in the market.
   
   
   Keys: Again, this wasn't an issue of missing or ambiguous requirements it was an issue of socializing the requirements across the team and executing upon them under an established cultural norm for the project. Therefore we changed the project management model so that the outsourcer adopted the cultural behaviors of our organization - open discussion and collaboration around various design aspects and requirements. We were fortunate that we had the contract leverage to mandate this approach, so it certainly could not be accomplished the way with an offshore team that is within the same organization. If this had been within the same organization our approach would have likely been to put more product management and engineering staff onsite in their location more regularly.
   
   
   

The net-net of this is to use a system or product management methodology for what it can help you structure and execute, but don't try to substitute it for the use of good old fashioned common sense to see what is missing from any project dynamic. And *never* wait for someone else in the project/product team to resolve issues – you are the product manager – make it happen.