Industry pundits claim that 9 out of 10 product releases are failures in that they don’t meet their goals. I don’t know if that’s the exact stat or not, but I bet it’s not far off. I do believe strongly that most releases are ill-conceived. Countless release cycles are wasted on products that are either not useful or not usable. There are many reasons for these bad products, and each article I write is intended to address some aspect, but I have long argued that the root cause of these wasted releases can most often be traced to how the role of product manager is defined at your company, and the capabilities of the people you choose for this role.

I have been meaning to write this article for over a year now. It’s a topic I’ve been thinking about for a long time, but one that I consider critically important as it gets to the core of what the job of the product manager truly needs to be. It is hard to write because I know how tough it is to try to get an industry to change the way it thinks of roles, and even to change the nomenclature it uses in talking about these roles.

Before we get started, to explain this issue I will have to define some terms, fully aware that these definitions will contradict their use in many companies. I define the role of the product manager first and foremost as the person responsible for defining – in detail – the product that the engineering team will build. I define the role of product marketing as responsible for telling the world about this product.

More about each role below, but as you can see, these are extremely different jobs.

To be clear right from the start, I argue that every product needs a single, accountable product manager, responsible for the product definition (the combination of product requirements and user experience that describe the product to be built).

However, unfortunately, all too often when I begin working with a company I encounter one of three different situations:

1) there is a product marketing or product manager titled person responsible for the high-level product requirements, and then the product goes straight to engineering – bypassing detailed product requirements and the many tough decisions that go along with that (and also very often bypassing user experience design, but that’s the topic of an earlier set of articles)

2) the product definition role is split between a product marketing person responsible for the high-level business/product requirements, and a product manager person responsible for the low-level product requirements

3) a product marketing person is asked to cover both roles (and the company sometimes calls these people product managers and sometimes product marketing)

Let’s discuss each of these three problem situations:

- Marketing-driven Product

This situation is pretty easy to spot. The rest of the product team views this person as “the marketing resource” that might be useful for creating data sheets, training the sales force, and coming up with the naming and pricing, but in terms of defining the product, this person is largely discounted and ignored. There are plenty of Dilbert cartoons portraying this person, and we’ve all known this type of product manager. While these people might be great at marketing, they are in way over their heads in trying to define in detail a useful and usable product. In this situation, hopefully someone else on the product team steps in and performs the true product management function, sometimes a lead engineer, sometimes a designer, and sometimes a manager. If that person has the skills, and also the bandwidth, the product may still succeed. More often, however, the product is in trouble right from the start.

My first exposure to product management was with this situation, and it initially kept me from wanting to have any association at all with this role, but then I met a guy that showed me what product management was really all about. So then my reaction was to rename the role to something different, but that’s a battle I soon realized had its own problems, so instead I’ve worked to highlight the successful product managers and work to redefine the role around these people.

- Two People, One Role

This situation is also easy to spot, as there is no single product owner. A product marketing person (sometimes in this model called the “business owner”) is responsible for the high-level business requirements, and a product manager is responsible for the low-level product requirements. The problem is that neither person truly owns the product, and more importantly, neither person feels and behaves like they are the one ultimately responsible for the product. Further, this model is based on a flawed view of software that believes that you can define high-level product requirements independent of detailed requirements and especially the user experience. When you have this model, the product managers become essentially a spec-generation service. It is a frustrating job that tends to stifle innovation, and rarely produces winning products.

Many larger companies with multiple business units evolve into this situation and then wonder why they can no longer come up with innovative products that their customers love.

- One Person, Two Roles

The problem with combining the product manager role with product marketing is that it is very hard to find someone who can do both types of jobs well. Each of these roles is critical, and each requires special skills and talents. Creating a product is much different than telling the world about that product. I have known some truly exceptional people that can excel in both roles, but these people are very rare and as an organizational model it doesn’t scale. Further, for all but the simplest of products, the role of product manager as defined here is an all-consuming, full-time job, requiring a dedicated person. If you ask the product marketing person to cover the product management role, even if the person has the skills and talents required for both, it is unlikely he will have the bandwidth to do both jobs well.

This is most frequently a problem at enterprise software companies where supporting the sales force is a big job in itself, and there is a strong tendency for the product managers simply to pass along (perceived) requirements from the big customers, to the sales reps, to the product managers, and then to the engineers. Almost never results in useful and usable products.


It is important to recognize that there are reasons for each of the organizational models described above, but I argue that the companies are sacrificing far more than they realize. They are wasting entire product release cycles. They are creating products that customers don’t want, or must struggle with to use.

The way out is to clearly define the distinct roles of product manager and product marketing in your company. The product manager is responsible for defining – in detail – the product to be built, and validate that product with real customers and users. The product marketing person is responsible for telling the world about that product, managing the product launch, providing tools for the sales channel to market and sell the product, and for leading key programs such as online marketing and influencer marketing programs.

Please note that nothing in this article should be construed as claiming that the product marketing role is unimportant. I have learned that it is, and great product marketing is extremely valuable. But it has little to do with the product manager role that I have described here.

In general the product manager and product marketing person will communicate often and collaborate occasionally on specific topics, but there are two main interactions. First, the product marketing person will be one of the several sources of input to product requirements owned by the product manager. Second, the product manager will be one of the several sources of input to marketing messages owned by product marketing.

By whatever title or organizational model, behind every great product, I promise you that you will find someone responsible for the definition of that product. Remember that it doesn’t matter how great your engineering organization is if you don’t give them something useful and usable to build.

Email to a friend

Sign up for the free newsletter here.

Recently Microsoft launched what may prove to be a very significant technology for those of us that build rich Internet applications. You can learn about this at www.microsoft.com/silverlight <http://www.microsoft.com/silverlight> . But this note isn’t really about Silverlight; it’s about some lessons from their launch. Silverlight is a platform technology, and normally Microsoft is quite good at launching this type of product, and I do think there is true promise for this technology, however, I am very unimpressed with this launch.

Most importantly, one thing you won’t find on their site are good customer references – in this case, reference applications. At least as of this writing (and I’ve been following this site for a couple months now), there is only one true reference site (Fox Movies), and I still have not been able to get it to run correctly on my Mac (which given the cross-platform claims, this should be bullet-proof).

So I thought I’d use this example to point out one of the most powerful and proven techniques in product management. One that Microsoft usually does quite well but for some reason they seem to have fallen down on here.

Before we get too far, let me state up front that there is nothing more important or compelling when launching a product than to have a solid set of reference customers (or reference applications for a platform product).

The magic number to me is six. Before advising any of my clients to use a new technology or product, I look to see if the product has at least six live and public customers that have problems very similar to the ones my clients are looking to solve.

If there are no references, this is a huge red flag, and usually means the product is either bad or not yet ready for prime time. And you don't want to be the first to try to use.

If there’s only one or a few reference sites, I worry that what’s been built is essentially a special, and that it won’t be generally useful.

Note that this applies whether we’re talking a platform technology like Silverlight, a business application, or even a consumer internet service. Potential customers need to know that this product really works for people like them.

If at launch, there are half a dozen marquee names publicly stating their use and satisfaction with a product, then the job of the sales and marketing folks is dramatically easier, as the largest risk the potential customer faces is dramatically reduced. On the other hand, if you don’t have good reference customers, all the creative marketing and clever sales tactics in the world will only take you so far.

Now let’s move for a moment from talking about the launch to the very beginning of the project.

As product manager, you know your job is to gain a deep understanding of your target customer, the problems to be solved, and whether you can come up with a product that meets these needs. You know you need to work closely and directly with customers in order to come up with a product that will meet the needs of hundreds of customers (and thousands or even millions of users), but you also know there aren’t enough hours in the day to work directly with this many customers.

My favorite technique for addressing both of these problems – getting deep insight into my target customers and having great reference customers at launch – is to use a charter customer program (also known as a “Customer Advisory Board” or “Customer Council” or by similar names). This is not a new technique (I did my first at HP about 20 years ago), and many companies do this, but I’m surprised at how many do not.

The program is fairly straightforward. Your goal is to end with at least 6 happy, live, referenceable customers from your target market. That means you’ll probably need to start with 8-10. So your job is to recruit these customers right at the start of your project. You’re looking for customers in your target market, that would make great references. They may be from your existing customer base, or prospects, or often a blend. The key is that they believe this is a real problem to solve and they need it solved as fast as possible.

Here’s the deal:

The benefits to the customers/users that join:

- they get early and significant product input – they recognize the problem that this product is trying to solve and they feel the pain and are anxious to ensure they find a good solution

- they get early access to the product – again, they feel the pain so the sooner they can get relief the better

- typically there is a significantly reduced cost, if any

The benefits to you:

- you have a set of users and customers available for ongoing questions and dialog

- you have access to the customer’s offices and the users at that company (or the company’s developers if it’s a platform product)

- the customers/users agree to come to your offices periodically for group sessions

- the customer agrees to deploy test versions promptly and provide timely feedback (you’ll typically be there with them)

- if they are happy with the delivered product, the customer agrees to serve as a public reference customer

A few critical points:

- It’s important that the customer not pay in advance to participate in this program. That would make this a very different type of relationship. You want a partner in coming up with the product. You do not want to build a custom solution just for them, and you’re not a project shop. You can take their money after you deliver them a product they love.

- If you’re like most companies, you will be overwhelmed with customers that want to participate. It really is a great deal, and customers know this. If you have a sales organization, they’ll try to use this as a bargaining chip, and the result is that you'll be leaned on to include many more customers than you can handle. This will take finesse at times, but it’s important that the members of the charter customer program be the right set. (Sometimes companies create an early release program that is essentially unlimited for those customers that want the software early but aren’t right for the charter customer program. This is fine. Just make sure you don’t accept more than about 10 customers as you won’t be able to manage them and work as closely as you need to with that many.)

- If you find that you are having real trouble recruiting charter customers, then it’s very likely you are chasing a problem that just isn’t that important, and you will probably have a very hard time selling this product. This is one of the very first reality checks to make sure you are spending your time on something worthwhile. If customers aren’t interested in this problem, you may want to rethink your plans.

- You need to make sure your charter customers are truly from your target market. It’s easy to end up with early adopters, which are much more tolerant and can easily lead to a product only useful by early adopters.

- You will need to explain to each member of the program that you are trying to come up with a general product here, something that you can successfully sell to a large number of customers. You’re not trying to build a custom solution that only works for that one company, and they wouldn’t really want that in any case (if you can’t build a real business with that product, you’ll go under and they’ll be left with unsupported, dead-end software). You are, however, deeply committed to coming up with a product that works very well for them.

- You need to think of these charter customers as development partners. You’re in this together. You need to treat them as colleagues. Open the kimono. You are helping each other. You’ll find that the relationships you create can last for decades.

- You will be interacting with these people throughout the project lifecycle - you'll be showing them prototypes and testing with their users, you'll be asking hundreds of detailed questions, and you'll be testing release candidates in their environment.

- Make sure you release the software to these people before the general release, and make sure they are live and happy before the release. When you launch, they’ll be ready to stand up for you.

Note that I talked here mainly about customers in an enterprise software or a platform product sense, but these techniques also work with end-users for consumer internet services and consumer devices as well. For consumer services, it’s ok to expand the set to 10-15 or so, but the key is to really get to know these people and the environment that they will be using your product – home or office. It is all too easy when designing a site for consumers to actually have far too little exposure to true target users until very late in the process (beta or even launch). This is very dangerous, and a program like this helps keep the product manager focused on providing real value to real users. In terms of marketing, when a consumer decides to buy or use a product, they may not look at all the reference customers like a business purchaser would, but they are affected by press and other influencers, and when the press writes a story about your product, the first thing they’ll look for is real users.

If at Silverlight’s launch, Microsoft had been able to cite at least six showcase examples of web sites built using Silverlight and show how impressive those sites are and how happy the businesses are that used this platform, imagine how much more interest and excitement there would have been around this launch, and how much more likely companies would be right now to build a site using it.

This really is an easy and powerful technique to ensure that you’re building a product that customers want, and that you can prove to prospective customers that they’re likely to be successful and happy if they go with you.

Email to a friend

Sign up for the free newsletter here.