One of the amazing things about doing web-based products and services is watching how quickly the service gets adopted internationally. With global access, and with good site analytics tools, we can see the service start to spread around the globe. But these of course are the early adopters, and for most products and services, we have considerable work to do to get the product working appropriately and successfully in countries around the world.

This note is not about what it takes to internationalize and then localize a product – I am assuming you know at least the basics of dealing with things like local language, currency, shipping, payment, content and support.

Instead, this note is about how the product manager can possibly be responsible for a product that will be sold to people he has never met, to people that speak a language he doesn’t understand, subject to laws that he isn’t aware of, and pay by mechanisms he has never used.

In the early days of the Internet, many companies just did a US-based product, and then passed the source code over to another group, or even another company (or a joint venture), to try to turn the product into something that’s useful in another country. There were of course obvious problems with this. First, it took a long time, often as long as 6 months to a year, for the software to become available in those other countries. Second, every time the US team made a new release, the process would essentially have to start again as the changes required were rarely incorporated into the US system. Third, the other group may have understood the new geography better, but they often didn’t understand the original product very well.

So most companies that were serious about the market beyond the US border realized that they had to do something different. They had to start treating the various country-specific versions of the product as one product, intended for a global market, and out of this need came the notion of the “global product manager” responsible for the single global product.

This single global product is still meant to be localized to the different markets, but the hardest problems are not usually associated with the localization, it is in enabling the necessary localizations by first defining a general enough and configurable enough core product such that i can be tailored to the needs of local geographies. We call this process of make software configurable for different geographies “internationalization.”

There are several important similarities between a global product manager and a platform product manager. I have written earlier about the challenges
of platform product management, especially in that you are building something intended to be used in very different ways, and how one of the keys is that the platform product manager must work closely with several application developers as they together explore and discover the necessary platform functionality. The same concept applies for the global product manager. He must work closely with people knowledgeable about the target countries to explore and discover the areas of the product that must be configurable and adaptable to meet the needs of the users in these countries.

One way to do this is for the product manager to make this a key priority and spend the time necessary to learn about the users, applicable laws, payment mechanisms and such, but this can of course take considerable time and travel. So especially larger companies realized that they can hire people that specialize in the local needs of specific geographies, and that’s where the notion of a “country product manager” came from.

The global product manager works with one or more country product managers to discover the areas that must be configurable to meet the needs of the different geographies.

Sometimes the country product managers are based near the global product managers (in this case we sometimes call them “international product managers”), but most of the time they are based in their responsible geography. There are obvious pros and cons to each, but in my experience either can work but be warned that significant communication and effort is required either way, and the global product managers must be actively encouraged and incented to work closely with the country product managers.

The country product managers also play a true product management role on the localization of the product for their local geography.

Many companies still struggle with global product management largely because they are trying to optimize their company around the US product and US market, and the notion of taking some time to identify global requirements and then build a global product that must then be localized for the US is not something most US business owners are anxious to do. This is why successful global product and service companies require a commitment by the senior management of the company that they are willing to make some trade-offs in order to ensure they can be successful on the global stage and not just in their own backyard.

Companies that are really good at global product are able to use their country product managers for more than just input on the global product and localizing product, but they can deploy early in specific countries to get early feedback (geographical deployment can be a very effective gentle deployment technique), and they can also work on general product discovery in country.

I want to point out that I have actually oversimplified things a little here. I have been talking about this as if there’s basically one release to the entire world, but in truth most companies do prioritize the world based on market opportunity. It’s common to have several tiers. The first tier might be major proven markets such as US, Canada, Germany, and the UK. The second tier might add India, China, Japan and Brazil. And a third tier might add smaller countries. Note that the opportunity for a country is not simply a matter of size, but rather the number of target customers and users that are willing and able to buy the product. Many companies are very anxious to sell to China, India and Brazil, for example, but the broadband penetration may not exist yet for the type of customers they are targeting.

If your company is at the point where you realize you need to expand beyond the market in your native country, these techniques can help you scale your efforts to meet the opportunities provided by a much larger world market.

Sign up for the free newsletter here.

I have already written about all the common roles in a product team, but in some companies, there is another role that exists and it goes by various ntitles including Subject Matter Experts (SME), Domain Experts, and Business Analysts. The defining characteristics of these people is that they are experts in the particulars of what the business does. For example, it’s normal for tax software companies to have tax experts on staff, and for payroll services companies to have a few people that have deep knowledge of
the national, state and local regulations regarding compensation and payroll taxes, and health care software companies to have physicians, nurses or other medical specialists.

In general, knowledge of the application domain is squarely in the responsibilities of the product manager, but for some products, there is so much specialized knowledge that it absolutely makes sense to provide the organization (especially the product managers) with direct access to true domain experts.

The product manager will utilize these subject matter experts in several cases. During product discovery, they will use these people to gain deeper insight into the market, the users, the domain and especially the necessary business logic. Similarly they will be very useful to the QA organization as they work to define test cases and understand expected behavior, and help with acceptance testing.

You will need to use care not to consider these subject matter experts as a substitute for talking directly to customers and users. In general, your subject matter experts will not be representative of your customer base. If your customers actually had direct access to people like your subject matter experts, they probably wouldn’t need your software. Your experts will know much more about the domain than a typical customer, and of course they will care much more about your company than any customer would.

Organizationally, companies often don’t really know where to put the subject matter experts. Sometimes they are part of the QA team, and sometimes part of the product management team, and other times you find them just hanging off to the side of the org chart. I prefer to see them closely associated with the product management team because primarily they are a shared resource to the product managers, and the product managers need to be encouraged to use them early and often in their product discovery work.

This is not a role that most companies need in that it is usually reasonable to expect the product managers to become expert in the domain, and to play this role for the product. But for certain products where the domain expertise required is extensive, this role can be a valuable, highly leveraged resource for the company.

Sign up for the free newsletter here.

Quite a few companies that exist today began life as something other than a product or Internet software company. Perhaps your company began as a large brick-and-mortar retailer, or an airline, or a financial services company.

While it is true that these companies all create lots of software to run their businesses, typically these companies are not set up to produce the type of software that they depend on for their business today.

For example, the retailer creates (or buys) software to coordinate and manage inventory, distribution, billing, and point of sale systems. And the airlines write software to manage the logistics involved in flights, crews, reservations, payment, and fleet maintenance. And the financial servicescompany writes software to manage their customer’s assets and investments.

But over the past 10 years, virtually all of these companies as well as those from dozens of other industries have realized that they need to use the Internet to engage directly with their customers online.

Today most retailers also sell their goods directly to consumers online. Most users book and purchase their air travel online directly through the airline’s site or through a reseller’s site. And nearly all financial services companies let their customers manage assets and trade directly via real-time financial sites.

I don’t need to tell anyone that reads these articles how fundamentally the Internet has transformed businesses.

However, many of these companies are trying to manage this new customer-facing internet software as if it were their internal-facing IT software, and the result is that many of these companies provide terrible online customer experiences, and worse, they don’t have the organization, people or processes in place to improve them.

I run into this often, especially when I am outside of Silicon Valley, and when I am in Europe or Asia or Australia, I find this case to be the norm. I’ll be brought into a company and they often don’t have product managers or user experience designers – they generally do have project managers, andmaybe some form of “business analyst,” and of course IT developers, and they all usually report into a CIO. Sometimes I even find that the company has been outsourcing “the website” to external agencies to design and run.

To be clear, when I say “product organization” I am referring to a software organization that creates products and services for end-customers (thousands to millions), and not just employees and partners.

Why is product software so different than IT software? Several reasons: you pay your employees to work at your company and use the software you tell them they need to use; in contrast, in product software, every user makes his own purchase decision – if they don’t want it, they won’t use it. Further, with your own employees you can get away with requiring training courses, reading manuals, and specialized professional services; in contrast, in product software, if users can’t figure out how to use your software they are a click away from your competitor. For IT software, you measure scale and simultaneous usage in the hundreds of users; in contrast, with product software, it’s in the hundreds of thousands or often millions of users. For IT software, if there is an issue with the software, they are your employees and they are forced to deal with it; for product software, an issue such as an outage disrupts revenue and immediately gets the attention of the CEO and often the press.

The truth is that most product software has a much higher bar in terms of the definition, design, implementation, testing, deployment and support than is necessary than most IT software. It’s also true that salaries usually reflect this. Finding people with the necessary product software experience is much harder than finding IT experience.

To help these IT organizations, in this article I wanted to highlight the typical changes that are needed to evolve an IT organization to an effective software product organization.

1) First draw a clear line between customer-facing software and internal software. The demands are different, the skills needed are different, and you will find you need different staff, processes and resources. Don’t get me wrong – both are important, but they are very different and most of your focus must be on your product software. If you can outsource or buy off-the-shelf any of your true IT software (internal-facing software) you should do so, so that you can put your best people, time and mind-share on the customer-facing software.

2) You will need product managers to represent the needs of your target users and lead the product discovery effort. You probably already have project managers, but if not, you’ll need project managers too, just don’t make the mistake of trying to hire one person to cover project management and product management.

3) You will need user experience designers, especially interaction designers, because designing software that doesn’t require hand-holding or a training course is hard.

4) You will need to hire engineers and web developers that understand the demands of large-scale, highly available software, and how it is different than “enterprise software.” While you may yourself be an “enterprise,” that term is referring to your IT organization and not your product organization, where you are trying to create something very different and much harder.

5) You will need QA engineers, because you will need to ensure that your software runs in the range of user environments, and under load, and outages that stop revenue from coming in are much worse than those that slow down your own employees.

6) You will need site operations staff including site security because keeping your site operational 7x24x365 is very difficult and requires special skills and processes.

7) You will likely need to revisit your software development processes from planning through to launch, as the needs of product software are so different from IT software.

8) You will need an online marketing organization. Getting people to your site is not easy in today’s search-engine-driven world, and this is a competency that many IT organizations have not realized they needed.

9) You will need to reprioritize your efforts around the fact that this customer-facing experience that allows users to directly engage to buy or use the products or services of your company is not something superficial – it needs to become a core competency of your company. This is not something to pass off to external agencies.

10) Determine your key business metrics, instrument your site, study the daily reports religiously, and then drive relentlessly to improve the key metrics.

If you don’t yet know what any of the roles or processes I referred to are, you can find out about each of these from the articles at www.svpg.com/articles.

A note of warning: there is a very large, established and lucrative industry around assisting IT organizations (especially professional services companies and agencies). Unfortunately, most of these organizations don’t understand the differences for product software either, which just causes this problem to perpetuate. In fairness, the vast majority of software out there is still custom, IT software, and these firms can help greatly in creating that software. But product software is a different animal entirely, so keep that in mind when talking to these firms.

For many companies establishing a true product software competency is the most important thing for them to be doing to ensure their survival, yet surprisingly some of them don’t even realize they have the problem. They assume that “software is software” and the same guys that managed their SAP implementation for them shouldn’t have too much trouble getting something going on the web. If you are at one of these companies, hopefully you can encourage your management to consider the ten steps above and see if you can’t get things to improve.

Sign up for the free newsletter here.