A few years ago, I was working for a large company here in Austin. This company had recently acquired a series of software startups and was attempting to integrate them into their larger hardware portfolio. The product team I managed was responsible for the integration, product management, and transition. What I learned during this time about Sales behavior was a shock to my system – and may help you as well.
Imagine a Fortune 100 company: large, established, incumbent. Also stale, bogged down in red tape, and struggling to innovate. A typical move for a large company is to inject innovation through the acquisition of a smaller company. Often, this makes great sense on paper – the bigger company gets access to technology and talent they don’t have, and the smaller company now has an opportunity to both cash in their hard work and take their products to a much larger audience via an established sales channel. If you’ve worked in the industry for any length of time, you’ve been through this cycle from one side or the other. Unfortunately, what looks good on paper can quickly go astray if you don’t understand Sales and the tools you are giving them.
In this case, my team had responsibility for four to five smaller acquisition company products and portfolios. Luckily, the larger company had done a good job acquiring companies in the same area who had complimentary products, both to each other and to the larger company’s hardware devices. Essentially, our new software portfolio provided ongoing systems management for the hardware that made up the mainstay of the larger company’s business. If we could simply start to attach our software to the millions of dollars of hardware deals that were already happening, there was a great chance of success!
To make this picture even more attractive, the larger company’s hardware business was undertaking a long, slow decline both in revenue and profitability. They were averaging single digit gross margins on hardware, whereas our software was achieving typical software margins in the 40-60% range and higher. By all rights, it was going to be an easy win…until we starting training the larger company’s Sales teams.
The first time we trained one of our hundreds of new Sales teams, we knew we had an issue. We did a “lunch-and-learn” where we fed the team pizza and spaghetti, while one of our product managers did a demo of the product and talked about how it was complimentary to the products they were already selling into their accounts. The Sales team was polite and listened while they ate for about thirty minutes. Then, everything went wrong.
At the end of the presentation, the Director of the Sales team stood up. He looked straight at my product manager and said:
“John1, I want to thank you for that great presentation. I think we all now have a clear understanding of your product, its pricing and competitive positioning, and how it can help the company. I understand that the CEO has identified this as a strategic product. And you know what? We are never going to sell it.”
Needless to say, that was not the reaction for which we were hoping.
John tried to recover by asking the Director why he felt that way, and the Sales Director responded by saying:
“To your credit, this does seem like a really good product. But, it doesn’t match up with how my team is rewarded. Right now, software sales represent 10% of our quota, and hardware is 90%. If one of my guys blows up his software number and misses his hardware number, he is fired. If he blows up his hardware number and sells zero software, nobody cares.”
Very quickly you can start to see the problem – even though the company had spent millions of dollars on this acquisition, they had not put the tools and behavior modification in place with their existing teams to make it a success.
At this point, we needed to get educated (quickly) on how Sales at this company was motivated. Our next stop was Finance. We scheduled a meeting with someone that Finance identified as the “Genie of Sales Compensation.” When we sat down with the Genie we asked her to show us how Sales was motivated, quota’d, and bonused. That was when she opened her manila folder, and took out a taped-together 3×3 matrix of legal sized paper, upon which was printed in 6-point font an Excel spreadsheet containing approximately three dozen rows representing the different sales teams, and about fifty columns representing various ways the Sales teams were measured. Some Sales teams had thirty or more variables to determine their quota attainment.2 In short, you needed a Ph.D. in Sales compensation to understand this system.
Many people refer to Sales as “coin operated,” by which they mean that Sales operates in whatever way will help them get the most coins. This is exactly how you want Sales to act, but it reinforces that if you aren’t very clearly part of their compensation, they won’t spend time worrying about you, regardless of how strategic or important to the business you think your product should be.
In the end, we found that adjusting the Sales teams compensation models to account for our products was so fraught with politics and peril that it was doomed to failure. Prioritizing our products in terms of comp meant deprioritizing someone else’s products, and every Sales comp line had an advocate in the form of a powerful executive for some other product. That is when we realized that we needed to sidestep the issue by creating our own overlay Sales team that was only measured on our products. This worked, but only after a lot of pain and suffering.
This month, Pragmatic Marketing’s bloggers are going to be writing a lot about various Sales tools and ways we can enable Sales teams. Remember however that the number one most powerful Sales tool in the Product Team’s bucket is the compensation model. If you get this wrong, or your product is not represented in it, it will not matter how slick your competitive training is, or how good your positioning is, the strength of your competitive analysis, or how well you priced your product. As the CEO of your product, you must understand how your team is motivated – and take corrective action where required.
What other challenges have you run into with Sales, and how did you overcome them? Weigh in below in the comments section.
1 Name changed to protect the innocent
2 This is when I realized that I prefer smaller companies to larger ones
On this Friday, June 6, 2014, I will be presenting at a virtual conference called PIPELINE 2014. PIPELINE is put on by Planview, and will include presentations about a wide variety of topics of interest to Product Management and Marketing professionals, including innovation, ideation, prioritization, and how to change your culture. I will be giving a talk entitled “The Cornerstone of a Market Driven Organization,” and if you’ve always wanted to go to a Pragmatic Marketing training, but never had the chance, this is a good opportunity to get a taste of our philosophy. Best of all, PIPELINE is free, and the presentations are all archived online for you to watch at your leisure – all at once or over the next year!
Over the past decade, there has been a ton of ink spilled over Agile development. Much of the Agile narrative has focused on the pros of implementing Agile methodologies, such as better planning, faster feedback, and the ability to quickly pivot and make changes. These are all good things. However, from a Product Management standpoint, Agile has some major problem areas that can create inefficiency at best, or completely wreck a project at worst.
Before we continue, I want to be clear: I love Agile. The teams I have managed and worked as a part of have delivered lots of user stories and requirements to Agile teams and seen success. Agile can be wonderful. In my travels over the past four years as a Pragmatic Marketing Instructor, I’ve also witnessed several “Agile traps” that jump up and grab teams.
1) Agile makes it harder to be disciplined with regard to strategy
Because of the nature of Agile, multiple sprints happen every two to four weeks. Organizationally, we now have the ability to change direction more quickly than ever before. This can be helpful to react to changing market conditions (or the needs of big deals).
Unfortunately, this ability to quickly change is a double edged sword. Because we can change direction quickly doesn’t always mean that we should. I often see Agile teams building half-solutions to dozens of problems instead of actually fully solving anything, because they are flipping from solving one problem to the next one too quickly. Agile requires extra discipline to stick to the strategy when it’s tempting to continuously change direction.
2) Agile values feedback from customers (sort of)
Agilistas would say that they strongly value getting constant market feedback at the end of every sprint. That’s good. In my experience, what actually happens is that most teams recruit four to five customers who are willing to provide that level of constant feedback and then roll with them – for the rest of the release or even multiple releases.
Going back to the same customers for feedback creates a two-fold problem. First, do those four to five customers really represent your overall market segment? Or, are they the “noisy 20%” of your market segment? In my experience, the types of customers who are willing to sign up for regular meetings to provide feedback every other week don’t typically represent average users; they represent power users and experts.
Second, customers aren’t dumb. Soon, those four to five customers figure out that they have a disproportionate amount of influence on your direction, and realize that their feedback can turn you into essentially a custom development shop for their particular needs – again, that’s not market driven, that’s customer driven.
3) Agile’s roles can actually prevent you from being market driven
When teams implement Agile, they often look to create new roles. Specifically, the “Product Owner” role is one that is often tasked to Product Management.
Unfortunately, the Product Owner role is extremely noisy and tactical and requires a lot of day-to-day interaction with Development in daily standups, sprint planning sessions, and retrospectives. While there is nothing wrong with making the Agile team run efficiently, I have seen teams get so obsessed with “making Agile work” that they start sacrificing what Product Management really should be doing – which is spending time with the market.
I speak to Product Team members every week who are doing the Product Owner role, and they all tell me that 95-99% of their time is spent on internally facing Development activities, and they rarely, if ever, speak to anyone in their market. That’s not a recipe for being market driven.
4) Agile helps us run faster, but are we running in the right direction?
Agile’s big promise is that it will help us run faster in Development (or whatever), but it doesn’t say anything about if we are building the right thing to begin with. That is the role of Product Management to find out. I see Agile teams often getting so obsessed with the machinations of Agile that they forget that you can be the most efficient company in the world, but if you’re building something that no one wants, it’s pointless.
How is your team using Agile today? Are you running into any of these issues, or others? Please share your experiences in the comments section.
One of the most frequent questions I receive is “Who owns Design?” Should the designers report to the Development or Engineering team, should they report to Product Management, or perhaps Marketing? Or, should Design be its own group? The answer might surprise you.
Before we can define where Design belongs in an organization, we must first define “Design.” There have been dozens of books written on this topic and the debate will continue to rage online long after this blog turns to dust. For now, let’s turn to “Paul’s Pragmatic Definition of Design”
“Design is the role in a team that understands a market problem, and comes up with a solution to that problem.”
It’s doesn’t have to be harder than that. To determine where Design belongs, lets examine whom the Design primarily works with on a day-to-day basis. Design works sits as the middle layer in this diagram:
Typically Product Management is responsible for the top layer of finding and quantifying the markets’ problems. Development is typically responsible for the Build layer of bringing the designed solution to life.
However, to make this picture more complex, Design doesn’t mean just one thing. At a minimum, there are two flavors of design:
- Front-end Design, and
- Back-end Design
Front-end design is what most people mean when they say “Design.” The titles found in front-end design include User Interface, User Experience, Human Computer Interface (HCI), and Human Factors Designers – all titles found predominantly in software projects. But front-end design is not limited to software.
Front-end Designers in hardware applications are concerned with ergonomic design, user fatigue, eye level, placement of power cables and interfacing to larger systems – such as how a server might mount into an equipment rack. In services, a front-end designer might think about how many key presses a user must make on their phone when they call into an interactive-voice-response system before they can talk to a human.
Back-end Designers are often called “Architects.” In software, they are typically concerned with items like choice of codebase, code re-use, selection of libraries, how to build a system that is both scalable and secure, and whether to use Amazon EC2 or another cloud provider. In hardware, they might choose the clock speed of the processor, or how much memory overhead needs to be planned for in the system for future upgrades.
Design is measured differently than Product Management and Development. We teach that Product Management should be measured on its ability to be market-sensing. That is, members of the product team should be measured on their effectiveness at bringing accurate market data into the business to feed better decision making. Development is often measured on a combination of scope, time, and quality. Design is not measured using these metrics.
How to effectively measure a Design team is a large question that incurs significant debate. But, suffice it to say that designers have their own set of metrics to test the effectiveness of their designs. For Design, measurement needs to answer the core questions: “Does the design effectively solve the user’s problem?” “Does the design fit into their daily life or workflow?” “Does the design act in a way the user expects it to act?”
The bottom line is: Design is a huge role, encompassing a wide variety of areas. It’s very rare that one person highly skilled at both front-end and back-end design.
TL;DR, Just Tell Me Who Owns Design!
In my experience, back-end design almost always reports to Development. Because of the intertwining technical nature of the decisions these Architects are making every day, it makes sense that they would sit within the reporting structure of the team creating the solution.
Front-end design is a very different answer. In the past decade, front-end design has migrated, from reporting to Development, to reporting to Marketing, to Product Management, to their own group. Sometimes, they are contracted resources that report to whoever hires them.
Like Product Management, there is a natural tension that exists between front-end design and the Development (and Marketing) teams. This tension arises from differing (sometimes competing) goals and different measurements of success. Typically, this tension is a good thing. However, when we subsume that tension and shove front-end design under Development, or Marketing, the tension resolves in favor of the executive who owns that team. For instance, a Development team who owns Design and is measured on “hitting the date,” will naturally pressure its designers to create designs that help them hit their date. This is probably not conducive to good designs for the user.
So who owns Design? The designers, of course. And who owns the designers? I believe that the goals of Product Management are highly aligned with Design, so I can easily see these reporting up the same structure. I can also see success for Design as an independent part of the Product Team.
Wherever you place Design in your organization, ensure that you have an honest conversation about how designers are measured. If you measure Design like Development or Marketing – the results will be sub-optimal.
Nearly every product manager I speak to desires to be a leader in his or her organization. Everyone knows that as a member of the Product Team, you must exercise soft skills like influence to nudge your product towards success. However, to few know how to gain the confidence to become the leader that they want to be. The first step toward becoming a great product leader is to have the best quality and quantity of information, so that you can attack any problem with data, not opinions.
Introducing Win/Loss Analysis
One of the most chronically under-utilized ways of getting to product data is by using win/loss analysis (WLA). WLA involves developing a deep understanding of how and why your buyers make their purchase decisions, both for and against your product. WLA data is interesting to Sales, because it could highlight breakage in the selling process, and it is highly interesting to the Product Team, because it can help you sharpen your understanding of competitive threats and positioning, what customers value the most in your product, and where to focus your product marketing tactics to match the buyers’ expectations.
How to do Win/Loss Analysis
Win/Loss analysis is typically done in phases. The first phase is almost always qualitative, and involves direct one-on-one interviews with buyers. In these interviews, the Product Team should focus on asking open-ended questions that generate new learning, such as:
- What was the main driver of your purchase decision?
- Describe the process you went through when making your decision.
- What motivated you to start looking for a solution?
These questions cannot be answered with a simple yes/no, and will create good discussion that can be explored further. If you do enough of these interviews, you might start to spot a trend. Some companies feel this is enough data and stop here. Other companies go to a second, more quantitative step, and test the trends they discovered in the first step through surveys to get more statically significant results. The upside to this is higher quality data, the downsides include: cost, time, and the requirement of a large enough pool of wins and losses to sample from. If you run a B2C product with take-it-or-leave-it pricing, the quantitative step may be easier than in a B2B model with negotiated deals.
Product Teams also need to consider who they target for WLA. Wins are obvious – they went through the entire buying process, and chose our product. Losses are less obvious. Don’t think of losses a deals that went all the way to the end, such as the RFP or bake-off stage, and the evaluator didn’t pick your product. Deals such as these are losses, but they constrain your view much too narrowly. Instead, think of the funnel that you must guide evaluators through in order to close. Every company has their own definition of the steps in the funnel, but a typical funnel might have these steps:
- Qualified Lead (from Marketing)
- Initial contact, sent marketing materials
- Meeting, assessment of needs
- Demo of our solution
- Competitive displacement
- Evaluator decision
An evaluator doesn’t have to get to step six to become a loss. Many times, the evaluator might get to step two or three, only to become non-responsive. That should still be considered a loss. What if our marketing materials don’t speak to their pain? What if we demoed the wrong solution for their needs? The result of these missteps is the same – we lost the deal. WLA searches for and finds the breakage in your process so the Product Team can address it.
Unfortunately, win/loss analysis can also be a political animal. Over the years, many Sales teams have become jaded by WLA, and view it as a way to assign blame to them for lost deals. That is not why we (should) to WLA. WLA should be about finding issues in our overall process of making the sale, of which Sales is a part – but not the only part. If the breakage is in our positioning or pricing or competitive response, these things have nothing to do with Sales, but could have a huge impact our Sales ability to sell. In order to overcome political objections to WLA, we encourage teams to put their initial focus on analyzing wins. Usually no one objects to win analysis and it is a good way to get the organization comfortable with the process.
Another important caution for WLA is who does the actual interview. WLA involves getting honest and straightforward answers from a buyer, who make be skeptical of your motivations. For that reason, Sales (and anyone involved in selling that particular deal) should not be involved in that WLA. Because buyers lie to sales people – it’s in their nature. If your salesperson calls on a buyer they lost to try to find out how and why the buyer made their decision, the buyer will immediately assume that the salesperson is trying to restart the deal – a now closed issue in their mind. So the buyer will generally say whatever they have to say to get the salesperson off the phone as quickly as possible – usually defaulting to the “easy” answers of: “we didn’t go with you because of the price,” or, “your product was missing a key feature we needed.” Is there any surprise that salespeople believe that the primary reasons they are losing are price and features?
WLA Generates Results
Win/Loss analysis can sometimes surprise you and lead you down a different path to product success. One Product Team we worked with found out through doing win analysis that the reason they were winning was not that they were the low price leader (as their Sales team thought), but rather that their buyers put a major premium on their customer service and support. In fact, the Product Team was able to illustrate that in 80%+ of the deals won over the past year, price was not the determining factor. The next time Sales wanted to discount, the Product Team had some data to show that perhaps discounting wasn’t the right strategy.
Another Product Team we worked with found breakage in their renewal process by doing loss analysis, which over the course of a year saved over $1MM in recurring revenue!
Clearly, WLA is a powerful tool, and should be exercised more by Product Teams.
The Impact of Win/Loss Analysis on Product Leaders
A few quarters ago, I was teaching a Pragmatic Marketing seminar and was approached by a product manager. He was discouraged because he didn’t feel like he had management’s buy in for being market driven and, as a result, was not getting any budget to do things like visit with the market. He asked me for advice.
One of the things I told him to do was win/loss analysis. First, it is relatively inexpensive, especially for wins. Second, nothing speaks with more credibility than the buyer. Third, he needed a quick win, and WLA can be fast. I asked him to try doing a handful of WLA’s, share those with his executive team, and see what happens.
A few months later, he reached back out to me, and his demeanor had completely shifted. He told me that his CEO was so impressed with the results of his WLA efforts, that they recreated their positioning, marketing materials, and selling process around the buyers’ expectations. All of the sudden, the organization was looking to him, the product manager, for answers about the market, and his concerns about budget for occasional travel were starting to go away. In short, a few well-timed win/loss analyses changed the company’s perception of him – and his perception of himself.
If you are interested in making the same transformation into a trusted product leader at your company, remember that first step to leading is following. Specifically, following the market. Once you have the market data on the tip of your tongue at all times, the confidence to speak with credibility about the needs of your buyers and users will follow shortly.
If you are intersted in going in-depth about win/loss analysis and lots of other topics of interest to Product Teams, consider attending a Pragmatic Marketing training. I will be leading seminars on these topics on Mar 11-13 in Toronto, Mar 19-21 in Austin, Apr 8-10 in Tyson’s Corner, Virginia, Apr 29-May 1 in Denver, May 6-8 in San Diego, and May 13-15 in Princeton, NJ. I hope to see you there! In the meantime, you can always email me at firstname.lastname@example.org with questions, or comment below.
If you are a ProductCamp leader, or are thinking about starting a ProductCamp in your area, this post is for you.
There is a problem with how ProductCamps are organized and run today: they are very tribal. Knowledge is passed on a one-to-one basis, or by physically traveling to another city to watch how that camp performs. This is inefficient and error-prone, and leads to a “multiplicity” problem where we are making a copy-of-a-copy-of-a-copy and missing out on the chance to share what is working and what isn’t to create a kick-ass experience for everyone.
To solve this problem, I have joined with two other leaders in the ProductCamp community to kick off an new initiative: a Global forum for ProductCamp coordination. Joining me is Colleen Heubaum, past President of ProductCamp Austin and small business owner. She brings loads of experience in managing teams, wrangling personalities, and guiding ProductCamp through transition and growth periods. Jon White is a board member at ProductCamp Seattle and the Product Management Consortium and has a broad range of experience in managing these same issues with ProductCamps.
Our goal is simple: provide a place where leaders of exisiting and prospective ProductCamps around the world can share best-practices, learn from each other, talk about challenges and provide solutions, and collectively raise the experience that we provide to the ProductCamp community. To kick off this program, we are hosting a conference call/web meeting this coming Monday February 11th at 11:00AM Central time. Leaders from over 30 camps have been contacted and we look forward to a good discussion about where we need to focus in the future. We envision a monthly cadence of calls, which will be recorded and posted for anyone interested to listen to and gain knowledge from in the future.
If you would like to join the call, please feel free – we want this service to benefit everyone. Details to join are below:
If you can’t make the call for whatever reason (there is never a perfect time for everyone), please drop your info into this form, and tell us what topics you would like to hear the community of leaders talk about in the future.
If you have questions in the meantime, please feel free to email me. Talk to you Monday!
This is a quick reminder to take our annual survey. We’ve run this survey for over a decade to provide product managers and marketers with a “State of the Union” for their profession. We publish the information we gather for free back to the community as a service, so you can have valuable insights into compensation, job responsibilities, titles, and ratios that represent the industry.
We hope that you find it useful and will help us help you, so go take the survey now!
[UPDATE] Link fixed, thanks!
Product managers and project managers: how do they compare? Though the titles of these careers may look and sound similar, the job descriptions are really quite different. However, both product and project managers can learn a great deal from one another to better perform their own job duties. Let’s take a look at the general responsibilities for these two positions.
Project Managers: These professionals are primarily connected to the “how” and “when” of a project. The main responsibilities of a project manager are to develop clear, detailed, and attainable objectives for a project, build the project requirements and oversee and manage constraints such as the cost, time, scope and quality of a given project. Some have likened the role of product manager to that of a midwife – he or she oversees the project from start to finish, “delivers” the product to the product manager and then proceeds to the next assignment.
Product Managers: These individuals are typically responsible for defining and analyzing market conditions for a product, and discovering and quantifying the problems that the product must solve for the market. They are the “what” and “why” folks. They research customer needs and develop sales and marketing plans that will increase product awareness and get the product to the market.
Both types of managers possess certain traits that make them succeed in their work, and naturally some of these traits overlap.
The best project managers:
- Know the right questions and answers to present to stakeholders and are equally adept at listening to them.
- Are able to quickly and frequently re-evaluate project priorities and make appropriate adjustments when needed.
- Are deeply familiar with one or more areas, granting them natural authority and necessary strategic insight.
- Can sift through information and data rapidly and determine where action is needed and what can be left as is.
- Are excellent communicators. One of their critical roles is to act as the communication hub for all product-related matters, meaning it is imperative that they know how to effectively communicate with different personality types such as introverts and extroverts. They are also adept at knowing their “audience;” that is, they are able to adjust their message according to whom they are talking to so that both parties understand all matters clearly.
- Know how to be leaders without being authoritarian. Through a combination of negotiation, influence, and relationship building, the best product managers can steer their ship calmly and steadily.
- Learn quickly and possess a solid understanding of the fundamentals of business. They know how to identify opportunities and strategies that will lead to a winning product.
Clearly, the strengths of project and product managers can overlap despite the difference in their roles. In order to serve as effective leaders, both positions can learn from the characteristics their counterpart is known for. Time management, excellent communication skills, effective leadership practices and attention to detail are all areas that serve both product and project managers well. Take a moment to think of these and other skills and traits that your counterpart may possess which could help you be more successful, manage tasks more effectively, and develop better relationships with your team.
Ryan Sauer is a writer and editor for Bisk Education in association with University Alliance. He actively writes about project management in different industries and strives to help professionals succeed in getting their project management certification. Through the University Alliance, Ryan writes to help encourage professionals obtain their PMP certification online.
A great mentor can be a huge help at any stage of your career, especially the early and mid stages. I’ve been fortunate to have some excellent mentors throughout my career, who have helped me drive my career in the direction I wanted. I recently agreed to be a mentor to a young product manager, and going through this process has made me think about what I want to give and receive as a mentor. Unfortunately, most mentoring relationships are sorely lacking in structure and results, and it can be very disappointing to establish a mentoring relationship only to see it fizzle out.
Mentorship typically breaks down for the same reason people stop going to the gym: it seems like a great idea at first, but then you find out that it’s really hard! Then, life takes over, and six months later you realize you haven’t talked to your mentor in months. Even worse then having no mentor is having the hope of a great mentor that gets dashed due to lack of follow through. Both the mentor and protégé should have reasonable expectations of what each side wants from the relationship, and of the time commitment involved. First, let’s examine what a mentor and protégé should desire and expect.
One who is protected or trained or whose career is furthered by a person of experience, prominence, or influence.
The motivation for a protégé to enter into mentorship is obvious: they hope to gain from the experience of their mentor. But a protégé should not just be a passive receiver of information, their job should be to put the advice and council they are getting into practice and offer feedback to their mentor. Every mentor-protégé relationship is unique, but there are several areas where mentors can be especially helpful in the realm of product management. These areas include:
- Strategic Thinking
- Executive Relationships
- Career Planning
- Management Skills
- Executive Presence
Good protégés should have a willingness to learn, be open to new ways to accomplish their goals, and have a strong desire to advance in their career. One of the first steps to becoming a good protégé is to recognize that you could benefit from a mentor, and by recruiting your own mentor. People are almost always flattered to be asked to be a mentor. If they’ve never mentored before, send them this post as a how-to guide to get started.
1. a wise and trusted counselor or teacher.2. an influential senior sponsor or supporter.
The motivations for a mentor to enter into a relationship are less obvious than the protégé. People become mentors for many reasons, such as a personal connection to the protégé, to help someone in need, because they see potential in a protégé they want to foster, to “pay it forward” from their time as a protégé, or simply to stroke their own ego.
Solid mentors have executive and management experience they can apply to help the protégé in various situations. They can help the protégé understand how to interact with leadership teams and stakeholders across the business by illustrating different perspectives the protégé may have not considered. A good mentor can even help role-play with the protégé by acting as the protégé’s executive team, preparing them for potentially stressful or high stakes meetings.
A word of caution to protégés searching for a mentor: your manager should never be your mentor. Part of mentorship is providing neutral, disinterested feedback on a variety of topics, including how to deal more effectively with your management. Your direct manager has a conflict of interest and cannot provide this feedback in the same way, plus it puts them in an awkward position when you ask them to mentor you. If you have a great manager that you want as a mentor, keep them in mind for when you move to another role where they aren’t managing you directly, and they will be honored to act as your mentor in that capacity.
Mentors can also help their protégé with their experiences in hiring and building teams to inform career planning and advancement. Mentors can advise on when to stand pat versus when to seek a job or company change, how hard to press during salary and benefits negotiation, and helping them map their desired titles and responsibilities in their next several roles.
Finally, mentors should also supply their protégé with access and introductions to the mentor’s wider set of contacts. The mentor by definition will typically have a more expansive network, that they should allow the protégé to use. In addition, the mentor should also make proactive introductions to people from their network that the protégé would benefit from knowing. Those contacts could become future bosses, contacts, or even additional mentors for the protégé.
The primary role of the mentor is to arm the protégé with council and contacts to make them successful.
Formats and Time Commitments
Mentoring is not free; for the mentor or the protégé. It costs in the form of time and energy. The amount of time and energy will vary based on the formats you choose.
Frequency: Once a month to every three months
Meeting face-to-face should be the staple of a mentorship relationship. 70% of human communications is non-verbal, and you will both miss out on that extra data if you try to do all the conversations online. Go grab a drink, hash out your issues. More than once per month will probably overtax the mentor, less than once every three months will allow the relationship to grow stale.
Frequency: Bi-weekly to monthly
Talking by phone between face-to-face meetings is a good way to keep up-to-date and do course corrections. It is also the way to get quick answers to questions that can’t wait for an in-person meeting.
Frequency: As needed
Email is good for background information, homework assignments, and certain introductions.
Roadmap for Mentoring Success
Mentoring is hard, but it is easier with a plan. If you are thinking about setting up a mentoring relationship, and you are willing to put in the time to make it work, use this plan as a launch pad to get started. You will know quickly if you need to modify this outline, but at least you have a starting point. Note: this outline is designed for a protégé product manager in an early career stage.
- Month 1: initial meeting, mentor should probe protégé for “where do you want to be in 1/5/10 years.”
- Month 2: chart a plan to achieve the 1/5/10 year plan, break 1-year plan into measurable goals for the year, design a plan to “sell” the goals to protégé’s management as part of objectives.
- Month 3: assess current role, responsibilities, fit to 1-year plan, compensation and benefits (design plan to correct if under market).
- Month 4: catalog past achievements, design plan for reviewing with current management so the protégé’s value is recognized.
- Month 5: ensure protégé is receiving adequate executive exposure and design corrective plan if not.
- Month 6: introduce protégé to contact from mentor network in an industry or title that aligns with his/her 5/10 year plan.
- Month 7: mid-point check in on 1-year plan achievement versus goals, adjust as needed.
- Month 8: identify networking and visibility opportunities to raise the protégé’s thought leadership profile inside and outside the company (e.g. presenting at a local ProductCamp), plan and execute.
- Month 9: collect information in support of comp and benefits negotiation (e.g. Pragmatic Marketing’s annual survey report), assemble BATNA.
- Month 10: assess performance versus 1-year plan, make adjustments to suit. Role play comp negotiation if needed.
- Month 11: assess results of negotiation and decide what action to take.
- Month 12: revisit 1/5/10 year plan. Assess need and value for continued mentorship. Repeat!
Completing the Circle
The last step in mentorship is to “complete the circle.” This means that the protégé should pay back the experience by becoming a mentor themselves. This step doesn’t have to happen immediately, but it should happen if the protégé got a benefit from the original relationship. Thank you notes to the mentor are always a great idea, but the biggest compliment to a mentor should be that they inspired you to become a mentor yourself. Pay the ultimate compliment, and as you grow in your career, help the next generation along and remember that you could be mentoring your next great team member (or boss)!
Rich Mironov at Product Bytes weighs in with a thoughtful post about measuring product managers. He had a recent experience in Sweden where the product executives he worked with shared the same concerns as product executives in the U.S., Europe and the rest of the World, namely: what is the right way to measure the performance of a product manager?
This is a really interesting and difficult question to answer. Rich breaks it down into three areas: product-level metrics (product revenue, profit, customer sat), team-level metrics (are the other teams getting what they need from product management), and individual-level metrics. The first two metrics are fairly well defined – there is a strong history of measuring products and teams with these criteria and there are MBA programs with entire curriculum defined about measuring product performance. Unfortunately measuring individual product manager performance is more tricky as these metrics are not as clear.
Lacking traditional or clear metrics, most companies rely on product-level metrics such as product revenue, margin, or customer satisfaction to measure the performance of an individual product manager. The thought process is defensible – you want the product manager to be motivated by metrics that lead the product toward success. Unfortunately, product managers typically have very little control over the outcome of these metrics, or at best, indirect control. For a product manager measured on product revenue, the product manager could spend months designing the perfect product, training the sales channel, and working with marketing to design a lead generation campaign – only to wake up one day and find that the executive team had made a strategic decision to make a large acquisition and change Sales resourcing. That change would have a huge impact on the product manager’s metrics, at no fault of the product manager; effectively they would be penalized for doing the right things. For a product manager measured on product margin, I always ask “Do you have the ability to outsource the development of your product to a 3rd party if your internal engineering team delivered an estimate that was too expensive?” For most product managers, the answer is a resounding “no.” Customer satisfaction suffers from a similar control issue – there are lots of reasons beyond the product that customer sat may suffer, and most of those reasons are not something a product manager can impact.
The other issue with measuring product managers on product-level metrics is an issue of timeliness. If you are measuring your team on product revenue, you can make an argument that it may take up to 18-24 months to know if the product manager is doing a good job. Consider this – if you hire a new product manager, before he or she can impact product revenue, the following will need to occur:
- The new product manager will need to go into the market and research the market’s problems (up to 3 months)
- The product manager will then write what they have learned into a business plan, and get it approved (1-2 months)
- Then the product manager will write requirements for engineering (up to 3 months)
- Then engineering will build something (6-9 months)
- Then in most products there will be a Sales cycle (3-6 months)
Only then will we have the data to understand if the decisions made on the front-end of the process are “good.” Hopefully we will be more agile and most faster, but the point remains – using product-level metrics to measure individual performance is insufficient. We need a better way, and there is a better way.
What I have settled on for measuring individual performance is to measure the activities required for a product manager to be market-driven:
- Setting a quota for market visits (10/quarter is a good start IMO),
- Being able to defend an updated business plan in front of me and their peers every quarter, without using the phrases “I think,” or “In my opinion” (which requires higher order thought and research).
- Keeping their finger on the pulse of the business by defining and measuring the right product level metrics and communicating them in the form of a dashboard report monthly.
I like these metrics because they require a product manager to get out from behind their desk and be outside-in focused, and the product manager can control them, as opposed to revenue, margin or CSAT which the product manager cannot control.
All things being equal, it would be preferable to measure outcomes as opposed to activities, but it is wicked hard to separate and quantify the inputs of a product manager vis-a-vi all the other variables that go into making a product fly. Activities are a sufficient proxy to measure a market-driven product manager to supplement product-level metrics and understand if a product manager is doing their job – without having to wait two years to find out.