Coaching Tools – The Plan
In my previous article, I defined how I encourage managers of product managers to assess the current skill level of a product manager in order to identify skill gaps. In this sequel to that article, I would like to share how I coach product managers on each of these specific gaps.
In truth, if this were truly fleshed out it would amount to several hundred pages, but I am hopeful that I can provide enough examples and suggestions in here to help most managers give useful guidance and coaching.
Note that I am using the same people, process and product taxonomy of skills that I spelled out in the assessment article, so if you are unsure what any of these topics are about, please refer back to that article.
To set your expectations, product knowledge is where a new product manager spends most of her time in the onboarding process. It usually requires 2-3 months of time to ramp up, assuming she is being provided the necessary coaching, and she is aggressively focusing on this for several hours per day.
But to be clear, a product manager that does not have this level of knowledge has no business serving as product manager for her team. And the responsibility for ensuring this level of competence is squarely on her manager.
User and Customer Knowledge
There really is no substitute for getting out of the office and visiting users and customers. That said, there is much to be gained by first taking advantage of the knowledge of your colleagues.
As you go about this learning, remember that each person you speak with brings their own perspective, and you’re looking to understand that perspective, and learn as many perspectives as possible.
If your company has a user research team, that’s my favorite place to start, and is a valuable relationship for the product manager. The user researchers are there to educate you, because they know if you don’t truly grok the issues, then you won’t fix them.
Next, if you have a customer success or customer service team, that is a terrific resource. You want to learn who their favorite customers are, and their least favorite, and why. You will also be spending quality time with this team to understand more about how customers perceive your product, but for now, we want to learn what they can teach us about our users and customers.
Product marketing is another valuable perspective on our users and customers, and another important relationship for the product manager. Product marketing will also have good insight into the broader sales and marketing organizations and the people you should talk to that will have useful perspectives.
In many companies, the founders or the CEO has had more customer exposure than anyone, and that’s another great resource. Ask the founders which customers they consider the most helpful for you to truly get to know and understand. You’re not only looking for happy customers, just as you’re not only looking for unhappy. You’re after as many perspectives as you can get.
At this point, you’re ready to go out there and meet real users and customers. To set your expectations, when I first took responsibility for a new B2B product, my manager wanted me to visit 30 customers (and further, he insisted that half be from outside the US), before making any meaningful decisions. I don’t think that number 30 is special, but I can tell you it’s not two or three. I typically recommend at least 15 customer visits as part of new PM onboarding.
I do know that when I returned from that trip, I had progressed from knowing virtually nothing, to knowing as much as anyone in our organization, and I leveraged what I learned, and the people I met and the relationships I established, for years.
Once you’re actually sitting down with users and customers, a whole other topic is the techniques we use to learn, but that’s the discovery techniques topic. I can tell you here that with every interaction, at the very least, you’re looking to learn: Are the customers who you think they are? Do they have the problems you think they have? How do they solve that problem today? What would it take to get them to switch?
Note that there are some obvious differences between customers that are businesses versus consumers, but the principle is the same.
Note also that if you are joining an existing team with a skilled product designer and tech lead, then you absolutely want to learn as much from them as possible, and if you’re joining a new team, then you want to include these two people with you during your learning.
There are generally three types of data and tools that the new product manager will need to achieve competence on. There is typically one tool that contains the data about how users actually interact with our product – user analytics. Another tool typically contains data about the sales cycle for our product – sales analytics. And a third typically shows how this data is changing over time – data warehouse analytics.
Realize that achieving competence for each of these tools means two things. First, that you know how to answer questions with that tool; you’re learning how to operate the tool. Second, you need to understand what the data in the tool is trying to tell you.
Your go-to resource for coming up to speed on the data (tool operation and data semantics) is usually one of the company’s data analysts. This is another key relationship for the new product manager. But to be clear, they are not there for you to delegate to them. They are there to educate and empower you to answer questions with data.
This topic is intertwined with the topic below about understanding your business. Every product has a set of KPI’s that collectively describe your product’s health, and while the data tools will help you understand where you’re at, your business will dictate which KPI’s are the most important for you to focus on.
Industry and Domain Knowledge
In general, the product manager is expected to become competent on the domain. This is of course different for every product. Media products are different than developer products which are different from advertising technology. Fortunately, in most cases, there is a wealth of easily accessible knowledge just an Internet search away.
However, with certain products in very specialized domains (such as taxation, surgical devices, and regulatory compliance) there will usually be an in-house resource available to all of the product managers that is an acknowledged expert on the domain. These people are sometimes called subject matter experts or domain experts, but this person is another important relationship for the product manager to establish. The PM is not expected to become as knowledgeable about the domain as these experts, but she does need to learn enough that she can engage and collaborate effectively.
In terms of the broader industry knowledge, my favorite insider tip is to subscribe to Stratechery which provides relevant and timely analysis and insights into the broader tech industry.
Key to industry knowledge is to identify which industry trends are expected to be relevant to the PM’s product. The first step is to identify the trends, and then there may be some education needed to understand what the trend or technology enables, and what the capabilities and limitations may be.
Also included in industry knowledge is competitive analysis. Product marketing is a good resource to get started here, but the product manager will need to have a deeper understanding of the offerings, vision and strategy of each of the major players in the landscape.
When I coach product managers on competitive analysis, I like to ask the PM to evaluate the top 3-5 players in the space, and to write up a narrative comparing and contrasting the strengths and weaknesses of each player, and highlighting opportunities.
Business and Company Knowledge
For most new product managers, understanding how their own business works requires the largest amount of work. But this is often the essential difference between competent and capable product managers, and those that are not.
One way I like to get started on this is to have the new product manager fill out a business model canvas (any of the variants are fine for this) for their product. It is a quick and easy way of helping the product manager quickly realize the areas she may not yet understand.
Sales and Marketing – Go-To-Market
The go-to-market strategy is an essential aspect of every product. This describes how our product makes it into the hands of users and customers. This applies to every type of product from consumer to enterprise, but it’s usually most involved when selling to businesses. Your product may get sold through a direct sales force, or an indirect channel such as resellers, or directly to your customers.
The sales process starts with marketing, which itself has many different strategies and techniques. Ultimately there’s always some type of funnel starting with people becoming aware you exist, and hopefully proceeding through to the point where they are an active user and customer.
The new PM needs to understand the entire funnel from awareness to trials to onboarding. It’s especially important to understand the capabilities and limitations of the sales channel. Your colleagues in product marketing are normally your go-to resource for learning about your go-to-market strategy.
Finance – Revenue and Costs
It’s also essential for the new product manager to gain a deep understanding of the financials regarding her product. This involves both the revenue side as well as costs.
I’ve long advocated making a friend in finance for this purpose. There are a set of financial related KPI’s for every product, and you need to first understand what those KPI’s are (e.g. lifetime value of the customer), and what they mean (e.g. how is lifetime value calculated?). Finally, you need to learn where your product stands (e.g. is your lifetime value sufficient relevant to your cost to acquire new customers?)
I also very much like the book Lean Analytics to help the new PM learn more about which analytics are important to their type of product.
Legal – Privacy and Compliance
Another critical aspect to your business is legal. These issues mainly relate to privacy, security and compliance. As with finance, establishing a relationship with someone in legal that can help the new PM understand legal constraints is important not just in coming up to speed, but when considering new product ideas.
Business Development – Partnerships
Most products today involve some number of partnerships. It may be a technology partner that’s used to deliver your products or services, or it may be a sales or marketing partnership to acquire new customers.
Whatever the purpose, these agreements usually come along with constraints about what we can do, so it’s important for the product manager to understand these contracts and constraints.
Additional Areas (Editorial, Merchandising, Manufacturing, International)
The areas above are common to most every product, but it’s also true that many products usually have one or more additional areas, depending on the nature of the company.
Media companies have editorial/content; e-commerce companies have merchandising; hardware or device companies have manufacturing; and companies that sell globally have international, as just a few examples.
Product Operational Knowledge
This topic really should be obvious, but I can’t tell you how often I meet a product manager that doesn’t actually know their own product beyond how to give a basic demo. But hopefully it’s clear that a product manager must be an expert user of her own product in order to succeed.
For consumer products, it is not usually very hard to become expert on the product’s use, but for products for businesses, this can be much more difficult, especially when the product manager lacks the domain knowledge.
Coming up to speed on this typically involves reading whatever user or customer documentation exists, taking whatever training classes may exist, spending time with customer service staff, and if at all possible, using your own products on a daily basis (this is known as dogfooding).
PROCESS SKILLS AND TECHNIQUES
There are countless process related skills and techniques, and new techniques are always emerging. The main objective for those of us that are responsible for coaching product managers, is to make sure the PM is knowledgeable about techniques that are suitable for the tasks at hand.
Product Discovery Techniques
At a minimum, the new PM must understand the four different types of product risk (value, usability, feasibility and viability), the different forms of prototypes to tackle these risks, and how to test those risks qualitatively and quantitatively.
There are many resources online, training classes, and I have written a book on these product discovery techniques.
When I coach PM’s, I typically have them read the book, and then I like to make sure they understand the techniques by describing different scenarios and asking the PM how she would address. I’m looking to make sure she is thinking about risk appropriately, and that she understands the strengths and limitations of each technique.
Product Optimization Techniques
For products that are live and have significant traffic, there are important techniques referred to as product optimization techniques that the product manager needs to understand and know how to effectively utilize.
This typically involves learning one of the commercial tools (e.g. Optimizely or Test and Target) and then running an ongoing series of A/B tests, mostly to optimize our product funnel, but it could be used for other purposes as well.
Product Delivery Techniques
In general, the delivery techniques are the focus of the engineers on the team. However, it’s important for the product manager to understand the delivery techniques that are being used (e.g. continuous delivery), and in some cases, such as release planning, to take a more active role.
For example, for certain large product changes, a parallel deployment may be called for. The product manager needs to know what these techniques entail, especially the additional engineering costs, in order to make suitable decisions regarding delivery.
Product Development Process
The decision as to which development process the engineers use to develop and deliver software is up to the engineers and engineering leadership. However, the PM does play a role in the process, and she must understand what her responsibilities are.
Most teams are using some form of Scrum, Kanban and/or XP (Extreme Programming) techniques. Often teams are using a combination of these.
I usually recommend that the new PM take a CSPO (Certified Scrum Product Owner) course if she has not had this before. That simple and short course will explain her responsibilities as the Product Owner for the team.
In most companies, they have also standardized on a tool for managing the product backlog, such as Jira, so the new PM will need to learn the tool as well.
Note that I have long complained that too many product managers have only had CSPO training, and then they don’t understand why they fail as a product manager. Hopefully at this point it is very clear that the CSPO responsibilities, while important, are just a very small subset of the responsibilities of the true product manager.
PEOPLE SKILLS AND RESPONSIBILITIES
Thus far we have mainly discussed areas (product knowledge, and process skills and techniques) where just about anyone that’s willing to put in the time and effort can succeed. And I would argue that without that foundation, nothing else matters. That said, the difference between just a competent PM, and a truly successful PM, is often their skills with people.
There has long been a debate in the product world about whether these people skills can effectively be taught or coached. In my experience, for most but not all people, you can significantly improve and develop their people skills. But they do have to want to improve. If they are not good at these skills, and they show no sincere interest in improving, then that’s when the manager needs to help the person find a more suitable job.
Team Collaboration Skills
Modern product management is all about true collaboration between product, design and engineering. This begins with ensuring the product manager is knowledgeable about the real contribution of product design and engineering.
The PM does not need to be personally skilled in either design or engineering (most aren’t – although many PM’s think they’re great designers) but they do need to understand and appreciate their contributions to the point where they understand that what each of design and engineering brings to the table is just as essential as what the PM brings.
Next, the PM needs to establish the relationships necessary for true collaboration, which is built on trust and respect.
In my own coaching of PM’s, once they’ve learned the basics we’ve discussed above, most of the coaching I do has to do with collaboration. When I sit down with a product team to talk about a problem they’re trying to solve, I rarely spend time with just the PM – almost always it is with the PM, the designer and at least one of the engineers. Again, that’s just the nature of product today. But during these sessions, I am witness to countless interactions, and afterwards, if I’ve observed something, I often pull the PM aside and try to point out how her interactions during that meeting either helped or hurt her efforts to build that trust.
A one-hour meeting discussing a problem or objective will usually yield many good examples I can use as a coaching opportunity for the PM. How engaged is the rest of the team? Are they acting like they are empowered to solve the problem or are they acting like order-takers? Is the designer and engineer bringing potential solutions to the table or just pointing out issues with whatever the PM proposed? Are they spending too much time talking (e.g. planning) and not enough time trying (e.g. prototyping)? How are they resolving differences of opinion?
Stakeholder Management Skills
Many of the points regarding team collaboration skills also apply to stakeholder management skills, but it’s actually easier to develop the trust and relationship with your own teammates (e.g. your designer and engineers) because you are with them every day focused on solving the same problem.
There are additional dynamics at play with stakeholders. First of all, while most PM’s are individual contributors, most stakeholders are company executives. They are often very knowledgeable on their part of the business, and they are often used to giving orders.
The key to successful working relationship with stakeholders is establishing mutual trust.
For the PM, that starts with putting in the time and effort to understand what each of the stakeholder’s constraints are. We discussed this under Business and Company Knowledge above.
But once the PM has put in that effort, she needs to personally convince each stakeholder that she understands what they are concerned with, and that she’ll make every effort to come up with solutions that work for them, and in any case, whenever she identifies something that might be of concern, she will preview those solutions with that stakeholder before the team builds anything.
Building this trust takes time, as there are less interactions, and each interaction carries more weight.
Again, in my work with product teams, I often observe PM / stakeholder interactions, and there are often lots of good coaching opportunities. I try to reinforce the actions that helped build trust, and point out alternative approaches for actions that diminished trust.
Especially in medium to large sized companies, so much of product involves persuasion. Convincing your team and convincing your stakeholders that you understand what you need to do, and you’ve got a solid plan to deliver.
I recently wrote about one of my favorite coaching tools that is very good for improving your arguments.
I also encourage PM’s to take a presentation skills class, where your presentations are video recorded and you are provided professional critique. I’ve personally taken this class twice over my career and consider it invaluable.
Finally, so much of strong product management is actually about leadership.
Leadership is especially important for the PM because the product team and the stakeholders don’t report to you, yet leadership is especially hard because they don’t report to you.
Which is to say, for the PM, leadership must be earned. It does not come with the title.
But this is also why so many strong product managers go on to become successful heads of product and CEO’s.
So how do you develop these leadership skills? The pre-requisite are the items above. If you’ve done your homework and demonstrated your knowledge and skills, and have earned the trust and respect of your team and your stakeholders, you are well on your way.
Beyond this, I encourage all product managers to become lifelong students of leadership. Most of us know people we consider terrible leaders. Some of us are lucky enough to know people we consider amazing leaders. Discussing the defining characteristics of each makes for excellent coaching discussions.
My next article looks more closely at coaching and leadership.