The Strategic Role of Product Management with Steve Johnson, VP Pragmatic Marketing

FULL WEBINAR TRANSCRIPT:

Good morning, I'm Steve Johnson with Pragmatic Marketing.

We're going to spend the next few minutes talking about our strategic role for product management.

A lot of the companies I have worked with have defined it by what it isn't rather than what it is.

It's not sales. It's not development. It's not marcom. It's something else.

We're going to look at that today.

You can find out more about Pragmatic Marketing on our website, pragmaticmarketing.com, which has more information about our seminars and courses. You can also find information about product management and product marketing in general at our free resource site called productmarketing.com, and some additional tools helpful from this seminar can be found at productmarketing.com/eb. You'll find some worksheets and stuff I'll talk about while we're together.

Pragmatic Marketing has been around technology for over a decade as we work with technology and primarily with product management and product marketing people at technology companies around the world.

Since '93, we've trained over 30,000 people in some of the stuff I'll be showing you today. I think we've found - I think most places I've worked with - have found that technology marketing seems to be different than the stuff we learned in college. So we'll look at some of the stuff we learned in college and see if we can apply a technology spin to it.

Furthermore, a lot of product managers find there is a great deal of stress in the job of product management because we don't really know how to do it. There's not a Procedures Manual - and the stuff we learned in college is pretty hard to apply to the business we're in. We'll be looking at that today.

This is the tool for which we are best known; a definition of what the job of product management is rather than defining it by what it isn't. That is the focus of our session today as we walk through these different categories of functions and look at what they mean and how we can use this tool to get our arms around the job of product management.

We're talking about the role, not the title. I was in a session recently and had 16 people in the room - 16 different titles - and they all did the same thing. I was talking to one group and they said 'you're talking about product management but I think you mean industry management,' and someone else said 'no, I think he means solution management,' and we argued about the title - but nobody disagreed about the role.

All these boxes have to happen; all these activities have to happen.

When I work with small companies, it turns out there is a product manager; it's the president. But as we grow older and bigger and have more people, the president can no longer apply his attention down at the product level because he's too busy with hiring and firing and cash flow and financing and signage and dabbling in marcom.

So these are some of the titles we find but we want to talk about the role of product management while we're together.

It might help to look at this graphic. Product management is stuck in between the Development group, the marcom organization and the Sales organization. But how far do we go into those organizations. A lot of those organizations - product management is in the Development group and they frequently become the assistant to the development process. But how far do we go? In most organizations it's pretty clear the product managers write requirements but sometimes we go further and write specifications and screen diagrams and test plans and where does product management stop and development begin.

So we'll look at some lines between product management and development while we are together.

How far does product management go into the marcom - marketing communications organization. In a lot of organizations, product management is doing all of the copy - writing all the copy or at least approving it. One company said they defined marketing as applying the corporate template and making sure all the TMs were used correctly. It seems marcom should have more of a contribution than that.

There ought to be a pretty clear line between what product management is and what marketing communication is. That line is blurred in a lot of organizations.

Finally, how far do we go from the product management organization into the sales organization. I am depressed to l earn how much time product managers often spend supporting the sales effort; doing that strategic role I refer to as 'demo boy' or 'demo girl' - one company calls it 'demo monkey'. That's got to feel good. Or answering sales peoples questions because apparently it's easier to call a product manager than it is to find it on the internet - which actually may be true in a lot of organizations.

So what are the lines between these departments is really the subject of what we'll be talking about today. One of the funny questions to ask executives, is what is marketing. Because they almost always say it's the 4P but they can't remember really any of them. They remember price and then three other words with a P in it.

Here are three of them: the product, promotion and place. The missing one for technology businesses, is problem. It is the problem that should determine our product. It is the problem we should be emphasizing in the positioning and our messaging and our promotion. It's the problem that makes it easier to sell products. Really good sales people - if you've seen good selling - really good sales people sell problems first and then say, 'I might have a solution', as opposed to saying, 'Heh, we've got a bunch of features. Let me read them all to you and if you ever are interested, ring your little bell.'

It's the problem that should determine the price of our product as well. It doesn't matter how hard it was for you to build. It matters how important the problem is to the buyer. The buyer is willing to pay more for a bigger pain, if you will.

The other thing I like about this definition of the 4Ps, is it gives me a very clear ownership of different parts of running the business, starting with the problems the responsibility of products management - finding and quantifying problems in the market, and delivering that information to development in the form of requirements.

Likewise, by the way, delivering that to our services organization as well. Our services should be repeatable the same way development is. Instead of saying 'Heh, we've got man hours for sale', we say 'We've got these services ready to deliver.' We already know how to do implementation assistance, and you can buy packages of the 100-person size and the 200-person size and the 300-person size depending on how big your shop is - instead of 'we've got man hours for sale.'

Then we can deliver the product which might be a service to marcom, to communicate so the sales can ultimately sell it profitably. In effect, the problem serves as a baton that we move through the organization.

Unfortunately, I find a lot of cases the product managers have not done the problem so they run alongside development and co-develop the product for a while. Then when the product is finished, they run alongside marcom and co-market the product for a while. Then we get into the sales organization, we run along the sales organization for a while and co-sell the product - and then wonder we're so tired.

We're running 3 laps but we haven't run our own lap. What we're missing is the baton which is the metaphor here of what the problem is.

We pass the baton through the organization.

Fundamentally if product managers don't do t heir strategic jobs the other departments have to. If you've ever attended sales training, you know the first day is marketing. It's positioning. Profile definition or what's the ideal prospect look like and probing for pain questions.

These are the things that product managers should have done but because product management hasn't, sales has to do it. Often marcom gets involved in writing up collateral because somebody has to do it. Since product management hasn't given us any positioning, they don't really know what to say, so they say it's scaleable.

But most of all, if we don't tell development about problems in the market we end up with products like this. This is the internet enabled, picture taking, computer based refrigerator. This comes from people thinking too much and not being very aware of the market, don't you think?

This is the kind of product that comes from what we call inside out thinking. A bunch of us, sitting in a conference room, around a nice conference room table, thinking about what's possible now that we have Ajax; now that we have Java; now that we have whatever four letter acronym of the day - and we come up with this idea for internet refrigerator and right then a sales guy walks by and we go, Yo, slick, come here for a second. We're thinking about building this thing - this internet enabled refrigerator. What do you think. Can you sell it?

Sales guy says - of course I can. I can sell anything. So now we have market validation. We build it, we hand it to sales, and sales goes out in the world and despite their superior salesmanship, they can't find anybody dumb enough to buy this product.

The blame falls on - somehow - marketing.

We now say to marketing, 'Heh, there's the deal. You guys need to create the need for this product.' The problem is you can't. People don't need what they don't need. And we say create the need. But what we're really saying is we know this is a pig product but if you perfume it, maybe people won't know that. Put some lipstick on this pig. Let's see if people will not notice that this is just a bad idea. No amount of perfume can overcome the stench of a pig product like this.

What we talk about, what product managers are fundamentally about, is representing an outside-in approach to the business. There are two ways to build your business. One way is to continue thinking of ideas from the inside out and saying well, here's what we thought of; I wonder if we can find anybody to buy it. That's one way. Another way is outside-in. Somebody leaves the building and finds a problem, and brings that back to us, and says you know what - we found this problem - if we solved it, people would dig it.

Companies that do that second thing; finding problems first, selecting technology second, have half the time to market as other companies. I think it's fundamentally because development knows when they are finished. We'll just build until we solve these problems and then we'll finish. Then we'll ship it.

Instead of, let's build stuff until the president has a hissy fit, and says damn, I need you to ship something and we say okay; how about this. Outside-in is easier, it has lower risk and frankly it's a lot more fun for a lot of companies.

But what do we find product managers doing. Product managers are involved in a whole bunch of activities from strategic to tactical. I live outside D.C. - Washington, D.C. It's about 20 miles from my house to the old office. It used to take me about an hour and a half to get to work. That was really the highlight of my day. It was the only chance I got all day to think.

Then I get to the office, the phone would ring, it would be Kevin, the worst living sales person, calling me from Atlanta, help, I'm losing a deal, I need you to talk to a customer, in fact he's on the other line - in fact he's on the line - go ahead.

I'd spend an hour and a half dealing with this sales problem. Then I'd check my voicemail; development needs me to come down and pick an icon before the end of business or marcom needs me to add some more ility words to some of their copy. Or I go to a meeting. Typical product manager goes to a dozen meetings a week. No wonder we can't get any work done; we're in a meeting.

Did you ever have one of those meetings where you come back to the meeting and you ask how you are doing on your action items and you realize you've been in meetings since the last time t his meeting was held?

So we find that we are being pulled into the tactical activities to the detriment of the strategic. I largely blame the cell phone. I've got a mobile phone; I've got a Trio - it's with me all the time.

I can always be reached by email, by paging, by instant message, by phone calls. I'm constantly in touch. Why do I have to be so in touch? Can't we go three hours without not calling a product manager?

What are the things we are involved in. some of the things we do are less technical, some are more technical, and we've categorized them this way; on the left hand side of the chart, we have market analysis; quantitative analysis. Let's make sure it's big enough to bother. Then a product strategy. Then we'll do our product planning. Then on the right hand side, we'll go to market with a program strategy. We'll get sales ready and provide continuing channel support.

These are the categories of activity. Some are technical. Some are less so. I don't think any of them are non-technical. It's a technology job and the fastest way to lose credibility in a company is to say, 'well, I'm not really technical.'
After that, everybody watches you talk but they're not listening. It's like talking to a cat.

So what are the things that are more technical. How about these. Let's do a competitive analysis. Let's do a technology assessment. Let's do win/loss analysis which is a product management's function, not a sales function.

From product management we can see what are the things that are going wrong systemically. What are things procedurally that are happening. What are problems in the product that are happening as opposed to the sales person who would be inclined, naturally, to focus on the problem of that deal.

What product managers are looking at, is what are the problems in the market full of deals. How about understanding innovations and how they might be deployed to solve problems for our customers. Understanding buyer and user personas and the fact that those are different. Aren't they? Does the buyer use your product? Typically not. Does the user buy your product? Typically not.

With anything more expensive than, say, a candy bar. And even in the candy bar you're playing both roles. Does this have enough fat grams and do I have enough money for it. Mmmmm ... it's got nugget. So we're the buyer and user in that scenario.

Think about your laptop. You came to work at th is company, and this IT department said, 'Do you travel,' and you said yes or no . And depending on that answer, you got a computer. There were no other requirements. Do you travel? Yes. Here's your laptop. Oh, you want something other than that? Tough; we don't do that. The buyer says we've got laptops and we've got desktops and that's all we've got.

But it's the users that are going to drive a lot of our product planning. It's definitely the buyers that are going to drive our go to market strategy. How are we going to communicate to them to make a buyer decision.

Then we'll get sales ready, we'll channel training and collateral and write papers and presentations and demos, and yet we often go on a lot of special calls. Sales calls and says I've got a sales engineer but he doesn't know enough ... I need you ... you're special ... this is a special deal ... it's not a big deal now but it has huge potential ... or they don't want what we have now so we want you to sell them the roadmap instead ... providing support at events, and most of all, answering sales questions over the phone. Just call 1800ICAN'T READ and a product manager will read to you all the information on the internet.

How often do you find those answer are, 'that's on the internet' and the sales guy says, 'well, yeah; but you're right there,' and so we find ourselves reading stuff on the internet to our sales people. How depressing.

How about some of the stuff above the line; the less technical, the more business oriented stuff. How about let's understand market problems. Do a little market research all within our company's distinctive competence. They'll make sure it's big enough to bother with market sizing. Let's identify some market segments and identify how big those segments are and make sure it's big enough to bother.

Which is fundamentally the difference between sales and marketing. Product management is looking for markets full of deals and we want sales to find us deals. Population = one as opposed to population = many.

From our distinctive competence and prospect problems and market sizing, we're ready to put together a business case which is the source of credibility of product managers at the senior executive team. That business case includes pricing and viable partner decisions and how this is going to fit in the overall product portfolio.

We'll also need to do positioning and sales process and market requirements and come up with a marketing plan that differentiates between customer acquisition and customer retention. They are different, right? I mean yeah; we want to acquire customers, that's why we have sales people. But we want to keep them too. That's why we have support. That's why we have on-going retention programs like blogging, newspapers, magazines; ways of getting it further immersed in the company's culture.

Here are the activities involved in, in a technical company. There's a lot going on here. There's a wide range of activity. Sadly, we find product managers spend an awful lot of time in these green boxes on the right hand side; getting sales ready and providing continuing sales support.

These are maybe important things but they take an awful lot of our time. And worst of all, product managers don't get credit for it. People look at that and go wow; that's not I thought product management did. That's what we thought sales engineers did. If you have that role. But most of all the senior executive team doesn't appreciate it. Product managers spend all their time supporting the sales effort, and in two years you get fired for it because the CFO doesn't appreciate the product managers were doing all the sales support because that's not what we were hired to do.

What about this stuff on the left hand side; market analysis through program strategy. The strategic side of product management. Those are the things that the executive team hired us for. The problem is we try to approach this chart from the right hand side, and it doesn't work.

We need to come at it from the left hand side instead. Who in the company understands market problems within our distinctive market competence. That's the key. Distinctive competence is your unique ability to deliver value to the market.

Why should I do business with you instead of your better known competitor or your larger competitor or your smaller competitor. Why you. That distinctive competence will color all the other decisions on this chart.

If quality, support, superior service, superior customer relationships, superior salesmanship are the key attributes of our distinctive competence, then guess what. We should be charging more for all of our products rather than less.

If you're the WalMart of software, no price is too low, we've got operational excellent, then we should have low prices. But the point is, that your distinctive competence drives the rest of this chart.

Your positioning and your pricing and your decisions to buy ... partner, should all be influenced by what is our unique ability to deliver value to the market. That plus market problems gives guidance to the rest of this chart.

In effect, the left hand side of this chart teaches us what we need to know about the market. We can bring that to a focal point in product planning. Once there, we create a product and we can take the result to market on the right hand side of the chart.

The left hand side is where we learn what the market will buy; will learn the problems they have and what products they want to buy whereas the right hand side of the chart is telling them what we've built and getting them to buy it.

Unfortunately you really can't learn much about the market in the typical activities on the right hand side because you're too busy selling. The client says well actually, I have an unsolved prospect problem and you say no; actually you don't. Because your problem is you're not buying what I'm selling you right now.

What we'll find is, the time we spend on the strategic will dramatically reduce the time wasted on the tactical side of the chart. If we knew who we were selling to, if we knew our distinctive competence, if we knew the problems they had, all the stuff we did on the right would be much easier, wouldn't it. We wouldn't have to do it over and over again because we'd do it one time right.

In the center of the chart, are three critical documents that in fact connect the left side with the right side.

The information we learned from the left hand side of the chart, we're going to articulate to marketing communications in a form known as deditioning. We're going to communicate what we learn in the market to sales through a thing called a sales process document that sales based on the sales process, here are the tools we've provided to help you navigate through the funnel using your nomenclature but this product's tool.

Then finally, we're going to communicate to development in a form known as market requirements. We cover each of these boxes in our training courses.

Our practical product management class covers everything except for that center, technical planning column, and then requirements that were classed drill down into market requirements, product roadmap, user persona, use scenarios and release milestones.

What we need to, I think, embrace, is the idea that there are market requirements rather than marketing requirements. Marketing doesn't buy a product. When working with development, development says I don't really care about what your opinion is, as much as what are the market facts that are driving us to these decisions.

If we articulate to our sales people, here's your method and our tool, then together we can navigate the funnel and close deals more quickly. We communicate to marcom through the positioning document so they can build - go to market strategy tools - the whole right hand side of the chart stuff - without having to come back to product management for content every time.

Most of all, we can communicate to the executive team in the product strategy column, showing here are the facts from the market, put into a format that executives understand, as opposed to I think it would be really cool if we built this product.

One way of using this chart is our agenda, as I've just indicated. Other ways of using the chart are to use it for delineation of responsibility. Who owns what around here.

In a small company, one product manager, you own the whole chart. Have a nice day.

Unfortunately the typical product manager is working 72 hours a week because we're trying to do the whole chart.

On top of that, we're trying to do the whole chart on three products.Typical product manager has not one but three products. No wonder we're so tired.

As a company grows to 25 million, roughly, in revenue, they tend to split this job in half. So the left hand side is one job and the right hand side is one job. Often we see the whole chart is called product management by some and product marketing by others - physically we find when we split them - a lot of times we use the term inbound and outbound - or the left sides is product management and the right hand side is product marketing.

This is one split we see pretty often. Another way of using this chart beyond our agenda, is to use the chart to define ownership. Who's going to own these boxes. Maybe it's individual names or maybe it's department names.

As we get up toward 50 million in revenue, we often see a third split happen. We create what's called the product management triad. We continue having a product marketing manager to the right hand side of the chart, but we then get a technical product manager doing the lower left hand corner; these purple boxes. And a director or senior product manager doing strategy - the upper left hand corner stuff - because that's the area that gets the least attention when there are too many things going on.

When we're asking more from the role than can be done, it seems to be strategy that falls away in favor of tactics. You know what? I find most people are good at only one of these colors. Most of us like being tactical or being technical or being a strategic.

I used to ask in job interviews. What's your favorite Microsoft Office product. The answer would tell me. If you like Excel, you're a strategic; you're the upper left hand corner person. If you can do in notes and footnotes in Word; you're purple. Come on; you're a technical guy. And if you like Powerpoint, you're over here in greenville.

These are the kinds of - I think people tend to be talented in only one of these areas. Maybe two but typically we are good in one of those areas, and when there's more work being requested of us than can be done, we gravitate to our safety zone; to our comfort zone.

Another way to use this chart, is to assess importance. How important is this. For your product right now in its life cycle, how important are these various activities. You sit down, you look at the chart, and you say here are these different boxes. Given where my product is right now, this company went through, as an example, put market problems as a 10 meaning it's a 10 in importance - very important - most important thing - and a 1 in terms of execution.

It's very important; we're doing a lousy job of it.

On the other hand, on the other side of the chart, presentations and demos; moderately important; we're doing a bang-up job of it.

Maybe we're doing even better than we should do.

Thomas Jefferson is supposed to have said, something not worth doing is not worth doing well. We seem to be doing something not that important extremely well.

We can use this tool to asses how important various activities are and I think you'll find over time the importance of those things changes as we move through the life cycle.

If you recall the URL on the very first page of this presentation productmarketing.com/eb - you'll find a gap analysis tool to help you do those things we just looked at on the chart.

Who owned this activity currently and who should. How important is this activity and how well have we done it. And perhaps, how much time should you spend and how much time do you spend.

We find these deltas - these gaps - between expectation and reality -- to be pretty illuminating as to where we should start focusing our time. If you're a manager of product managers, you can use this same tool to asses the skills of your product managers.

A lot of us are good at some things and not so good at others. Some prefer Powerpoint, some prefer Excel. Some are the other way around. So looking at this tool, you can see not only what does the product need, but then what people are best suited to meet the needs of the product. It gives you a hiring profile for other people you want to bring into the team.

Then finally, we can help with some other things. We offer an executive briefing on site. We offer a class called the Strategic Role of Product Management in a public seminar and it's really designed for you to bring executives and others that are tangential to product management in to kind of hear the message.

We offer a practical product management class and requirements that work class that covers the grid, and the effective marketing programs class focuses entirely on the right hand side of the chart, of how we can do the product marketing effort in a more repeatable consistent way.

Here's the framework for defining the job of product management.

We're covering a lot of ground; there's a lot of stuff going on here. It's a challenging job but it's also a very satisfying one if we can do more than just support sales.

In a survey not too long ago, it was reported that roughly 50% of the executives in technology business are former product managers. This job is very much like president of the product. And like president, ideally, product managers do know actual work.

We just make sure the work gets done.

A metaphor I like even better, is parent of the product. First of all, it doesn't imply you're the only parent. Although it is possible to raise these kids by yourself, it's kind of fun to have another sane adult in the room every once in a while. And as parent of the product, it says we don't do the work as make sure the work gets done.

One day, my wife said don't forget you have an algebra test on Friday. I went, what? You're doing his homework, I guess you have to take his test.

She's right.

So this is a framework for thinking of all the activities that have to happen to successfully deliver a product to market. It's a very helpful tool for defining what the job is and what it isn't and it's a very helpful tool for showing people around you in the organization, what contribution product management can make to the business of the product.

Pragmatic Marketing will be at a conference in June; the software marketing prospectus conference in June. I will be there speaking as will others from Pragmatic Marketing.

I hope you'll come by and look at what we have to say, and have an opportunity to network with others from the technology space that we're in.

Other than that, thank you very much for coming. I hope you found this a helpful seminar - something to give you another way of looking at the role of product management.