How to Make Less of a Mess in Software Product Management

By Bruce Hadley June 11, 2007

In our 20+ years in the software business, the messiest job we've ever seen is product management. Not because it's particularly dirty or greasy, but because so few understand it, yet nearly everyone claims that they do--and none will hesitate to tell you how badly you're doing at it.

And, this mess runs deep: Ask 10 software CEOs to define software product management, and you'll get 10 different answers. Ask another 10 where the job ought to live, department-wise, and you'll get at least three different answers. Ask another 10 to put a price tag on the position, and you'll get a range from secretarial to saint.

In terms of job security, there's probably nothing dicier than VP of sales--especially in a sour economy. But the product manager's job is right up there: To do it well, you need a renaissance-level assortment of skills, the charm and graciousness of a career diplomat, and the hide of rhino.

So, what the heck does a software product manager do? How do you know if you need one? And what are the prime mistakes to avoid in product management?

We recently caught up with Bill Corrigan, the VP of product management and marketing for Boston-based developer Softricity, founded in 1998.

Although the company isn't huge--55 employees and about $6 million in revenue this year--Corrigan's product management background is blue-ribbon: He previously worked for Calico Commerce, a Kleiner Perkins-backed developer that went public in 1999 then sold to PeopleSoft, and forIBM; he was the product manager for Lotus Notes for over 10 years.

Since Corrigan now has both 'management' and 'marketing' in his title, we thought that a good place to start:

What's the difference, we asked, between product management and product marketing?

'Product management means building the right product for the market at the right time, and helping sales sell it, ' Corrigan says. 'It means understanding your customer inside and out, so that you can deliver the right product to the right audience. Product management puts the product on the shelf; product marketing is getting people to take it off the shelf.'

Okay, next question:

Who should 'own' product management? To whom should the product manager report?

'Most successful companies have VP product management who reports to the CEO or COO or VP marketing, ' Corrigan says.

Why not R&D?

'Don't put it in engineering. You'll end up developing an ivory tower complex. When the development group controls product management, you tend to lose customer focus, and you start drinking your own Kool Aid.

'Engineers tend to get too inwardly focused, rather than customer focused, ' Corrigan says. 'Engineers are very good at building, at sticking to schedules, at drilling deep into the details. But if R&D owns product management, you'll get an inside-out view; if it comes through the CEO or marketing, you'll get a customer's perspective.

Then why not put the position in marketing?

'Well, engineering types don't often have the listening skills required, but pure marketing types don't have the ability to establish what's practical, ' Corrigan says.

Let's say I want to hire a product manager; where should I look?

'There are two places, ' Corrigan says. 'Many good product managers come out of a traditional sales engineering role. They've been out talking to customers, working with customers, most of their lives; that's where I came from, in fact. Often, those people have the technical wherewithal and the customer skills, but they may not have the discipline to focus on a set of deliverables.

'Second, I'd look at people who are coming out of an engineering role within a professional services organization. They likely understand the technology, but usually have a lot more interest about what's happening in the industry in general.'

It's unlikely you'll find a great product manager who came from a marketing background, Corrigan says. 'Those people usually don't have the technical depth that's necessary to be a good product manager. First, they lack that curiosity that drives them to play with product, to figure out what makes is work. And second, they don't have the credibility with the engineers. It's sort of like the Venus and Mars thing--engineers are from one planet, and marketing is from another.'

But, lest you think Corrigan just has it in for marketers, he says it's just as much a long shot that you'll turn one of your developers in to a successful product manager. 'It's going to be a very, very gifted engineer, ' he says. 'Most good product managers have come from a consulting background, or a sales engineering background--they have been implementing. It's highly unlikely you'll pull someone right out of development and put them in this role.'

Regardless of their background, Corrigan says it's vital that they can verbalize well, and use multiple modes of communication. 'You have to be able to cut left, cut right, and run right up the middle, ' he says. 'You also have to be the ultimate evangelist for your product.

'A product manager needs to be a technical person who is the ultimate communicator. He needs to gather information from customers, from analysts, VARs, and employees, then coalesce it into a vision and a product plan that's deliverable.'

Much of this is personality type, Corrigan says. 'You want someone who is a good listener. Somebody who is inquisitive and wants to solve the customer's problem--as opposed to someone who says, 'I have a new widget and isn't it cool?''

What's the overlap between product management and product marketing?

'Marketing is often looking at branding, how to capture mind share--you're spending a lot of time with analysts and the press, ' Corrigan says. 'You're looking at the best way to phrase this, to couch this issue.

'Product management is defining what a product could and should be. It's very hard to do both--most people tend to gravitate one way or another. I think they can report into the same organization, but not to each other--it's good to have the two separate disciplines.'

How does the product manager get customer feedback? How do you go about contacting them?

'You get very close to the people who are close to your customers--you become the sales people's best friend, ' Corrigan says. 'The product manager needs to proactively engage the direct sales channel and the resellers, so if it's the ugliest, most gnarly situation, they'll call you into it.

'The other thing you need to do is get on a plane and go out and deal with customers eyeball to eyeball--especially when they're complaining. Set the expectations correctly: If your product isn't working as advertised, then yes, tell them you're going to fix that problem.

'But if it's enhancement territory, you need to be upfront--tell them you're in it for the long haul, and you will look at their requests and do whatever we can. I'll tell the customer, 'I will fix bugs, I'll communicate your needs, I'll elevate your most serious requests--and I'll communicate that back to you. I can't guarantee you're going to get this feature, but I will get it into a queue, and I will let you know where it stands.' You must build credibility over time.'

What happens when an over-eager sales rep promises the moon?

'I have worked out plans with sales management to explain why that's damaging over the long haul, ' Corrigan says. 'We've actually have put discouragements into sales compensation plans, to show reps that ultimately they are the ones who will pay the price, because they have to look the customer in the eye.'

At what point should you hire a product manager? Is it a function of size or number of products or something else?

'It depends on the dynamics of the team, but you do need that product management role filled first, ' Corrigan says. 'But the thing is, in a small company the product manager is oftentimes the CEO--they become the person who defines the product, they direct engineers, and so on. In a small company, you can get away with that.

'But if your CEO comes from a sales background, one of your first hires needs to be the product manager. Too many software companies wait until after the fact--after product release--to realize the product was never defined to meet market requirements. Maybe along the line it got off track because no one was tracking deliverables other than the engineering team, or maybe they missed it altogether after a great initial idea.

'Either way, it's a huge and very common reason that companies fail: The product plan is a mess. I've done consulting for companies where they have 50 customers and 50 versions of the product, and their code stream is a mess.'

Okay, that's one example; what are some other tell-tale signs that you need a product manager?

Sign #1: Your engineers are spending more time out of the office than in. 'It's often because they are doing the job the product manager should have been doing--either gathering data or evangelizing, because the marketing person doesn't have the depth to do it, ' Corrigan says.

Sign #2: Sales is screaming for sales tools (and creating what they need on the fly). 'Marketing can do the high level stuff, but they can't do the technical demos, the technical white papers, the stuff that comes up during the course of the sale, ' Corrigan says.

'So, you'll see your sales people wasting a lot of valuable sales time creating the tools they need--competitive sell-against sheets, FAQs, etc.--because they don't feel what they've got is effective.'

Sign #3: You look at product plans for the next two years, and you see you need an engineering team that's four times as large as what you have. Put another way: Your pipeline and sales forecast is predicated on features and products that's beyond your ability to build.

This happens for two reasons, Corrigan says: 'First, sales doesn't understand the product--so they're selling futures. Second, you're not managing the process. Stuff is getting thrown at the engineers 'unscrubbed'--usually from sales. Everything is important, everything is urgent, and everything is a huge market opportunity.'

What about the person managing the product manager? What are the most common CEO's/VP's mistakes?

Exec's mistake #1: Trying to force their own personal views on the product roadmap. 'I had a CEO once who, I swear, had attention deficit disorder, ' Corrigan says. 'We had a well-defined, well-thought-out roadmap, and he would read something in Red Herring magazine about a successful IPO and say, 'Why aren't we doing that?' He'd yank engineers off a project, and then realize too late it was something we never should have been pursuing.'

As an example of this type, Corrigan cites Steve Jobs. 'He was, effectively, the product manager for Apple. He'd come out on stage at a big show and say we're going to do this, and this, and this--and often it was the first time the engineers had heard anything about it.'

Exec's mistake #2: Assuming that the engineers will deliver the right product. 'This is the opposite of the first mistake, ' Corrigan says. 'The product manager's boss needs to care about the roadmap, and needs to be engaged. Once a quarter, I sit down with the senior management team to say here's where we're going here's what needs to be done--just to keep the awareness high and the momentum going.

As positive examples of how execs ought to treat product management, Corrigan thinks Philippe Kahn and Bill Gates stand out. 'Gates is unbelievably talented in that regard, ' he says. 'He can go toe to toe with any engineer with their project plan. He can walk into any cube and Gates will know about the technology and ask them challenging questions.'

But that sounds like mistake #1, we said; isn't that micromanagement?

'You don't want to tell them what to build, or to divert focus from the roadmap,' Corrigan says. 'The trick--and what Gates does so well--is to create just enough tension to make people always seek out the best solution--to think, as opposed to just doing what they feel comfortable with.'

Okay, let 's look at the other side; what are the most common mistakes a software product manager is likely to make?

PM's mistake #1: Getting too entrenched on one side of the problem set. 'This is by far the biggest danger, ' Corrigan says. 'You either get too deep in the design, almost becoming an engineer, or you spend too much time on the outside and fail to bring that information in.'

PM's mistake #2: Not taking time to document what you're doing. 'Being a product manager is a very disciplined process, ' Corrigan says. 'You need to gather all the information and document it, so that people can see where you are and so that others can reuse your work. Your work is--or should be--the genesis of the functional spec.'

PM's mistake #3. Defining products rather than market requirements. 'Engineers get really bored when they're just treated like code monkeys, ' Corrigan says. 'You need to come in with a really clear set of requirements--the market needs these three pains to be solved--then engineering needs to respond with, we can solve that pain with these 10 features.

'Don't engineer the product for your developers; define the problem set in a complete enough way so that it can become an iterative process on both sides, drilling down to the definition.'

PM's mistake #4. Not getting clear consensus at project milestones. 'This has happened at almost every company I've been to, ' says Corrigan. 'You're three months into the schedule, the engineers have built something, and the product manager or the customer says, 'No that's not what we had in mind at all.''

The fix, Corrigan says, is what he calls a product contract. 'The contract gets all sides to agree that we're not going to deviate from this schedule. The product manager promises, that engineering is not going to get yanked around with requests for nine other things during this process.

'With that contract in place, all the downstream activities can start much earlier: the sales tools, training and demos, research, the press and analyst tour. Most companies do that stuff way after the fact, and that's because there's ambiguity right up until three weeks before the code is frozen. That ambiguity slows the whole product-to-market process down.'

Where should aspiring product managers go to learn more?

'The training class I like the best is from Pragmatic Institute--those guys are the best,' Corrigan says.

'From a book perspective, I love the Geoffrey Moore books, because they encompass the big picture, and show you everything that happens if you don't do it right. [Among Moore's titles: 'Crossing the Chasm, ''Inside the Tornado, ' and 'Living on the Fault Line.']

'Another good one is Jerry Kaplan's 'Startup: A Silicon Valley Adventure'--it's kind of funny, because he's the best person in the universe he's ever met, but the stuff his company goes through is very interesting from a product management perspective.

'I also recommend 'High Stakes, No Prisoners' by Charles Ferguson--he's the guy who conceived and built FrontPage. He wrote a thesis at Harvard about how to bring that product to market, then went out and did it.'

Editor's note: We didn't prompt Bill Corrigan to mention Pragmatic Institute, but we're glad that he did--and we agree that they're the best. That's why we recruited them to teach a class for our Software University online series :The Role of the High Tech Product Manager.

Copyright (c) 2004, SoftwareCEO Inc. This article originally appeared at www.SoftwareCEO.com. Reprinted with permission.

Want more information on how to make your product management team successful? Attend a Pragmatic Institute course today.

Categories: Roles & Activities
Bruce Hadley

Bruce Hadley

A veteran of three startups, SoftwareCEO Inc. founder Bruce Hadley spent 20 years in software marketing, sales, and operations. One of those companies went public, and the other two were sold to much larger software firms. Before founding SoftwareCEO, an online resource for software executives and entrepreneurs, he was editor of one of the industry’s leading news and research publications.

Looking for the latest in product and data science? Get our articles, webinars and podcasts.