Resources > Articles

Building Teams From Shore to Shore

Post Author
  • Magda Ramos has been in the product management and innovation fields for more than 10 years, working with high-tech startups and Fortune 100 companies such as Emerson, AMD, Motorola and Optio Software. She has a bachelor?s degree in electrical engineering and a master?s in business administration from Georgia State University. She currently leads business intelligence and mobile solutions for the retail industry at Emerson Retail Solutions.

Building Teams From Shore to Shore

Corporations often build offshore development teams as either an extension of their domestic teams or to serve as core groups. This means that product management teams often have to overcome a unique set of problems to communicate requirements across the miles.

Photo By Magnet.me on Unsplash

One of the fundamental tenets of product management is that you should communicate market requirements without being specific about the implementation. But there are significant challenges to this when working with offshore teams:

Lack of business context. Something as fundamental as a work order might not be commonly used in the host country, and often teams have no real, practical grasp of the driving forces behind the users’ goals.

Language barriers. Due to limited face-to-face interactions, written communication is critical, but it is susceptible to misunderstanding resulting in rework and project delays.

Culture. Teams residing in countries with centralized authoritarian systems and/or collectivistic cultures tend to resist development methodologies that don’t rely on discrete instructions and finite deliverables (e.g., Agile) and have a strong preference for rigid requirement documents and deliverables (e.g., Waterfall).

Size. To compensate for potential skill challenges and hedge for personnel turnover, teams are typically larger. Getting all these team members on the same page—especially without face-to-face interaction and while overcoming time zone differences—requires a great amount of effort and coordination.

Avoiding the Prescriptive Requirement Documents Trap

A hybrid framework, combining some of the elements of both Agile and Waterfall methodologies, can be instrumental in achieving success in early-stage offshore teams—before any measure of maturity has been developed (which typically occurs at 3-5 years for highly technical, niche products). This allows the organization to develop core competencies in critical areas early on, while also enabling the team to ramp up productivity in a reasonable time. Later, more traditional Agile methods can be gradually introduced, adopting elements of each method that best fit needs, circumstances and skillsets. (For example, you could develop market requirements documents using Agile methodology elements such as high-level requirements, context scenarios and personas. And you could develop other artifacts such as project plans, system requirement documents and test plans using more Waterfall-like processes and methods.)

Here are some critical factors to successfully integrating offshore teams:

Delegate a liaison. This person—commonly referred to as a business analyst, team liaison or product owner—should serve as the main point of contact between local product management and the remote team. It is unlikely that this would be an independent role, but this individual will be an invaluable resource that can work directly with product management to help develop requirement documents, answer questions from developers and perform quality assurance—escalating only issues and questions that cannot be resolved independently. This resource will develop system-requirement documents in collaboration with product managers or engineering managers, based on the market requirements document developed by product management.

Expand user goals and requirement descriptions. These need to be significantly more elaborate than typical requirements to provide enough context. Succinctness is not always a virtue in this scenario.

Don’t say: “2.2.5.3 Sorting: Unless otherwise stated on the system requirements document, tables should default to sort by newest to oldest data.”

Say: “2.2.5.3 Sorting: Unless otherwise stated on the system requirements document, tables should have the sorting function enabled on each column. The sorting default should be newest to oldest based on the date column.”

To a native English speaker, the first paragraph has the same meaning as the second. The phrase “sorting a table” (while grammatically vague) can only mean that the columns within can be sorted, and the only way that sorting can occur is if that function is enabled. These are the types of stylistic shortcuts we usually take when writing internal documentation. But for a non-native speaker, drawing all these implicit conclusions is very confusing—in part, because the syntax of their native language is very different.

Create personas that represent both external users and internal stakeholders. The advantage of this approach is that it overcomes internal resistance to deliverables. (Why do we need this? We should defer this feature.) Internal deliverables like building a sales demo are typically not directly correlated to personas. Under this framework, however, describing an internal stakeholder that won’t use the end product but has a stake in a specific project or product goal is extremely beneficial. Not only does it indirectly provide additional context to a requirement, but it also explains the business and cultural environment for the developers and the whole offshore team.

Let’s consider this example for the fictional Stark Corporation:

Context Scenario for John, Sales Representative persona. Several times a year, John presents the ProActivities portal demo to potential customers. He has noticed that it contains outdated dashboard samples. His other option would be to show another customer’s data directly from the production portal, which would not be acceptable because the data is confidential. The demo site cannot be accessed half of the time, because the client cannot provide him with a network connection, the demo site is down or something else in his laptop operating system has changed causing problems with the browser. He just wishes he could demo the portal offline, so that he would know what to expect and avoid any unwarranted negative perception of Acme’s solutions.

Requirement. Develop a subset of the online dashboard using a technology that conveys the look and feel of a multimedia, rich Internet application.

Group. Develop exciting online/offline dashboards and offline demos using BIP/Flash.

Although various external end-user personas and context scenarios existed (not shown in the illustration) to support the requirement, this scenario supports the notion that a set of features that allows offline dashboard interaction is needed and reinforces that a mature look and feel is critical, since it affects the sales cycle. (Note: It could be argued that in an Agile paradigm, even the mention of “Flash” falls into prescriptive territory. But as we are explaining in this article, depending on the offshore team maturity, some exceptions to this stance are pertinent and beneficial.)

Using various channels of communication is more critical when verbal communication is infrequent and work is done in different time zones. The expanded use of personas and user stories and the designation of an offshore resource as a main liaison will go a long way to building a process with built-in redundancy to traditional communication methods such as prescheduled conference calls and on-site visits. These will serve as safeguards that make it less likely that minor miscommunications derail your project.

Author

  • Magda Ramos has been in the product management and innovation fields for more than 10 years, working with high-tech startups and Fortune 100 companies such as Emerson, AMD, Motorola and Optio Software. She has a bachelor?s degree in electrical engineering and a master?s in business administration from Georgia State University. She currently leads business intelligence and mobile solutions for the retail industry at Emerson Retail Solutions.

Author:

Other Resources in this Series

Most Recent

Article

[Comprehensive Guide] Product Owner vs Product Manager

Learn how to separate the roles of product owner and product manager on Agile teams and uncover some common challenges with confusing these roles. Including a short primer on the Agile revolution.
Article

Use Scenarios are Stories That Provide Context

The problem with today’s user stories is that they aren’t interesting. And they aren’t stories. The solution is use scenarios. It’s a narrative. It explains the problem in the form of a real-life story.
Article

Benefits of Bundle Pricing

Bundle pricing is simply a strategy where services or products are packaged together for one (often reduced) price rather than priced separately. This article covers some benefits of bundle pricing followed by a system for getting started.
Article

A Quick Guide to Value-Based Pricing

Value-based pricing begins with knowing the customer’s willingness to pay based on the perceived value of your product. You can charge less than a customer’s willingness to pay, and they feel like they’ve received an
Article

What Is Captive Product Pricing 

If you’re looking for a simple answer, it’s this: captive product pricing is when consumers make a one-time purchase (usually a lower-priced core product) but are required to purchase accessories for the main product to

OTHER ArticleS

Article

[Comprehensive Guide] Product Owner vs Product Manager

Learn how to separate the roles of product owner and product manager on Agile teams and uncover some common challenges with confusing these roles. Including a short primer on the Agile revolution.
Article

Use Scenarios are Stories That Provide Context

The problem with today’s user stories is that they aren’t interesting. And they aren’t stories. The solution is use scenarios. It’s a narrative. It explains the problem in the form of a real-life story.

Sign up to stay up to date on the latest industry best practices.

Sign up to received invites to upcoming webinars, updates on our recent podcast episodes and the latest on industry best practices.

Subscribe

Subscribe

Training on Your Schedule

Fill out the form today and our sales team will help you schedule your private Pragmatic training today.

First Name*
Last Name*
Email Address*
Phone
Company
Job Title
Location
How can we help you?
Preferred method of contact
Privacy Policy*
Map Your Message to Its Audience with the Communication Compass
Map Your Message to Its Audience with the Communication Compass
Ensure your message hits the mark. This eBook helps you visually map communication styles so you can tailor your design story to a stakeholder or business partner.

Download Ebook

Demystifying Data Projects: A Guide for Business Leaders
While data science is a competitive advantage, data isn’t magic. Learn how to make magic happen by partnering more effectively with data professionals. This eBook delves into types of data projects, sample questions, tools and methods, key points and cautions—so stakeholders like you can initiate data projects with real business impact.

Download Ebook

Define Ebook Thumbnail
What’s the difference between a successful data analysis project and one that falls flat? 

Before you begin working with the data, you need to understand what you’re solving for. Gathering context and aligning around goals with your stakeholders from the outset will help you avoid disconnects and deliver actionable insights. Discover the most vital questions to ask before embarking on a data analysis project in our in-depth guide, “Define: Laying the Foundation for Successful Data Analysis.”

Download Ebook

Download Now