Having managed offshore development, worked for managers more than four time zones away, and delivered products to customers on every continent (except Antarctica), I've found there are three key elements to be successful in the new global world of product management.

 It's all about context

Context is defined by The American Heritage Dictionary of the English Language as:

1. The part of a text or statement that surrounds a particular word or passage and determines its meaning.
2. The circumstances in which an event occurs; a setting.

For product managers, context is the backdrop of any and every requirement you communicate to the development team. It's not the business case, it's not the use case, but it can be part of both. The context represents the facts of why a market needs something new whether it be a new feature, new module, or new solution.

Context includes profiles of the target users including their experiences, areas of expertise, preferences, and primary goals. Context includes profiles of target market systems including technology capabilities, IT staffing and skills, and appropriateness of certain types of technology. In short, user personas, buyer personas, and use scenarios.

It may seem obvious that you need to provide the engineering team with as much contextual information as possible. After all, context allows developers to make the best decisions when building a solution.

But typically in the rush to get the development team moving along, the contextual information is not always complete and is doled out in increments rather than all together. And sometimes the contextual information makes assumptions of the engineers in terms of market, cultural, or user knowledge.

When working with offshore development, when, how, and to what extent you deliver that context can be as critical as the information itself. It becomes critical to deliver that information as early as possible. And completeness is required if you need the team to work autonomously. Lastly, even the smallest and seemingly low-value information could mean the difference between a successful project and one that misses the mark.

Without complete, detailed, and timely context, the development team is not able to create the most appropriate solution and the risk of missing expectations grows enormously.  Because this extra information can allow a team to make the best decisions without having to rely on constant input from stakeholders, you can avoid those costly misses.

Here are some things to consider that should help you meet this challenge:

1. Try to think of all the questions a person who has no knowledge of the market might ask and then provide those answers. Think of the cultural differences of the personas that could impact decisions when designing a solution.
2. Deliver the “package” of information in a very collaborative session that allows for presentation and Q&A. The more you can discuss the information and allow the team to interact with you, the better the knowledge transfer.
3. Keep the information as simple as possible. Plain, direct, and brief sentences work best. You can still provide loads of relevant information, but keep it easy to consume and structured. Also avoid colloquialisms or any cultural references that cannot be clearly explained.  Remember, those that will use this information are not always fluent in English.

In summary: Always explain the context around every requirement providing information that will allow engineers to make decisions without your constant involvement. Keep the information simply worded, and as brief as possible.

Know what type of communication is best

Today, there are many ways to keep connected with a development team. Instant messaging, email, wikis, and video conferencing are all relatively inexpensive and readily available. The key is knowing when and how to use each communication channel in order to avoid problems during a project.

First things first: email. Don’t use it for handling discussions or any time where multiple responses are required. While most folks tend to lean on email as a preferred communication vehicle, for offshore development, it is actually the worst tool in terms of actual communication.

In most cases, email use in offshore communication is best used as a communication support tool to disseminate information or share basic ideas that will be further addressed in a real meeting. Look back over your own emails and there is a strong likelihood that most of your product-related emails also have live meetings or calls associated with them.

Unfortunately for most companies that use offshore development, there is a tendency to use email as the primary vehicle of communication since it doesn’t require coordination across time zones for a live call, video conference or collaboration session. It’s asynchronous. You can send a communication to someone far away even when they are away from the office (most likely asleep).

For offshore communications, email should be limited both in quantity and amount of information. Things like daily status updates, alerts for changes in documentation, or general project communication are fine.

But everything else should find a different medium. Here’s my basic guideline for using various forms of communication based on the type of need.

Brainstorming

Wikis, online collaboration tools, and video conferencing work best for idea generation conversations. Wikis are great for sharing and discussion of requirements and other evolving information. They also work well for task coordination and asynchronous communication involving communication threads. While video conferencing capabilities have become fairly ubiquitous with solutions like Skype and instant messenger tools, few companies have implemented video conferencing for much other than formal infrequent meetings. These tools have become pretty capable and are very valuable when something needs to be collectively reviewed live. Video conferencing, along with online collaboration is the ideal medium for working through requirements problems, or sharing concepts and ideas.

Requirements and other Project Documents

The most common issue, even within companies that are located in close proximity is the most important information can get lost within email threads and other forms of transient communication. So it is key that the group finds a centralized location to store all project documents.  Additionally, this type of information requires strong versioning control to manage updates as they become available. Document management portals like SharePoint work best for this type of information.

Status Updates and Alerts

As stated before, email is great for infrequent and brief information dissemination. Try to limit emails as much as possible to once-per-day. And keep the information as brief as possible with links to more controlled artifacts like documents, wikis, or other forums where iterative updates are better-controlled. 

Short Problem-Oriented Sessions or Questions

Instant messaging and phone calls work great for shorter communication needs that need prompt responses and interactivity but where the discussion is limited to one or perhaps two topics.

Both are very valuable communication mediums. Depending on the amount of overlapping hours between the offices, it might be easy or hard to coordinate calls or chats. Again, chats work well because of the idea of presence; knowing if someone I need is online and vice versa. In this manner, we can communicate even in situations where a phone call is not the best option.

The key is to understand the benefits and drawbacks of each communication medium and select the most appropriate one.

Create a local proxy and provide clear expectations

When the team actually creating the product is half a world away, it becomes critical that the team is able to operate without you being involved. Doing this allows the team a good amount of autonomy without increasing the risk that deliverables will not meet expectations.

The keys here are to identify someone in the remote office that can act on your behalf during their business day. But, ensure this proxy is armed with key information regarding requirements, expectations, and stakeholders. What you want to avoid at all costs is a team that either stops working or continues to move forward in a different direction than what is intended. You can do this by ensuring that someone with them can provide the guidance needed, find the answers, or seek input from the appropriate stakeholders and in the most efficient manner.

Your proxy might be the lead developer, the project manager, or a lead architect. Regardless, this person should be well-established in the team, be in a position that allows them to be involved with the overall project, and be willing to act on your behalf. The result is that you’ll sleep better knowing that the development team will find the right answers without having to guess or wait for your return the following morning.

Being the product manager when the engineering team is thousands of miles away is a challenging task. You lose the ability for ad hoc interactions and reviews which become the norm with local development. You also have a more difficult time ensuring that the team always has the right amount of information at the right times to be successful. And you lose the confidence that comes with being directly involved with the project.

All it takes is a little more planning and thought regarding the aspects that we often take for granted. By providing the right amount of information, selecting the appropriate communication vehicle, and having people represent your customer’s needs, you can make offshore developed solutions be just as successful as the ones created down the hall. 

Greg Council’s personal agenda has always been to be a great product manager. In the last 14 years, Greg’s honed his expertise within the product management domain to identify unmet (and often unarticulated) needs in order to deliver truly valuable, unique, and useful solutions. He’s managed both large and small direct and virtual teams to improve existing products and bring new offerings to market. Contact Greg at greg@councilnet.com.