Product managers - who needs them (and are they overpaid)?

Replies to This Discussion

Permalink Reply by PCSpectra on November 13, 2008 at 3:44am

Is software product management somehow different or could a product manager from another domain (e.g. breakfast cereals) take it on?

In an ideal world product managers would be both, which implies the impossible.

Developers who have the gift of the gab are usually the ones who quickly accelerate into management postions. They have little experience in 'design' and are only concerned with 'development' because features sell the product, not the stable architecture. On the flip side, a horrible software package will result in frustrated customers who constantly seek alternative solutions.

As a software architect, I always advocate that design comes first. If physical buildings were developed like software, they would topple in the first gust of wind. It's ironic that "Windows" is the name of the operating system for something so fragile. :P Stupid joke sorry.

Anyway, it's frustrating beyond all belief as a passionate developer who is genuinely concerned of his overall product, when a manager tells him to "just get it done" or "do it this way -- it's easy I've done a hundred times before" when they haven't th slightest clue as to what a front controller is or any design pattern or object oriented best practice for that matter.

Yes, I could "hack" that feature onto the product but it begins to loko like WordPress at the source code level and all your best developers will leave your company to find higher quality software elsewhere. I have yet to find a company that shares my zeal, which is why I started my own.

That being said, when I do finally release my email marketing software and assuming it generates enough revenue to require my hiring an additional developer, I will assume the role of "software architect" over seeing rhe entire design of every system and ensuring the best performance through simlicity, as well as addressing security, architecturual concerns, etc.

I would consider a product manager someone with more 'sales' savvy than myself but in no way senior or capable of dictating what features *must* be in the next release. As the architect I know what features are best suited for my application and which are best left to a separate product (ever notice how software is bloated because it tries to please everyone?). It is also assumed, that I know what is best for the product end users as well. If you follow a user feature development process what you end up with are monolithic applications that solve every problem under the sun and are full of holes, security exploits, bugs and over engineered, complex interfaces.

In some organizations I suppose a product manager would be someone who can motivate a team, which is a skill onto it's own. Motivating design conscienous developers though, without some background in design is next to impossible, as you will likely only irritate them with requests/suggestions/etc.

I would say the architect and product manager would work in paralell as understanding your users requirements is impetus to a software projects success, but blindly implementing every feature as a senior developer because your product manager tells you to, is just foolish and naive.

Cheers,
Alex

▶ Reply to This

Permalink Reply by John E. Abram on November 13, 2008 at 1:15pm

Hi Mark

In my opinion – Product Management is a Science. Taking your ‘physical buildings example’ as a means to support my response; here goes! One of the key roles of the PM is to answer the question “why do we need a building?” “who will be its primary users?”. Developing a detailed understanding of the commercial environment within which the building shall operate is a scientific one. There are a bunch of tools and techniques a product manager can use to find answers to these questions. Once these NEEDS have been described in sufficient detail the PM is ready to enter into a discussion with the engineering team as to the best way to create, adopt or acquire a suitable solution.

How to differentiate between a good and bad PM! – asking the PM a bunch of specific questions about their offering will give an insight into their competency. A PM worth anything will be able to describe very quickly the findings from their SWOT analysis, the 4Ps and describe both external and internal commercial and technical Inferences.

Cheers
John
www.monetical.com

▶ Reply to This

Permalink Reply by Colin Millerchip on November 13, 2008 at 3:01pm

Crikey, where to start?! You're asking some pretty fundamental questions, but I'll try to avoid writing a book in reply:


> How is it done in their organisations, if at all?
The role of a product manager gets interpreted in two broad ways: as "the messenger of the market", and as "the CEO of the product". To expand a bit:

• "the messenger of the market" means that they bring a view into the company that's based on discussion with customers and prospects, and other market data; and this view helps in making decisions about products, eg, "what product should we build?", "how much should we sell it for?", "can we compete?".
• "the CEO of the product" means that they carry the P&L responsibility for the product. This therefore requires a whole bunch of activities, including being the messenger of the market, but also managing financial performance (some companies will find this too broad a purview for their tastes).

The first of these two is essential for a product manager to be adding value. If they don't have a view from the market, then a product manager is just another person trying to make decisions.


Pretty much all organisations are doing some parts of product management, even if they haven't encapsulated them within a role -- for eg, every software company needs to decide what new product or product release to do next. You can make such decisions without having anyone act as the messenger of the market -- such organisations are often termed "short-lived companies" :-/


In smaller companies, these activities are usually done by the founders and early staff: they're typically very closely involved with the market, both in terms of contact with current customers and lost opportunities. So they get lots of input from the market, and hence have a reasonable chance at building something that the market will value, and will pay for.


> When do organisations need one or more 'product managers'? What are the signs they should look for to tell them they do?
As a company grows, the people who were doing these product management activities find that they're becoming a secondary (and neglected) aspect of their day jobs. They get more and more involved in internal issues -- eg, managing projects and people, evolving business processes, etc. As such, their available time to talk to customers and prospects gets squeezed. At this point, they've got a few options:

• keep making product management decisions, despite the lack of input from the outside world. It's a risky strategy, but many companies do this (ref. "short-lived companies").
• work through proxies, the people who do still talk to customers -- eg, sales, support, some people within marketing. Your chances of getting a fair view of your marketplace and customers through these proxies is pretty slim.
• hire someone to take on the role from them. It's time to cut the umbilical, and many CEOs of growing companies struggle to do this.

So rather than put a number here (eg, 50+ staff... oops, just put a number here!), it's more an aspect of focus: when the people who have been doing the product management activities find themselves focussing more and more on other issues, and not on the market and their customers / prospects, then you need someone to take on the role of product management as the mainstay of their job.


> Is product management an art or a science? (or are good product managers simply lucky?)
It's both an art and a science... but you knew I was going to say that, right?!

There are some aspects that are pretty 'scientific' -- eg, statistical analysis of survey results; financial modelling (NPV, scenario modelling, Monte-Carlo simulation); repeated methodology to allow for comparison between project options; etc. Some aspects are definitely an 'art' -- eg, actually 'hearing' what a customer is trying to tell you, even though they might not be saying it; having an instinct for where the money is (eg, when will people pay for a solution to a problem, rather than just grin and bear it?).

I think your reference to being lucky, doesn't quite get to the heart of things. Luck is clearly an aspect of any business venture; but if you have someone bringing a view from the market inside the organisation, your chances of being successful are higher than if you don't.


> What makes a good (or bad) product manager?
The traits of good product managers include...

• passionate -- with all the impediments you face in getting products to market, you're never going to get anywhere unless you have passion. Same goes for project managers.
• lateral thinkers -- they must identify all the key issues (big or small) upon which a project might flounder, and address them all.
• relish customer contact -- and they need to be empathetic with customers.
• good communicators (both listening and articulating).
• diplomatic -- you need to convince people of your vision, without having the authority of line management.
• ability to synthesise large amounts of data.
• domain knowledge is a useful addition (see below).
• ... yada yada yada...

> Is software product management somehow different or could a product manager from another domain (e.g. breakfast cereals) take it on?
I've personal experience of moving between domains within software product management (both in terms of technology domains, and market types), so I'm confident this can happen. If you filter possible candidates based on whether or not they have domain knowledge, and on whether they have product management experience, you'll be picking from a small pool indeed.

Look for the traits I reference above, and if possible look for a track-record of being able to handle such domain jumps.

Test them out: as part of the selection process, ask them to show their approach to researching an area they have no knowledge of, and see how they go about it. But be sure to judge their method, not whether they reach the same conclusion as you -- assuming they're only spending limited time on this, then you can't expect an exhaustive trawl of the market data. Plus they'll be working in a vacuum (without input from others in your company), and probably based on secondary market data (rather than on customer research). If the method looks sound, the recommendation looks plausible (based on their data), and if they identify the limitations in their research (ie, if they recognise the importance of customer research), then there's a decent chance they can jump domains.

Obviously, the bigger the jump, the bigger the risk. But the flip-side, is that if they're jumping from a radically different domain, perhaps they'll bring in new thinking that can be applied to your domain. For eg, your breakfast cereal product manager will know how to manage FMCGs -- could any of these techniques be applied to your business environment?


> What are the key success factors and things to avoid?
This list could go on and on, but here are some opening thoughts:

Key success factors:

• The "CEO of the product" approach suggests that P&L is a good measure, and indeed it can be.
• In addition to P&L, there are various KPIs you could apply, in terms of your sales process -- eg, deals won, conversion rate, customer support statistics.
• But you might measure on other shorter-term issues, like generating a pipeline of well research product ideas. If you want your product managers to be "messengers of the market", then this may be a better measure (eg, a certain volume of research done, to a specified quality).

I'm cautious of the law of unintended consequences, when putting measures in place. For eg, a focus on P&L may be inappropriate for a v1 product, for which the goal is market share. YMMV.

Things to avoid:

• Don't have a hard hand-over from the product manager to the project manager.
  • The market requirements shouldn't be a "cast in stone" document handed Moses-like down the mountain from the product manager to the project manager.
  • Get your development team involved in customer research. This helps ensure the market requirements have some feasibility checks early on; it also means they better understand the customer (when designing the UI & workflows); and it helps them during the development phase, to judge the sort of changes they can make without missing the aim of the project.
  • Keep the product manager actively involved in the project specification phase. Then, keep them involved (in a light touch way) during the project, so that there's no "what's that?!" moment at the end when the project is unveiled.
• Don't combine the roles of product and project management (sorry if you were hoping this would be a fix to the first issue!). All that will happen is that the project mgt work will squeeze out the product mgt work.
• Look for people who would fit into the company. The world's most experienced product manager, with bags of gravitas from interacting with the CTOs of Fortune 500 companies, may not connect with your team of new graduates.

▶ Reply to This

Permalink Reply by Mark Dalgarno on November 23, 2008 at 9:19pm

John E. Abram said:

Hi Mark

In my opinion – Product Management is a Science. Taking your ‘physical buildings example’ as a means to support my response; here goes! One of the key roles of the PM is to answer the question “why do we need a building?” “who will be its primary users?”. Developing a detailed understanding of the commercial environment within which the building shall operate is a scientific one. There are a bunch of tools and techniques a product manager can use to find answers to these questions. Once these NEEDS have been described in sufficient detail the PM is ready to enter into a discussion with the engineering team as to the best way to create, adopt or acquire a suitable solution.

How to differentiate between a good and bad PM! – asking the PM a bunch of specific questions about their offering will give an insight into their competency. A PM worth anything will be able to describe very quickly the findings from their SWOT analysis, the 4Ps and describe both external and internal commercial and technical Inferences.

Cheers
John
www.monetical.com

John,

Thanks for your reply.

I also view it is a science but have seen little evidence that it's tackled this way in our industry. I have met product managers who were previously users of the software they were managing. They were very good at articulating end-user requirements but I feel their lack of formal marketing experience made it hard for them to place a value on these requirements. Consequences here included time wasted developing features that few people used. Also, while these people did have a very strong empathy with the user base they generally didn't understand their competitors' products and so their products were vulnerable to being replaced.

Mark

▶ Reply to This

Permalink Reply by Mark Dalgarno on November 26, 2008 at 6:18pm

PCSpectra said:

Is software product management somehow different or could a product manager from another domain (e.g. breakfast cereals) take it on?

Anyway, it's frustrating beyond all belief as a passionate developer who is genuinely concerned of his overall product, when a manager tells him to "just get it done" or "do it this way -- it's easy I've done a hundred times before" when they haven't th slightest clue as to what a front controller is or any design pattern or object oriented best practice for that matter.

Yes, I could "hack" that feature onto the product but it begins to loko like WordPress at the source code level and all your best developers will leave your company to find higher quality software elsewhere. I have yet to find a company that shares my zeal, which is why I started my own.

Yes, I hear you. It can be a problem when an architect has been working on a product for many years, has a good sense and vison of what it does and is then asked to do something that doesn't fit into this vision. I guess this can be particulary bad if there's a lot of turnover in Product Management but less in product development or if the compant as a whole doesn't have a strong sense of direction.

PCSpectra said:

I would consider a product manager someone with more 'sales' savvy than myself but in no way senior or capable of dictating what features *must* be in the next release. As the architect I know what features are best suited for my application and which are best left to a separate product (ever notice how software is bloated because it tries to please everyone?). It is also assumed, that I know what is best for the product end users as well. If you follow a user feature development process what you end up with are monolithic applications that solve every problem under the sun and are full of holes, security exploits, bugs and over engineered, complex interfaces.

In some organizations I suppose a product manager would be someone who can motivate a team, which is a skill onto it's own. Motivating design conscienous developers though, without some background in design is next to impossible, as you will likely only irritate them with requests/suggestions/etc.

I would say the architect and product manager would work in paralell as understanding your users requirements is impetus to a software projects success, but blindly implementing every feature as a senior developer because your product manager tells you to, is just foolish and naive.

Cheers,
Alex

I think it's essential that the product manager understands the value of particular product features, products and product portfolios. This doesn't take place in isolation - the PM has to get out there and speak to customers & collaborators and understand what their competitors are doing. John mentioned some of the standard approaches for doing this such as the 4Ps and SWOT analysis and there are many more but I wonder how many product managers know about these techniques when they are first given the role.

▶ Reply to This

Permalink Reply by Mark Dalgarno on November 26, 2008 at 7:27pm

Colin Millerchip said:

Crikey, where to start?! You're asking some pretty fundamental questions, but I'll try to avoid writing a book in reply:

Not quite a book Colin but the beginnings of a small pamphlet :-)

Colin Millerchip said:

When do organisations need one or more 'product managers'? What are the signs they should look for to tell them they do?
As a company grows, the people who were doing these product management activities find that they're becoming a secondary (and neglected) aspect of their day jobs. ... At this point, they've got a few options:

• hire someone to take on the role from them. It's time to cut the umbilical, and many CEOs of growing companies struggle to do this.

Yes, I've seen this many times. A similar problem exists for other roles too e.g. the CEO who developed v1 of the product and now can't step back to run the company. (I will no doubt be guilty of this when we reach a similar size :-))

Is product management an art or a science? (or are good product managers simply lucky?)
It's both an art and a science... but you knew I was going to say that, right?!

Sure, in my experience product management is both a creative and analytical process. Sometimes it does help to be lucky though, or rather as you note below to make your own luck by coming to a deep understanding of the marketplace.

There are some aspects that are pretty 'scientific' -- eg, statistical analysis of survey results; financial modelling (NPV, scenario modelling, Monte-Carlo simulation); repeated methodology to allow for comparison between project options; etc. Some aspects are definitely an 'art' -- eg, actually 'hearing' what a customer is trying to tell you, even though they might not be saying it; having an instinct for where the money is (eg, when will people pay for a solution to a problem, rather than just grin and bear it?).

I think your reference to being lucky, doesn't quite get to the heart of things. Luck is clearly an aspect of any business venture; but if you have someone bringing a view from the market inside the organisation, your chances of being successful are higher than if you don't.

> What are the key success factors and things to avoid?
This list could go on and on, but here are some opening thoughts:

Key success factors:

• The "CEO of the product" approach suggests that P&L is a good measure, and indeed it can be.
• In addition to P&L, there are various KPIs you could apply, in terms of your sales process -- eg, deals won, conversion rate, customer support statistics.
• But you might measure on other shorter-term issues, like generating a pipeline of well research product ideas. If you want your product managers to be "messengers of the market", then this may be a better measure (eg, a certain volume of research done, to a specified quality).

I'm cautious of the law of unintended consequences, when putting measures in place. For eg, a focus on P&L may be inappropriate for a v1 product, for which the goal is market share. YMMV.

I like your idea of measuring the quantity and quality of product ideas. How in practice is this tempered by realities on the ground i.e. the capacity of the organisation to deliver these ideas and the potential for the organisation to grow into new areas?

▶ Reply to This

Permalink Reply by Marielle Sanna on December 3, 2008 at 12:05am

Hi Mark,
I am currently enrolled in a Software Product Management certificate program at the University of Washington, USA. As a student, my understanding of the role and the value of a good Product Manager are the following:
- understand the customer problem (use market research if necessary)
- offer a value proposition to that problem and differentiate yourself from your competitors
- target to a reachable market segment
- Reach out for the early adopters of your technology and define a strategy and tactics to reach for the mainstream market
- Collect business requirements. Product Management is not about design. It's about the overall solution (from the software, to hardware, partners, training, support etc ...) It is about business scenario. keep in mind the original value message.
- Define a Go To Market/ Launch strategy
- Helps define the business model. How are you going to make money.

I would say (eh, I am just a student), if the company cannot answer my list above, they might need a Product manager.
I do know that not all company have a Product manager and would be happy to know when they need one.
Cheers.

▶ Reply to This

Permalink Reply by Giles Thomas on December 4, 2008 at 7:17pm

@Colin Millerchip - great post!

I've recently been playing with using Google AdWords as an aid to product management - create an ad for each feature area, and then see what gets the most clicks. The results can be a factor when deciding where to concentrate development effort. Some interesting - and, for me, counter-intuitive - results so far, though I don't know how useful it will be in the long term. I guess that's something more on the "science", rather than "art" side.

Is using AdWords this way something other people have more experience with?

▶ Reply to This

Permalink Reply by David Locke on December 7, 2008 at 2:26am

Giles Thomas said:

@Colin Millerchip - great post!

I've recently been playing with using Google AdWords as an aid to product management - create an ad for each feature area, and then see what gets the most clicks. The results can be a factor when deciding where to concentrate development effort. Some interesting - and, for me, counter-intuitive - results so far, though I don't know how useful it will be in the long term. I guess that's something more on the "science", rather than "art" side.

Is using AdWords this way something other people have more experience with?

Using AdWords is something that can be done with any and all market messaging, so talk to your marcom people. Marketing will have the experience in this area.

You can use it at the level of the inbound concepts long before they get into your product. You can use them to develop your conceptualization and differentiation. You can use them to preflight your terminology, which would include what you call a specific function. You can use them to select labels in your interface.

A/B test all the alternatives. Use Google's keyword research tools as well. They be be used for competitive intelligence as well. If you have a trademarked term that you haven't published yet, when you do publish it, you can watch the searches for it. Your fast followers will be searching for your terms.

▶ Reply to This

Permalink Reply by Paco on December 8, 2008 at 5:52pm

I've been a software PM for over a decade at multiple companies. And my background includes an EECS degree from MIT.

1. How is it done? Keys to success?

Seen PMs organized all over - under product exec (CEO/VP/GM), under mktg, under dev. Having PM org report directly to product exec mgmt works the best. Why? PMs under mktg can be vetoed by mktg upper mgmt. PMs under dev can be vetoed by dev upper mgmt. PMs gotta call the shots as they see them and not simply try to make mktg or dev happy.

Keys to success are simple - competence and authority. Hire competent PMs. Make sure management recognizes their authority over the product roadmap.

You can be a successful PM even without those two "keys", but it requires more work and more professional risk.

2. When do you need more than one PM?

Always helps to have more than one. I've never met a good PM who was completely caught up on all their demands and had free time. Good PMs help close sales deals, help shape mktg comms, meet with important customers, review features with dev and qa, provide training for sales/consulting/support staff, not to mention that they have to author and maintain a lot of documents and stores of knowledge.

The best PM team I served on was just that - a team. We peaked at 8 people across three continents, and we reported through the Director of PM to the product VP.

3. PM - art or science?

Both.

You need the creativity and people-skills to deal with all the outbound responsibilities.

You need the logical, analytical, and technical skills to deal with all the inbound responsibilities and be the product expert.

4. Is software PM different from other PM domains?

Yes.

Product Managers for other industries are more likely to have P/L responsibility. They are also more likely to have a much more well-defined role and authority.

For example, the PM for a consumer goods company like Proctor & Gamble. That PM literally owns a product or product line: they make the business case, call the important shots, and their head will roll if the product fails. Also, they work in a much more regulated/standardized industry. For software PMs, that sounds like heaven :)

For a software PM, you're lucky if you have any official authority. However, you're almost always going to take some or all the blame for product failures. You're also in an industry with minimal standards or regulations. Every software engineer has their 2-cents about code languages, platforms, methodologies, and their own evaluation of how good they are. Numerous studies have proven the oft-cited 10x difference in effectiveness of software "engineers" of the same title and seniority. You gotta be ready to work with anyone along that spectrum of opinions and skill-level, and somehow make sure a good product is delivered.

Another perspective - software PM courses have only started to show-up at major universities within about the last 10 years. Industrial/consumer goods product management has been around in business schools for at least the last century.

5. Are they overpaid? (you asked in your title)

For good ones, hell no. And it always surprises me that people think PMs have cushy jobs where they're paid lots of money to call the shots from their own personal opinions.

For good PMs, that's so far from reality :) We typically make much less than our same-level counterparts in engineering. We may make the same as our same-level counterparts in marketing (because too many people think we're essentially marketing goons). We sure as hell don't make as much as sales or sales consultants make.

When I've mentored new PMs who came from sales, consulting or engineering, they all have the same reactions:

1. This is a lot harder than I thought.
2. I can't believe you guys ever get anything done.
3. You really should get paid more :)

▶ Reply to This

Permalink Reply by LisaG on December 8, 2008 at 10:43pm

PCSpectra,

I was shocked by your lack of insight into what a product manager does. The PdM is the bridge between the customer (aka industry, user) and the developers (including architects). The PdM helps determine what the gaps are in the software and then determines what the priorities are for addressing them. In addition, having a pulse on the industry and competitors (which a developer/architect does not usually monitor) means that the evolution of the product will be done in a manner that allows your to be in front of your competitors, not behind it.

To Mark Delgarno: you'll know your software needs a product manager when you are losing sales and if you are letting your developers dictate the features, functionality and strategy long term.
PCSpectra said:

Is software product management somehow different or could a product manager from another domain (e.g. breakfast cereals) take it on?

In an ideal world product managers would be both, which implies the impossible.

Developers who have the gift of the gab are usually the ones who quickly accelerate into management postions. They have little experience in 'design' and are only concerned with 'development' because features sell the product, not the stable architecture. On the flip side, a horrible software package will result in frustrated customers who constantly seek alternative solutions.

As a software architect, I always advocate that design comes first. If physical buildings were developed like software, they would topple in the first gust of wind. It's ironic that "Windows" is the name of the operating system for something so fragile. :P Stupid joke sorry.

Anyway, it's frustrating beyond all belief as a passionate developer who is genuinely concerned of his overall product, when a manager tells him to "just get it done" or "do it this way -- it's easy I've done a hundred times before" when they haven't th slightest clue as to what a front controller is or any design pattern or object oriented best practice for that matter.

Yes, I could "hack" that feature onto the product but it begins to loko like WordPress at the source code level and all your best developers will leave your company to find higher quality software elsewhere. I have yet to find a company that shares my zeal, which is why I started my own.

That being said, when I do finally release my email marketing software and assuming it generates enough revenue to require my hiring an additional developer, I will assume the role of "software architect" over seeing rhe entire design of every system and ensuring the best performance through simlicity, as well as addressing security, architecturual concerns, etc.

I would consider a product manager someone with more 'sales' savvy than myself but in no way senior or capable of dictating what features *must* be in the next release. As the architect I know what features are best suited for my application and which are best left to a separate product (ever notice how software is bloated because it tries to please everyone?). It is also assumed, that I know what is best for the product end users as well. If you follow a user feature development process what you end up with are monolithic applications that solve every problem under the sun and are full of holes, security exploits, bugs and over engineered, complex interfaces.

In some organizations I suppose a product manager would be someone who can motivate a team, which is a skill onto it's own. Motivating design conscienous developers though, without some background in design is next to impossible, as you will likely only irritate them with requests/suggestions/etc.

I would say the architect and product manager would work in paralell as understanding your users requirements is impetus to a software projects success, but blindly implementing every feature as a senior developer because your product manager tells you to, is just foolish and naive.

Cheers,
Alex

▶ Reply to This