The case for Product Management - random Learnings from 33 years in the Job

Product Management is never a large function in a company, but it has a great view

Contents

1. Introduction

2. Key skills needed in Product Management 

3. Typical Responsibilities & Tasks 

4. Why have Product Management (and common misconceptions)?

5. Interworking with other Organisations

6. Product Management and Agile/Product Owners

7. Summary for successful Product Management

1. Introduction

I’ve had Product Management roles in 10 companies, across 4 Countries, in the Telecom, Media and Automotive industries. These roles have been split equally between B2C and B2B businesses, and with Products having one Customer, to hundreds of Customers. Over these 33 years we’ve designed, developed, launched and operated some successful Products. But probably had more failures, hopefully learning from these. 

Product Management is a key role in any organisation, with a high number of internal interfaces. If the Product Management function is well-executed, it contributes to making life easier and clearer for other units, and therefore the company as a whole. 

In this article I’ll try to explain experiences and learning along the way, and why I believe Product Management can help. This applies even more so in today’s complex environments, and where the solution to many challenges is to apply Agile and deploy Product Owners. Product Management is significantly broader than the Product Owner role and focusses on why and what to develop, to get the right products, rather than how they are developed.  

These are personal views and opinions only. And it can be difficult to generalise on such topics, as every company situation is different. With Product Management at the heart of complex organisations, a huge number of configurations and realisations are possible. References to companies will usually mean something beyond the 3-person start-up. And normally a company developing and supporting Products, rather than Services – though this distinction is rapidly disappearing as Products are packaged as Services in new business models.  

2. Key skills needed in Product Management

• Have an ability to persuade & influence others without the formal authority. Product Management has never been about having lots of people to command and manage, rather it comprises a few experts who need to convince others to go along with their thinking. It is about openly presenting product information in such a way that colleagues come to the same conclusion as you have, even when they may have different initial perspectives. It’s about working through other people. 

you simply have to believe me

• Be as factual and data-driven as possible. Although the role has a (Product) Marketing element externally towards customers, internally it should be done straight and with minimal marketing and selling to your own colleagues. Show them everything, and then explain your thinking and why it leads to specific conclusions on the products and their associated messages. 
• The first priority of Product Management is to have a Business perspective, which means being Customer-centric also. Have a constant and intuitive feel and voice for overall product costs against revenues of any solutions, products or features. This is the point of Product Management. Do not avoid business discussions and customer feedback around your products because you are more comfortable in technical areas.  
• However, Product Management must also retain its Technical edge. Having a degree of technical knowledge and competence is an essential element of the job. Whilst it may not be as deep as those working in Development, in should always be present. In these days of Customer Journeys and Use Cases - both essentially a license for everyone and the office dog to hold an opinion on product requirements and priorities - knowing deeply the solutions and their trade-offs, is an essential competence.   
• Be fully aware of the issues around any Product Management reporting line. I would not recommend having it organized under any development/CTO organisation, as it ends up being too technical and lacking independence. Under Marketing also, it creates a fictional bias that Product Management should avoid in favour of more solid facts and data. Under Sales … well, it simply can’t be under Sales. Product Management is optimally organised as a unit reporting to the CEO, if getting the Products or Services right is deemed important enough to company success.

3. Typical Responsibilities & Tasks of Product Management

A broad Product Management scope runs from Commercial to Technical areas

In any discussion on Product Management responsibilities it can be debated where the lines are drawn with respect to adjacent organizations. I’ll attempt to show the maximum scope of a company Product Management function, but the configurations are endless.   

On the commercial side Product Management can be fully responsible for Pricing & Packaging. Knowing what the products cost to develop, launch and support, hopefully the pricing and market estimations can recoup these costs, and then some. Having a Pricing function run by those not fully understanding the product, can be a risky business.

Business Cases are the last refuge of the uninformed. They are a misused tool in many companies. The thinking behind any Business Cases does have value, particularly detailing the assumptions made, but as used today many exist to simply tick a box, and are easily manipulated by (Product Management) experts. Taking decisions because a box in an Excel spreadsheet has a certain number in it, is not recommended. This number is often based on debatable inputs and assumptions, that are quickly forgotten about and not debated, in the desire to see a number that is good, or bad, or at very least, clear.

Product Managers should invest heavily in supplying excellent Sales Collateral and Product Marketing output. Investments there are efficient and will help avoid over-selling and misunderstandings later. And greatly help your overall relationship with Sales. 

Go-To-Market Plans or Product Launch Plans should be a part of the process of managing a product and making it successful. It may require more Project management skills than normal, but is essentially making sure everything and everyone is ready for the launch and knows how this will be done, and when. 

Competitor Analysis is a classic Product Management responsibility and deliverable, and in the old days meant the creation of a document that hardly anyone read. It is important to always be aware of the Competition and what they are doing, but not to an obsessive degree. And there is no shame in borrowing ideas from others products as an input.

Product Roadmaps, the outcome of having a Product Vision & Strategy, are a difficult topic. I have seen 2 extreme situations. One had roadmaps generated only as required and barely referenced, in a constantly changing environment, but where there was a comprehensive core product in service. In the other case the 3-year roadmap was sacred, with long development cycles and products partly driven by standardization. This meant we needed early decisions on which new technologies and vendors to incorporate. Our customers had similar, or longer, planning horizons then we did. Roadmaps are a tool of Product Management and should be flexibly used as such.

Business and Sales will tend to want it all 

Product Evangelism sounds a bit general, but every product needs a champion and it should be from Product Management. It requires a healthy knowledge of the market and customers, and an ability to stand up on stage and be credible when talking about where they are both heading - before even adding your Product to the mix. Everyone in the company should appreciate your product advantages and benefits, and you should keep a positive and open newsflow going, without descending into Marketing baloney. The alternative is hearing endless complaints and moaning about your product, creating a downward spiral that makes it difficult to sell externally.

Requirements Management is a core function of product management, with customer input and feedback forming the best base. This is then processed with other inputs and directed at own development organizations (e.g. in a product company), or external vendors (e.g. for a Services company, or an integration), depending on the nature of the company business, or the result of a build-or-buy decision. Requirements include those around the user interface and user experience, because these elements are inseperable from the Product as a whole. Product Management should articulate clearly what the requirements are, and then always follow-up, to ensure that they are delivered against. This can be either daily (e.g. Agile), or at appropriate points in any development or integration project.

Management should usually not be left alone and unattended with major Product Decisions. I have seen far too many poor-to-disastrous product decisions taken in these limited fora, and without the right knowledge levels and expertise being present. Enough for a book of Dilbert cartoons. Even if members of the management team invented the product themselves (e.g. as company founders), it still needs the structure and independence of Product Management to fuse together necesary technical and business information. Product Management is very much about handling complexity and making situations clearer for all others to see. 

4. Why have Product Management (and common misconceptions)?

It’s a general rule that if someone has not experienced Product Management functioning in a company, they will likely not have a positive view of it, nor even understand why it is needed. This is natural and probably quite widespread, as many companies do not have fully functioning Product Management. We can always debate whether Product Management works or not, but it can really only work if given the opportunity - meaning that management empower suitably qualified Product Management experts to take responsibility for the company products. See what happens.     

What such a Product Management team can bring to a company, beyond executing all the functions discussed above, is a simplification of complex worlds, so that everyone else can understand them and participate. It can act as a means to bind an organisation together and ensure issues are not slipping between stools. And it is a force for securing that company methods and processes are based more on science, expertise, and data - usually better than relying only on opinions, luck or guesswork.

But there are still common attitudes to Product Management that may show a slight lack  understanding of what the function is all about, or why it is needed. Some of these views take the form of …

An argument can be made for such concepts, but ...

Consider yourself a mini-CEO

In my view this is going a bit too far and over-simplifies or distorts the situation, and can provoke organisational conflicts. The Sales team and others still don’t actually work for Product Management (nor should they), so Product Management will not really be getting CEO-level responsibility. One of those soundbites that may sound good, but is ultimately a bit meaningless.

We don't have Product Management, but a Product Owner instead

For some companies with less product development focus, this can make sense. With Agile being applied outside the framework of software development, and in environments without a history of Product Management (e.g. some Service businesses, Retail industry, Media & Advertising), a Product Owner role allows Agile work methods to be adopted. But Product Owners will not deliver on the Product Management scope, and it represents a very different role, albeit still part of a company Product Management function.  

We need a Product Manager - who do we have in the company that can do it?

The grabbing-the-nearest-person method, and their subsequent conversion into a Product Manager. Usually, and unsurprisingly, this simply doesn't work. Who trains them? Product Management is a specific skill and competence, and not everyone can do it. In the same way that not everyone can do Sales, or Marketing. Developers will likely not have the business skills, and Marketing/Sales people will not have the technical skills. You need a qualified  Product Manager, and often the only way to build them is on-the-job training and collecting varied product experiences.  

The customer is always right, and Product Management should just build what they request

The customer is important and their views should take priority, but there will always be other considerations that may mean you cannot deliver 100% to customer requirements. The real world is often not so simple, and customer requirements can be weird and illogical at times, as we are dealing with humans. Product companies usually have multiple customers that cannot all be 100% satisfied within finite development resources. Service companies may have a better chance of nailing what is generally perceived as a good service. The goal is getting your standard product good enough for most customers, while tolerating the costs & complexity of customised versions to satisfy specific other customers. This is the real skill and balancing act of Product Management.

Product Management is just the case of choosing the best features to develop

This is partly the role, but good Product Management can actually be more about being strong and clear on what not to build, about saying no to customer requirements, and being able to argue why, against predictably strong pressure from Sales and Management. This is often the case when winning a new customer, or a large deal, where product concessions may be needed.    

5. Product Management interworking with other Organizations

It may not always run smoothly

 I’m not suggesting there are always fights, but if there is not some tension and debate occasionally, then it may be that people do not care enough about your Products.

Sales and their Customers

Product Management must understand customer requirements, problems and priorities. It is far better to get such information directly from customers, rather than through an interpretation from Sales that will both lose information and add further biases. But this understanding should be collected via Sales and with Sales. And be wary of second-guessing customers, and assuming that they think exactly the same way as you do. Often they don’t. Humans, again.

Development

There will often be tension between Product Management and the Technical Organisation, and the stronger the Technical Organisation, the greater this tension. Therefore Product Management need to make friends here also, by communicating and explaining to them constantly, and by being present and available. And being aware that Product Management needs to recognize its own technical limitations - which is the same advice Product Management usually gives to Sales. The Development organisation is a good source of product ideas and this should be encouraged, though there is a need to avoid too many homers or unofficial projects. Most important is not to tell Development exactly how to develop something, and to give them space and flexibility to do their jobs. And watch out especially for the genius CTO types, who regularly offer business expertise as well as technical, and could possibly be in the wrong job.

Marketing

This can be a difficult relationship, partly due to Product Management often having an attitude that we’ll call expert scorn – a feeling that others such as Marketing don't understand the product well enough and operate on too high and fluffy a level. This is unfair and not recognising the broader role of Marketing sufficiently, and can lead to Product Management over-correcting any Marketing output, such as Press Releases and website content. Just don’t.   

6. Product Management  and Agile / Product Owners

In recent years we have seen the increasing adoption of Agile, first as a software development methodology, then extending into business processes, and then on to the transformation of companies as a whole. We should always be more agile. Indeed it is difficult to argue against agility, and for more … sluggishness. Many companies need to be transformed and disrupted, and agile mindsets and Agile methodologies are a good solution. There are obvious benefits in doing product development in an incremental and iterative manner, in shortening feedback cycles, and involving the customer more in these processes. 

The somewhat-less-than-Minimum Viable Product (MVP)

The Product Owner role comes from Scrum, a framework that helps teams to work together through learning from experience, self-organize while working on a task, and reflect on positives and negatives to improve continuously. The Product Owner role is on the operational and technical side of the Product Management spectrum, working in a tactical manner on the product backlog, detailed requirements, and frequent interactions with the development team. Product Owners are normally less active in areas like Strategy, Roadmap (backlog is a short-term subset), Pricing & Packaging, Business Cases, and further external and commercial Product Management duties.

Some of the problems that Agile addresses, could be mitigated to some extent if there was a functioning Product Management, in my view. These are typical product development issues - delayed products, poor quality, poor communication, high development costs, prioritisation of support v development, etc. As an example if the customer ends up with the wrong product, then an Agile solution would have the customer involved in the development, and an MVP approach adopted. But equally more experienced Product Management can also avoid wrong products, based on their knowledge of the Product, Market and Customer.

Unfortunately there is still some confusion today, on Product Owners and Product Managers and the terms are sometimes used interchangeably, which is helpful to neither role. They are not in competition and can co-exist. Depending on what needs to be fixed, a solution could be Agile, better Product Management, or some combination of both. With data-driven and AI-driven development increasing in future, there will anyway be more automation and autonomy in the development organisation, and therefore less input from Product Management required.   

Often the way Product Management is described by Agile followers, associates it with traditional development methodologies such as waterfall. I don’t see Product Management as being tied to a specific development methodology, product, or even culture. It can vary depending on which development process is used, but the fundamentals of the role are methodology-independent. Product Management remains focussed on getting the Product right through a deep understanding of its environment, and managing its life-cycle in the broadest sense.   

7. Summary for successful Product Management

• Be honest and be independent. The role owes it to the Product - and the Company.
• It's all about Communication. Publish your thinking and plans continuously. There are many modern tools to help do this. Do not create confusion, or encourage hidden agendas and rumors. Product Management is all about shining a torch into dark areas ….. 

The role is about clear communication, which is not always easy

• It's a complex role in the middle of many processes, so learn to filter out the important information from what can be considered noise, as early as possible. And watch out for others dumping random work on you, because they say it is ‘related to the Product’.
• You need friends in the company for Product Management to work, and an ability to persuade and influence people without any formal managerial power to help you.
• Be magnanimous. It is too easy for domain experts to develop a slight arrogance, as they have the best knowledge in a particular area. But we should accept there is no absolute right and wrong, just degrees and shades of grey. Do not discourage input and feedback on your product by appearing to know it all already.

In conclusion I am not saying Product Management in any company can, or should, do everything described here. In many companies Product Management has more limited responsibilities, often (rightly) dictated by the existing team members competence, knowledge and experience.

However, when it is appropriately staffed, organised and empowered, Product Management can handle all of the role described here. Product Management is primarily about people applying their skills, experience and clarity to Products, no matter what the product is, or how it is developed. By occupying a central role in a company, Product Management can be the solution to many of the product challenges encountered in modern Tech environments, heading off and fixing issues before they arise. Or before a complete Agile transformation and some serious surgery is needed. It should be given a chance.

About the Author

Hello there. I’ve been working in Product Management for some time in different countries and industries. This has enabled me to try and understand these regularly changing products, and domains such as: Mobility, Cellular/Wireless, Location & Maps, Automotive ADAS, Mobile Advertising, Personal Data & GDPR, and more. But while the products and domains have always changed, the Product Management role has not, allowing me to port any learnt skills and experiences from product to product, industry to industry, country to country. This is what the above article is really about, the constants of Product Management, that you will usually find no matter what product or industry you are working in.

John Craig, Munich, November 2019.    

References

Very much go along with these insights from Siraj Khaliq, Investment Partner at Atomico.

https://medium.com/atomico/europes-product-management-problem-9061bc71dc99

A useful perspective from Roman Pichler on Product Owners and Product Managers

https://dzone.com/articles/product-manager-vs-product-owner

Cannot disagree with most of these points

https://www.feedough.com/top-13-myths-product-management/

Another viewpoint from Glen

https://www.glenevis.com/Glenevis/Product_Management