How to Manage a Product with a Global Team

By Anders Linsdorf

globalBuilding a product by oneself is difficult. Building it with a team can be harder. But building it with a distributed team is even harder.

Today it is rare for companies to build products with a 100% local, in-sourced  and on-site team. This is why one key requirement to build a successful product is to be able to manage a globally distributed team.

That is not easy and there are some crucial differences between being a small start up and an established enterprise.

Here is what I learned from teaching this at the University and doing it in practice.

Specific challenges – Startups vs Established Companies

A start up typically differs from a more  established company in the way globally distributed work is carried out.

A start up will typically have:

More freelancers compared to full time resources.

An established firm will typically have an offshore team with a local project manager either through an agency or possibly an independent legal entity. Startups don’t typically have those types of resources, so they rely on freelancers.

The primary challenge of a start up is to locate the right freelance resources. Luckily, services like oDesk, Elance and Fiverr make it easy to find skilled people in off shore destinations.

But a skilled person is not always a good fit. If you need someone to code to do research or to write, you may want to check how they work first. It is common practice to post a tender for a small test task you need to get done.

Just design a task that is similar to what you actually  need and invite three people to do it. It is important to remember that this is a test, so you need to guide and inform them all in exactly the same way.

It is also important to decide in advance whether you are looking for commodity or premium services. Even out there in off shore countries there is a relation between price and quality. Invite people according to this.

More specific individual tasks compared to a continuous flow of tasks.

Larger companies have a continuous flow of tasks. They work on projects, but when one project finishes,  resources are transferred to another. In a start up you will usually be restricted in funds and have much more defined tasks to be completed by offshore resources, such as:

  • tasksdesigning a landing page
  • implementing an algorithm in PhP
  • defining a colour scheme
  • setting up a server etc.

This shifts the management focus to being very clear and precise about what you want. If it is a specialized task, you typically don’t have the luxury of working with a resource who has any knowledge of what you do,

This means you have to do a lot of prep work. This is by the way where most people fail and get a bad experience with off shore resources, but although the skill level may differ between the US and India it does not differ as much as you would think. The reason why you tend to hear about bad quality from India or other off shore destinations has more to do with them not being instructed in enough detail what to do.

General challenges

There are also some general management challenges when you work globally that are the same whether it is a team, a freelancer or an entire division they are:

Timezone differences

Timezones are usually a problem, but they can actually be an advantage. The best companies manage to build organisations that work 24 hours a day. This means they have 24 hour support and develop new functionality more quickly if done right.

You need to set up a rhythm for your company where you define the hand offs between timezones. For example one can have a morning meeting in New York with the off shore development team team in Ukraine (where it is the afternoon) anbd discuss progress and new tasks; and then have an afternoon session with the Singapore team who have just started working.

Cultural differences

culturesLet’s talk about the elephant in the room. Different countries have different patterns of behaviour, but they all expect everyone to behave like themselves and interpret behaviour in that light. From a management perspective the first step is to become aware that you may not make sense to your off shore team because of how you frame it.

It may not be possible to understand each culture in detail, so a little sensitivity will take you a long way and do try to read something about that culture. On the other hand, for core tasks I would strongly suggest to pick just one destination, that you are either familiar with, or are ready to become familiar with.

For my own company, I chose Moldova for the core development tasks. I know the country from travels, speak some Russian and it is a similar size to my native country, Denmark. These things resulted in a close cultural match where we have a really good connection. For Western countries, I usually recommend Eastern European countries although they are usually a bit more expensive, but you earn it back really fast by not having to do everything three times because of misunderstandings. They are generally very familiar with Western culture as well.

The human factor

Just because they are offshore, it doesn’t mean you can treat them differently than onshore staff. Try to visit them every or invite them to visit you. Neither Skype nor Webex nor Google Hangout will ever replace face-to-face interaction.

This is important in any type of collaborative endeavour, and especially in software development. I went to stay with my offshore team for a week on several occasions. I think they thought it was weird that I was there in the office, but we now have a really good relationship because of it.

Development phases

It is important to think about what development tasks are carried out close to the home market and which can be carried out elsewhere.

A rule of thumb, supported by empirical studies, is that the earlier design phases are best and most often performed inhouse or close to the target market. The middle phases where solutions are developed according to specification are more commonly performed by off shore resources, but the later phases such as integration and deployment are again best performed inhouse.

In research, you talk about tightly and loosely coupled tasks. Design is tightly coupled because every change can effect everything else. Coding a module designed properly with an interface definition is loosely coupled since changes to the module do not affect the workings of the whole system.

Integration is again tightly coupled because one small change can make everything fail. Tightly coupled tasks need more and quicker iterations which is intractable at large distances. For my own company, I do all web and front end design with local resources although it is much more expensive.


tools2Having a particular tool is not important, but having the same tool amongst people who work together is very important. One common source of problems is the “two versions of the truth” problem.

If everybody is not on the same page, the product will not work and you will spend endless time clearing up those problems. So by all means have only one system of record for one type of information.

Even if you have the greatest tool in the world, an inferior tool that does the job is better. If the people you work use Trello and you are a die hard Basecamp fan, ditch Basecamp and learn Trello.

For example I went with my offshore developers’ choice of Redmine, although I preferred to work with Jira.


People are used to working differently and you need a pragmatic approach to how you are going to work that will work for everyone. How do you plan a release or sprint? How will you test? How will you do status reports etc.

Again it pays off to go with how your offshore resources are used to working rather than forcing the latest scaled agile framework down on their heads.

There are likely other factors to consider,  but this article covers some of the more important items you should keep in mind. It is difficult to work with a global team, but not impossible. It can actually be very rewarding. Just don’t expect it to be like working with a local team.


Tweet this: How to manage a product with a global team #prodmgmt 

A version of this article originally appeared on the Sensor Six Blog:

About the Author

 anderslisdorf-bwAnders works to to turn new innovative ideas into the reality of tomorrow. His company, Sensor Six, makes software to help companies develop new products.

You Can’t Talk to Customers. Really?

By Heather Searl

Often when I suggest to a client that they talk to and observe customers, the suggestion is immediately met with a series of reasons why that is impossible. And yet if they are willing to try, we’ve always been able to work around the impossible road block.

So here are some of the most common customer insight roadblocks I’ve heard and how to get around them.

The Sales Team Won’t Let Us Talk To Customers

Dead endIn many B2B organizations the sales team “owns” the customer and doesn’t want the rest of the organization “bothering” customers.  My contacts at these companies have previously approached the sales management team to ask to talk to customers and were turned down.

I’ve found that a better approach is to ask a few specific sales people,  explaining what you want to do AND invite the sales person along.

Most sales people are looking for a reason to visit their customers, and are happy to help you set up insight sessions as long as they are included.

Some of my clients have worried that if they included the sales person the insight session would become a sales call. But as long as we explained who we wanted to talk to and about what that has never happened.

Good sales people understand the value of knowing what is important to their customers so they are happy to make the introductions and then sit back and listen. They usually attend any sessions where we talk to decision makers and when we move on to talk to end users they disappears to talk to the decision makers about other sales opportunities.

There are a few keys to making this direct approach work:

  • Approach sales people individually and pick people you think will be open to the idea.
    • It`s always easier to explain and answer questions one on one (and harder for them to say no).
  • Ask to speak to customers they think will be open to giving feedback.
    • They often have a few customers that they know would be interested in helping develop the next generation product.
  • Be clear about the types of people and roles you want to speak to so that the right interviews are scheduled.
    • A sales reps view of the ideal customer is not the same yours.
  • Keep the sales person in the loop.
    • Sales people don’t want to upset customers by wasting their time, and need to be able to answer the customer`s questions about the interviews.
  • Be open to talking to unhappy customers
    • Build time into your interviews to hear complaints – whether the complaints relate to the current project or not.
  • Follow up on customer concerns.
    •  Do whatever you can to help and you`ll often end up with a contact you can call again when you have new questions.

There Aren’t Any Local Customers and We Don’t Have a Travel Budget

no-moneyWeb Conferencing to the Rescue

When you interview customers via web conference you may not be able to do everything you can in person, but you can accomplish a lot.

Early in my career I was told you had to do usability tests and contextual inquiries (where you watch people perform various tasks) in person so you could see their body language to understand what they are thinking but not saying. On one of my first research projects we didn’t have the budget so we tried a web conference where we gave people access to our prototype software and asked them to try a variety of tasks.  I can’t say how much more we would have gotten out of the experience if we had been in the same room, but we learned a lot and could tell when someone was hesitating or unsure of what they were saying.

Tech Support has a Wealth of Knowledge

Tech support is your friend.  If you want to see how people interact with your product, understand their vocabulary and mental model of how it should work – spend some time listening to tech support calls and talking to support personnel.

At one company I worked for we tried to spend half a day every month sitting with someone in tech support listening in on their calls.  We also talked to groups of support people about different issues and what worked and what didn’t work when they were talking people through various issues.

The one problem with sitting with someone for half a day is that you can’t control what calls you get to hear. You learn a lot but you can’t focus that on your current issues.

To get more focus, see if you can befriend someone who does the quality control checks on calls. The company I mentioned above had someone who listened to a cross section of recorded calls every month. We asked for her help and she happily flagged calls on specific issues and burned a CD of calls every few weeks. The user experience and product management team would pass the CD around and listen to the calls as we drove home from work.

We’d Need to Talk to Hundreds of People because All of Our Customers are Different

crowdI have never found that the belief that there are dozens and dozens of different types of users for a product to be true, however there are people that I have never been able to convince of this.

To get around this argument you need to to change the conversation and focus on talking to a couple key types of customers, then following that up with a group discussion to figure out which types of customers are the “right” types to focus on.

The team creates a lengthy list of user types and then shortens it to the key types. And the list is usually still too long.

The next step is to define the key habits and workflows for the short list. You need to be careful not to focus on what is different about the groups — there are lots of differences — just focus on workflow and habits.  A few distinct patterns will emerge.

Sometimes you can regroup the types of users based on these patterns, and sometimes there will be resistance because the user types are still different. It doesn’t matter, because now you can guide the conversation toward a couple types of users to talk to and make sure they cover the different patterns the team defined.

 Tweet this: You can’t talk to customers. Really? #prodmgmt #ux

heathersearl-newHeather is a user experience consultant and freelance writer who believes in doing everything from a user-centric point of view. She has 20+ years of experience in high tech and is well-versed in helping product management and development teams get to know their customers, understand usability issues and turn these insights into design innovations.

Heather can be reached at or on Twitter as HeatherSearl.

How to Keep Your Product Strategy From Turning Into a Game of Jeopardy

By John Mansour

jeopardyFor those not familiar with it, Jeopardy is a very popular and long running game show where contestants answer questions based on categories and can win or lose money based on a dollar amount tied to the question.

For product planning, the Jeopardy analogy comes compliments of one of our clients describing his organization’s annual product strategy routine. The analogy as he described it was pretty funny, but the experience and the results, not so much.

The Jeopardy version of product strategy is a game you may have played but didn’t realize it.

You and your fellow product managers each come to the table with a proposal of your highest priority product investments accompanied by revenue and cost projections – the answers.

Your key stakeholders come to the party with the questions – the topics are market landscape, risk, competition, ability to execute, etc.

It’s time to play Jeopardy!

“I’ll start with product 3 for $600, Alex” says on Product Manager, while another prefers to start with “product 1 for $400.” After a few rounds, a lot of discussion and final Jeopardy, priorities get decided and set the resource wheels in motion. Fast forward 3, 6 or 12 months and the results are fairly predictable.

The sales team that signed up for the revenue numbers has been reshuffled, or key members have moved on. There’s been another reorg or acquisition and priorities have shifted. Ideas for shinier new objects have leap-frogged projects that were once the highest priority.

The bottom line– products aren’t delivered as planned and revenue goals aren’t met. Are we having fun yet?

Fixing the problem

In B2B, there are two things your product management team can do to drive the product strategy routine in a more meaningful and predictable manner and avoid the game of Jeopardy and all the ills that go with it.

1. Function as a unified team

Don’t act like a group of individuals each running the business of his or her products.

You’ll see your target customers the same way they see themselves and understand the biggest obstacles they face. Determining the solutions that have the most value relative to those obstacles becomes blatantly obvious.

2. Treat your products as the means to the end

Components of the solutions that have far more value together than any individual product. In other words, end the strategic planning pitch with products instead of leading with them.

In the case of our client mentioned above, they looked at the commonalities of their target-customer organizations across five vertical market segments. All of them are in hyper-competitive businesses with short product cycles, rapid commoditization of services and revenue models that are changing as fast as I’m writing this article.

As a team, they asked themselves, “What are the biggest contributions we can make to those organizations to help them survive and thrive in their hyper-competitive markets?”


After a lot of thoughtful discussion, two themes surfaced.

  • Help them get new offerings to market faster
  • Keep their customers from defecting to the competition with a superior level of service until new products/services are available.

The solutions that support each of those target-customer goals all involve more than one product. Interestingly enough, none of them required any major new products.

The revenue projections put forth by the product management team weren’t product specific. They projected the uptick in revenue in each vertical market segment as a result of delivering the proposed solutions. The projections are attractive, even from a conservative point of view.

Still some work to be done

The jury is still out on the results and will be until the solutions are in the market, but senior executives across the board have welcomed the new approach, especially the SVP of sales. Why?

It demonstrates the market value of focusing on the target-customer’s goals first and determining how your organization can contribute in a way that supports your own growth and profitability goals. Products are merely the vehicles to get you there.

The best part is the senior executive team has a clear understanding of the market value of these solutions and unless the market suddenly changes, the product investment priorities are highly unlikely to change.


Tweet this: How to keep your Product Strategy from turning into a game of Jeopardy #prodmgmt #strategy

About the author

John Mansour is a 20-year veteran in high technology product management, marketing and sales, and the Founder of Proficientz, a services company focusing on product portfolio management.

Top-down prioritizing: markets and portfolios

Failing to focus, failing to choose one discipline and stick to it, is exactly what leads firms to a state of mediocrity.—Michael Treacy & Fred Wiersema, authors, Discipline of Market Leaders

In most organizations, development teams have dramatically less capacity than the appetites of the business units and sales teams. That’s why I continue to hear things like “how can we get the developers to work harder?” or “why aren’t they giving me what I need?”

The big thing is this: you only get the development your organization has chosen to afford. [tweet this]

Many cannot understand why this feature or that one can’t simply be added to the list. Here’s why: adding a feature means moving or deleting another feature; satisfying one customer (and their sales person) usually means disappointing another customer (and their sales person).

Product marketing or market owners should focus on a market full of customers, and generate a prioritized list of what is needed by their markets; portfolio owners should direct those market stories to the appropriate product. And company leadership prioritizes these with the budget.

To do this successfully, your leadership needs to do two things: allocate investment by market and then by portfolio.

Allocate investment by market

Allocation of development spend reveals your market strategy and provides guidance throughout the organization. In practice, this means approving or revising the recommendations made by the product marketing and product management teams. It means signing off on a portfolio strategy for products and sticking with the strategy in each part of the business.


Allocation of development spend by market sends a clear signal of the company’s priorities. For instance, perhaps education is your top priority, then health, then Europe. Allocation by market ensures that each market gets funded in sync with the overall business strategy. If your #3 market priority is Europe, this market will still get funding for their requirements (although perhaps not as much as they want) instead of just hoping to get some of the other markets’ funding.

Allocate investment by portfolio

Perhaps some of an organization’s frustration occurs when executives cannot see or do not understand how product trade-offs are made today. In a company with multiple products in varying stages of their lifecycle, leadership must decide where to put their investment dollars. This top-down approach reveals the relative importance of each product in the portfolio. Once the decision is made for levels of funding, the product management team can show what features can be delivered for the allocated budget.

If you allocate dollars for development in one product, product management can tell you what you will (and will not) get for that money.

Product management can help focus the allocation by clearly articulating the portfolio positioning. One product is for this market; another is for that market. The portfolio positioning must be enforced companywide; we cannot allow sales people to sell products outside their intended markets—and if they do anyway, it means rejecting those contracts.

The Three Horizons model (advocated by Clayton Christensen, Geoff Moore, and others) reminds us to redirect profits from old products to fund development of new products. It means the older products don’t get all the development spend they may want because their profits are paying for innovation in future products. I know that many product teams are frustrated when they don’t get the funding they want but we’re trying to run a company, not just a product.

Remember, if we only focus on this year’s revenues, we’ll have last year’s best product. [tweet this]

I recommend an allocation that includes, for each product release, something that will appeal to new buyers, something for existing customers, something that furthers your vision, and something that upgrades your infrastructure. (See more on this at Politics and your next release)

And don’t forget services! We need to extend the view of “product” to include services and support in addition to software and hardware. After all, your customers buy a solution that is often much more than the product. In future, services should be defined (by product management) and promoted (by product marketing) as clearly as your products.

Take the example of the Nest Thermostat. It comes with all the tools and instructions necessary to install it but they can arrange for your installation if you aren’t comfortable installing it yourself. Nest also sends an email periodically reporting your power consumption (and reminding you how much you’re benefiting from their product).

Within the portfolio, given a total dollar amount of funding, you then allocate the development funding to the products.


Look to your current spending on the product. How much is spent on maintaining code and fixing defects versus adding new functionality today? Let’s assume you’ll spend the same next year. And let’s also add some amount, like 10-15%, for innovation or other internal improvements.

The challenge you’re likely to face is the market owners and sales people and others may want to allocate all the funding to new functionality but we also have to account for maintenance, defects, and innovation. If you want to change these allocations, you’ll need to be able to explain why this year will be different from last year—new techniques, new priorities, new team members may indeed justify changing your previous allocations.

Next steps

I used to work for a company that generated 15% of their revenues from one product. Because of this, the president said he didn’t focus much on the product—he never spent more than 15% of his effort on it. However, if the product currently generates 15% but could generate more, you’ll need to convince your leadership why they should allocate more attention and funding to this emerging product.

Market and portfolio allocations can be estimated by product marketing (or market owners) and product management (or business owners) respectively and presented to the leadership team for revision and approval.

Your company leaders signal their top priorities with funding. They can tell us the relevant importance of specific markets and products by showing the percentage of money allocated to each.

Need help prioritizing your portfolio? Make it part of your product playbook.


About the author

Steve Johnson is a recognized thought leader and storyteller within the technology product management community. At Under10 Consulting, he helps product teams implement product management in an agile world. Sign up for his inspirational newsletter.

The Maturity of your Market Dictates the Type of Product that You Need

By Rivi Aspler

A few months ago, I linked the type of product manager that you want to hire, to the product life cycle stage that your product is at, saying that an engineering oriented product manager would be a better fit for a product that is at its first life cycle stages and that a marketing oriented product manager would be a better fit for the more mature product.


Taking it one step further, it is important to define the type of product that would be a better fit, for each market-stage.

This may seem like a non-issue, but trying to break into a mature market with a new product, you will be faced with companies and products that have been there for years. Trying to take market share from these veterans, you will have to bring something new., i.e. key differentiators.

The old saying that no one gets fired for choosing IBM, is maybe a cliché, but clichés are such, usually because they are true….


Immature markets, on the other hand, or early adopters, for that matter, are either still fragmented, or are  disappointed to one degree or another with their current products. They would be willing to consider a young product or an unknown vendor, if you had managed to prove that your product holds enough key differentiators.

Product management wise (and this is where it gets interesting), if you are building a product for a mature market and if your budget is limited, you have to make difficult choices. You will not have the money to build that mature product that the veterans already have as well as add those key differentiators that are an absolute necessity.

As a Product Manager, you will have to compromise on the completeness of the product in order to invest in differentiation. This means that you must consciously neglect all the bits and bytes that make your product feature-perfect. If you are a perfectionist, this may be painful for you.

Once you have your foot in the door, meaning you have earned enough industry attention and enough early-stage customers (i.e. perceived equity) – only then can you go back and fill the product-holes that you consciously left un-attended.

Good luck in building the product that your company really needs,


Tweet this: The Maturity of your Market Dictates the Type of Product that You Need #prodmgmt #innovation

Rivi is a product manager with over 15 years of product life-cycle management experience, at enterprise sized companies (SAP), as well as with small to medium-sized companies. Practicing product management for years, Rivi now feels she has amassed thoughts and experiences that are worth sharing.