Unfortunately, the product management interview process at most companies is poor. Navigating the interview process, or creating a good one at your company is a tall task.
In this wide-ranging interview we cover both perspectives to help you think about both the perspective of the interviewer and the interviewee. You’ll learn how to prepare to run a great interview process, when a project is appropriate and how to make it effective, as well as tips for your resume, and how to handle imperfect interviews for your next job.
This episode is with Willis Jackson, a long time friend of mine who has been the first PM at recently IPO’d Grove Collaborative, as well as VP of Product at Apto. He’s now hard at work on his own startup, but he took some time to share a lot of hard earned knowledge on the interview process in this episode of Practical Product.
The Product Management Hiring Process: How to thrive as the interviewer or interviewee
On this episode, we cover terrible PM interview practices, the key fundamentals of hiring you need to follow, how to ask behavioral questions the right way, making good PM assignments, and how to build your resume like a pro.
Highlights of the episode include discussing:
(0:44) – Introducing Willis Jackson
(2:18) – The different types of Product Management and how they affect interviews
(8:09) – Recommended resources to learn to be great at hiring.
(17:15) – Handling ridiculous hypothetical questions and what to do instead.
(26:51) – The importance of networking, reputation and interviewing stories
(38:33) – How to make good, fair PM assignments for your interview process
(52:43) – Whether you should include company problems in your interview process
(59:13) – Resume crafting do’s and don’ts for PMs
(1:22:45) – Finding the right type of PM roles and filtering opportunities to save all sides tim
Key Show Notes & Further Reading:
We covered a lot of ground for both the interviewer and those seeking their next job, so some key takeaways are grouped below for each.
For the interviewer:
If you know you’ll be hiring down the road, start planning now. Think about the skills you want, the values you want, and the process you’ll follow.
Interviewing is a skill. Spend time reading and learning how to do it well.
It’s much easier to create your interview plan in small, incremental steps leading up to when you need them than being buried, desperately needing help and spread too thin.
Avoid puzzles, brain teasers, and hypothetical situations that are nothing like the job they’d have. Research shows it has no bearing on evaluating candidates effectively.
If you’re going to make an assignment, make it:
A reasonable time request (a few hours, not days worth of effort)
Consistently applied to everyone (don’t give one person a day and someone else 2 weeks)
Involves what the job would really include. (Willis’s example is a plan after an experiment / launch fails)
Extremely clear what you’ll evaluate them on and what you will not. (Like whether you care about design or format)
Be proactive in communicating with your recruiting team. Enlist their help and expertise to find & close great candidates.
Remember that hiring the wrong person is extremely expensive in time wasted by your team, cost on your budget, and setbacks on your projects.
For the interviewee:
Make your resume succinct and include data & numbers as much as covering skills and actions
If you do not have numbers now, start working on it now. Get in the habit to look up numbers and see what work you did has moved the needle.
Your resume becomes talking points and great questions in the interview.
Prepare good questions to ask an interviewee to make sure the company does the kind of product management you like doing.
Reflect on your current job regularly. Willis recommends weekly journaling on subjects like:
What wins have you had recently? What happened?
What did you learn from a project that recently didn’t go well?
What do you enjoy about your work and want future jobs to also offer you?
What’s changed over time in my notes?
Helpful links mentioned in this episode:
BOOK: Work Rules by Laszlo Bock is about Google’s learning about HR and People responsibilities, including interview tactics.
Are your product specs high quality? Do they succinctly and clearly convey what you’re working on, why you chose them, and what your engineering and design partners need to do their jobs well?
Or are they kind of random, with each one different than the last?
I’ve helped dozens of PMs improve their product specs, and I’ve been lucky to learn from one of the best how to make a great product spec. Which is why I knew I needed to do an episode on the subject to help everyone improve their product specs.
Today, we cover:
The most common mistakes PMs make in their product specs
How I learned the right way to make a spec
The key, fundamental concepts underlying good product specs
and most importantly: Exactly what goes into a great product spec (aka- Product Thesis)
How to Write Product Specs Your Team Actually Wants to Read (AKA – The Product Thesis)
Everyone writes product specs regularly in their job as a PM, but few do a great job with them. These poorly constructured specs then cause all kinds of problems on product teams including:
Engineers and designers confused and uninspired about what they’re making
Delays in shipping due to misunderstandings and miscommunication about priorities
Disappointed execs who don’t get what they expect
And a lot more. Yet, it keeps happening because PMs don’t realize that the root cause in their specs that:
Do not cover the right topics
Are wayyyyy too long, and filled with fluff
Tend to be overly prescriptive on the solution instead of collaborating with your team on it
Lack data to back up your decision
Fail to share an inspiring WHY to motivate your and convince your team
Are inconsistent spec to spec making it harder to read and digest
That’s why we need to hit the reset button and reshape how you make product specs with something called The Product Thesis. Listen in to learn more about it:
Highlights of the episode include discussing:
(0:49) – Mistakes made on the average Product Spec
(3:17) – Introducing you to The Product Thesis
(10:06) – What goes into a Product Thesis?
(12:05) – Section 1: Why are we working on this next?
(14:57) – Section 2: When and how do people use this feature? (Aka – what are the use cases?)
(18:24) – Section 3: What problems do we need to solve, and in what priority?
(24:19) – Section 4: How much time is budgeted for this project? When does this need to be completed by?
(25:56) – Section 5: What are the future considerations that must be accounted for?
(27:28) – Section 6: What is our KPI or metric for this thesis?
(29:59) – Optional: For larger companies: Who are the stakeholders and how/when do they need to be involved?
(31:14) – Optional: What kind of launch or marketing/sales efforts go with this feature?
Have you ever thought about building a free tool for your company? Do you want to build more buzz, get a ton more inbound SEO links, or drive signups and leads for your core business?
Or maybe you are a free tool skeptic, worried it will distract your team, take to much time, or not pay off?
I’ve always been curious about free tools, but haven’t been directly involved in many myself. So when I met Michael Novotny, who has become an expert in creating free tools, I knew I had to have him on the Practical Product podcast.
Michael is a product manager turned founder, who has helped build and launch dozens of free tools / side products now and studied hundreds of others with his company, Product and Build Co.
In this episode we go deep on this topic covering everything including keys to success, pitfalls to avoid, tons of examples, and how to convince yourself or your boss to take a shot at making some free tools or side products.
How to Use Free Tools & Side Products to Grow Your Business
Today we talked about how building free tools (aka – side projects) for your company can help drive major growth for your company.
Building these tools helps you a few ways:
People who use your free tool may directly sign up for your paid product when they see you made the free tool.
People using your free tool may give you their email address, which you can market to later.
Others will link to your free tool, boosting your SEO through improved backlinks.
Michael shares a lot wisdom and experience doing these, and the most important tips are:
Build a portfolio: You need to launch many tools (ideally 4-5 or more) so that some will hit, and others won’t. If you only launch one, the odds work against you on the moon and stars aligning for you.
Build in public/test with your community: To increase your success rate, validate and test the ideas you have for tools to see if they resonate and what are the most important things it needs to do to provide value.
Use low and no-code tools: You can build and launch a lot faster using these tools, and since it doesn’t touch your core product, it doesn’t need the perfect architecture.
There’s a lot more to this episode, so I encourage you to give it a listen on your favorite platform or in the player below:
Highlights of the episode include discussing:
(2:04) – How Michael discovered the power of free tools to drive sign-ups for another product
(11:46) – What are a couple of your favorite examples of these tools?
(16:31) – Cases where free tools didn’t work out.
(21:55) – Are there businesses that shouldn’t be creating free tools?
(29:05) – What is Michael’s Side-Product Framework?
(34:56) – How should PM’s think about budgeting for Side-Products?
(42:08) – How do you come up with good ideas?
(47:55) – How can you start to validate some ideas for tools to see if you’re on the right track?
(54:09) – What should people do to make these free tools successful?
(58:05) – What are the best ways to tie a free tool to your product?
(1:03:32) – How much ongoing maintenance should you expect?
(1:09:18) – What are your favorite tools that help you piece this process together?
(1:13:58) – Keys to convincing your boss or peers to try free tools.
We had an amazing, 95-minute conversation covering a wide range of topics that any manager leading a fully or partially remote team needs to hear.
And if you’re thinking about changing jobs and joining a remote organization, you’ll want to listen in too, because we specifically talked about the transition you’ll have to make as well.
How to Succeed as a Remote Product Leader (even if you’re new to it)
Some jobs are not that different doing them remote versus in person. For example, a sales rep may have to sit and make the same calls, send the same emails, and generally have identical tasks that if anything, might be easier in a quiet environment remotely.
For a highly collaborative role like product management, that’s not the case. A LOT changes.
What works in person, doesn’t always work remotely, and often, the solutions aren’t even a 1 to 1 trade. Instead, you have to reinvent entire workflows and processes to fit the different way of working remotely.
Today’s discussion with Valentina Thörner goes deep on exactly these things.
You can listen on your favorite platform or in the player below:
Highlights of the episode include discussing:
A deep dive on remote vs. in person communication advice, and great team construction:
(1:43) – What are some of the biggest changes when someone shifts to a remote PM role?
(11:38) – How can a Remote PM be successful?
(14:55) – How can Remote PMs understand how their team is feeling and reacting to their work and communication in an asynchronous environment?
(24:00) – Do you think the ideal product team size is different for remote vs. in-person?
(26:54) – How do you avoid meeting & Zoom fatigue / overload?
(42:16) – How do you create the collaborative juices from a whiteboarding session for a remote team?
(48:48) – How often do Remote product teams need to be together in person?
(51:53) – How much would you think about geolocation when it comes to constructing pods?
If you’re thinking about working as a remote PM or want to find a great remote company:
(58:49) – What are ways PM’s can prepare themselves for the shift to a remote-first organization?
(1:04:54)- What questions would you recommend asking when sussing out if a remote company is the right fit?
(1:14:15) – What skills would you recommend developing for folks looking to become remote PM’s?
(1:20:32) – What are good ways for folks to build their writing and communication skills?
(1:27:10) – Are there any more skills people need to develop to be great Remote PM’s?
Key Show Notes & Further Reading:
– Books and other helpful links from today’s episode:
Many books and great blog posts were mentioned in this episode. Here’s a rundown of the books:
What are the consequences of AI making our lives easier and better? What jobs will be lost and what happens when they are gone? And how should product managers think about the new, bundling phase we’ve entered?
In this week’s episode of the Practical Product podcast, you’ll hear my thoughts, and some quotes from others related to a few key topics that have been top of mind lately:
What it means to now be in a bundling phase for tech and how PMs should adjust their strategies.
A problematic mindset I see and hear in too many PMs.
The truth about AI and the future of work. Will we really see jobs disappear?
Practical Rants: Why intellectuals are wrong about AI, what PMs must do as we enter the Bundling Phase, and a key mindset PMs must avoid
This episode is a collection of my thoughts on some trending topics I am seeing in the world of tech and product management relevant to PMs:
1. We are in a Bundling Phase: How can we as Product Managers bundle our offerings for consumers who are concerned about economic instability? We need to establish our products as absolute must have’s in the eyes of our customers and recognize the new market dynamics to survive and thrive .
2. Let’s stop the Self-Deprecation in Product Managers: Don’t be the “this is fine” dog meme, be part of the solution when you see negative trends within the culture or product at your organization.
3. The Truth about AI & the Future of Work: I break down a clip from Yuval Noah Harai and his horrendous take on the “Useless Class” of folks he predicts will grow as technology continues to advance. We must shut push back on this rhetoric and build tools for an abundant AI future.
You can listen on your favorite platform or in the player below:
Highlights of the episode include discussing:
(1:27) – Bundling within companies amidst economic uncertainty
(6:34) – What to do as a PM when you see customer churn due to bundling
(10:23) – Understand your secret sauce
(12:37) – Self-Deprecation in Product Managers
(17:29) – Yuval Noah Harari on the “Useless Class” & The future of work with AI
(29:22) – Product Managers can be part of the solution
(32:04) – Final Thoughts & Recap
Key Show Notes & Further Reading:
1) Now entering the Bundling Phase…
I saw a tweet from my old boss and mentor, Hiten Shah, that really hit home:
That got me thinking…why now?
Now you have the combined argument of:
We had too many tools to manage. IT hated this. It was a security and info management nightmare.
Budget cuts. You’d rather cut a tool than an employee. And there’s an easy case to make to decision makers that, “hey, this big system does all these things. Let’s cancel all the other tools and consolidate on this.”
And for PMs, this means you need to consider a few key tactics to navigate this reality:
Look for breadth over depth in feature building. In a consolidation phase especially, you’ll be competing against a lengthy feature checklist, where one system that does everything gets the purchase, and there’s no second place.
Take advantage of integrations and APIs. If you integrate with tools they use, it helps keep you sticky. And if you have an API and others build on top of what you’re doing that’s also a great, viable strategy to expand your functionality faster than your own team can build.
Build for the right ecosystems. Microsoft and Salesforce are two of the biggest heavy hitters. They’re exactly what people are going to consolidate on because it’s so easy to. Be prepared for push back though…both are miserable to build on.
Tighten your relationship with Sales and CS. You need to know how you’re winning and losing deals. Find out how account management is doing trying to retain key accounts and what they’re saying they’re thinking about.
Understand your secret sauce and champions. What’s unique about your company? What do you do better than most? What critical thing do you deliver that will have someone with influence at a customer banging the table to keep you? If you don’t have it you better get it. If you do, make sure that feature stays great. Don’t let the goose that lays the golden eggs get hurt.
2) The problem of self-deprecation for product managers.
While this meme can be funny, it shouldn’t be your main identity as a product manager:
It sends a bad message to everyone around you if you’re constantly self deprecating about your job:
It makes you sound like a victim, and potentially setting you up to welcome more abuse
It creates a self-fulfilling prophecy where you look for confirmation of this negative way of living as a product manager. Build for and focus on the positive direction.
It sends a bad external message to other PMs that “this is the job.”
And maybe in some cases “this is the job” but ask yourself if that’s what you really want?
3) Why AI is NOT going to cause massive unemployment.
The ignorance of Harari is staggering. He oversimplifies things and has such an out of touch view of reality.
These changes always happen. Every time there’s talk of this concern.
There used to be tons of jobs for horses before cars: Poop shovelers, veterinarians, horse feed, etc.
And cars of course created jobs: car dealers, mechanics, all the many parts needing manufactured, car washes, windshield repair, gas stations and the entire oil industry, etc.
There were floors and floors of accountants and bookkeepers, and then the spreadsheet came along…and with the rise of computers, I think we can all see the many jobs they created, and how information and services were democratized.
There are plenty of jobs to fill
In today’s world, it’s crazy for someone to argue there are no jobs. There are tons of opportunity all around us:
We have organizations like Bloomtechhappily training people, many coming from “low skill” jobs.
Most tech jobs are self taught, too! Can you major in sales or product management?
This means that even if some jobs are displaced by AI, there’s no reason to believe there won’t be work for these people.
AI makes jobs more efficient, not eliminated.
Not one reply to this great question about copywriting AI mentions *anyone* losing their jobs:
And similarly, Github’s AI is making engineers faster, not taking their jobs:
When you free up a worker’s time, they can do more and different things.
Product Managers can be part of the solution.
If you’re working on a product that uses AI, think about how you can help make a better future for workers:
Build your tools to make their jobs faster and better, not replace them. You’ll get less adoption resistance and they’ll become your loyal fans.
Make your interfaces more accessible and easy to use. This will allow newcomers to use your product, and speed up adoption.
Harari is a monster and a terrible human being.
Harari is an example of an intellectual monster. He is giving speeches like the video embedded above to world leaders at places like the World Economic Forum. He has a large platform and the ears of people that make his ideas very dangerous.
Did you know that part of Nazi eugenics called some people, “useless eaters”? To use phrases like the “Useless Class”, is the first step to genocide and should be condemned fully, especially in intellectual conversations as we all develop technology people will be using every day.
Do not fall for those false pity ideas from false intellectuals. There will always be jobs. And every new technology creates new jobs and opportunities as much as it may eliminate a few old ones.
We as product managers have the opportunity to be a part of the solution and create the future that helps everyone, and does not consider anyone “useless.
Want to be the first to hear about new episodes of the Practical Product podcast, and other blog posts I write about Product Management? Subscribe here:
Why is it such a struggle for 1st PM hires to succeed? What are the challenges from the perspective of a product leader who has done this before? How can you avoid being a casualty of the 1st PM curse?
Today, we answer those questions and a lot more.
A chance meeting…
Back in 2019, I was living in New York City. I was meeting other PMs in town, and by chance was connected to Hostos Monegro. As it turns out, we had a lot in common, as we’d both been a 1st PM multiple times at startups.
As the conversation continued, we realized there was *a lot* in common between our experiences. It helped me realize that the situations I experienced were possibly less about me, and more about the nature of the job. It ultimately led to the inspiration for the now oft-discussed post, “Why you want to be the second 1st PM.”
Knowing how much credit Hostos deserved for inspiring and helping craft the ideas of that post, I knew there was no one better to talk about the product manager perspective than him. When I started planning this podcast, he was one of the first people I asked to come on the show, and this week’s episode is the product of that discussion.
The Curse of the 1st PM – Part 2 w/ Hostos Monegro, 4-time 1st PM
Today’s discussion with Hostos dives into lessons learned on having made the majority of his career being either the 1st PM, or as our original post called it, the *second* 1st PM (who comes after the first one didn’t work out).
If you’ve ever thought you wanted to try being a 1st PM, or already are one, this is a great episode for you. We cover key topics like how to screen for the right founders to work with, why this role can be awesome and fulfilling, and how to avoid some of the common pitfalls that come with the curse of the 1st PM.
Highlights of the episode include discussing:
(2:14) – What is it like being a 1st PM the 4th time around?
(5:53) – How did you think about filtering the Founder when looking for a 1st PM role?
(9:14) – What are the awesome parts of this kind of role?
(15:07) – What are some of the hardest lessons you’ve learned as a 1st PM?
(25:17) – Advice for someone interested in taking on the 1st-PM role
(38:40) – What should potential PM’s look for in a company to determine if it’s a good fit?
(46:52) – Recommendations if you think some of these 1st PM pitfalls apply to your situation
(48:11) – Advice for founders thinking about hiring their First-PM
Why is it such a struggle for 1st PM hires to succeed? What are the challenges from the perspective of the CEO who hires them? What do founders learn in the experience when seemingly inevitably, the 1st PM they hired with the best of intentions didn’t work out?
And knowing he had just gone through this, I knew we had to talk about it on the Practical Product podcast. That’s why this week’s episode is all about it.
The Curse of the 1st PM – Part 1 w/ Pulkit Agrawal, CEO of Chameleon
If you haven’t read it yet, the best place to start is reading my 2019 post, “Why you want to be the Second 1st PM” to get context on this unique role that comes with special challenges, and sometimes a lot of baggage.
Today’s discussion with Pulkit helps answer the question you may have from the post, “How does this happen?” Pulkit read my blog post, new the risks, and yet it still happened.
Are all 1st PMs doomed? Probably not, but the challenges and unique factors of being an early stage startup do make for an ever-changing set of circumstances that can make someone who was the right choice when hired no longer the right person 6-18 months later.
Pulkit and I have a really candid conversation about what happened, what he learned, and most importantly what he’ll do differently with the second 1st PM (who he just hired).
Highlights of the episode include discussing:
(5:35) – How has your approach changed for hiring PM #2?
(6:27) – What got you excited about the person you ultimately hired for the #1 role?
(13:52) – When did you start to realize things may not be working out?
(18:28) – How did you handle the transition of a PM leaving the team?
(25:13) – Is it inevitable that the first PM will never be a perfect fit?
(34:02) – How are you thinking about changing your hiring process the second time around?
(35:44) – What advice would you give a founder who’s considering hiring their first PM?
(43:17) – How can the founder set the PM up for success?
(45:03) – What advice would you have for PM’s interviewing for a first PM role?
(48:52) – What are some red flags candidates need to look out for?
“A great product manager is… 🧵 ” <- You’ve probably seen more than a few threads like this on Twitter. The challenge is that the whole list is impossible to be in one person; even if you did somehow manage all the skills needed, you’d still end up with not enough hours in the day to do it all.
Reading it resonated a ton as I’ve seen in my career and coaching other PMs, so I knew I had to reach out to Jason to talk more about it on the Practical Product podcast.
The “Impossible” Product Manager w/ Jason Cohen of A Smart Bear + WP Engine
The demands of a product manager can be overwhelming. You can often be expected to be more things to more people than any one person can truly master. And even if you can do those things, there’s not nearly enough hours in the day nor the week to do all of them.
Read Jason’s full post here. Today’s podcast discussion is focused on the consequences of the post and what to do about it.
As a quick summary, there are 4 key areas of responsibility that can fall under product managers that Jason outlines:
Scrum Product Owner
The key to those for is that as Jason puts it, “a “Great PM” is excellent in one area, good in at least one other, and doesn’t have time for more than two.”
So today we’re diving into what that means for product managers.
Listen in the player above, or you can find all your favorite podcast platforms with links to them by clicking the “Subscribe” text in the player.
And as you search for that balance of the right areas to focus on, keep in mind this great visual from Jason on finding your ideal situation:
When you find this intersection, you’ll maximize your happiness *and* thrive in your career.
Want to hear about every episode of the Practical Product podcast as soon as it drops, and other blog posts I write about Product Management? Subscribe here:
Being a product manager is tough. No one majors in it, every company seems to want something different, and most learning comes by a combination of on the job trial & error, and reading blog posts.
Over the years, I’ve tried to share the most practical, actionable lessons I’ve learned from mentors and my own experiences. I hope a few of them have helped you along the way.
It’s also why I’m excited to share I’m starting a podcast with the same mission: teach others how to be great product managers.
The Practical Product Podcast
In the coming weeks and months, you’ll be hearing from many of the experts that helped me learn some of the most important skills I’ve written about here and tweeted. You’ll also hear from guests I’ve coached and gotten to know.
Each episode we’ll focus on a key challenge product managers face, or a skill they must master including topics like:
How to write a product spec your team members actually want to read.
What it’s like being a 1st Product Manager and pitfalls to avoid both as a CEO hiring them, and the Product Manager considering such a role.
How do you get your first 10 customers for a new product?
The broken hiring process for product management
Why feature voting apps are terrible and what to do instead.
…and much more.
Most importantly, we’re going to help you know exactly what to do, because what would “Practical Product” be if not all about putting what you hear into practice?
You can listen to our first, teaser episode here, and click the Subscribe button to find us on your favorite podcast platform so you never miss an episode:
Hear every episode as soon as they drop when you subscribe to the show on your favorite podcast platform here:
“Sales is just a bunch of sleazy, coin-operated machines”
“These bugs never get fixed. Product doesn’t care about CS…”
At the companies I’ve worked at, and those where I’ve coached PMs, relationships between departments have not always been great. In fact, they have sometimes been down right toxic, like the quotes above.
As much as it may feel good to point fingers, it doesn’t really help in such situations, and it’s the responsibility of product managers like you to improve them.
Yet, to fix them requires real change, new habits, and a lot communication. It’s absolutely possible (and common) to be well-liked as an individual human at your company, while the reputation of your product team or the product org as a whole is poor.
Today, we dig into those common issues, and how to hit the reset button so you can have great relationships with other departments and especially your key stakeholders within them.
How to Reset Your Stakeholder Relationships to Improve How You Work with Other Departments
Before we dive into how to fix this, let’s look at where things go wrong. There are a few common mistakes that lead to stakeholders and other departments being at odds with product teams. If any of these resonate with you, then read on:
Sales sells features that don’t exist yet without consulting product.
Sales and/or marketing complain about ship dates slipping often.
Customer Success keeps trying to come up with new ways to get the attention of product to fix things they see daily.
An internal feature request board filed by customer success, support, and/or account management has become a bloated graveyard rarely reviewed or followed up on.
Executives keep asking for new ways to be updated on product.
Product managers feel misunderstood, or overwhelmed by demands and requests.
New feature launches are extremely stressful, and rarely well coordinated with needs from other teams like marketing promotion, sales training, or help doc creations and updates by support.
And there’s likely others you’ve experienced. The underlying theme of all of them is that you have a stakeholder relationship issue one or both ways:
PM -> Outward: You’re having trouble getting what you need from other departments for launches, customer insights and needs, sales demands, etc.
PM <- Inward: Other departments are complaining that product isn’t informing them effectively and delivering on what they need to be at their best in their role.
As a product manager, your job is to be a coalition builder. A large portion of your job is about listening and learning. You’re also challenged with building buy in and support for the things that you believe need done. Fortunately, that makes you perfectly suited to reset your relationships with other departments and stakeholders, regardless of who is to blame for past issues.
One of the phrases you hear commonly that PMs need to do is “Stakeholder Management”, which I think is a misnomer.
Your job is not to manage them. Your job is also not to keep them happy.
Instead, you should treat them like a Partner.
You share your goals with them and listen to theirs, so you can see where you’re aligned and work through areas where there may be conflicts.
You let them know what you need and what you’re working on so they can help you.
You treat them as a valued source of information, and share what information you have that could help or impact them.
You bring structure to your partnerships with them by thinking ahead, asking good questions, and communicating the information they must know based on their needs and role.
When they make requests, you genuinely listen and then explain your priorities so they understand how their requests fit in, or why you have to say “not yet.”
This is all instead of “Management”, which often means:
Fielding their requests
Trying to keep them happy, or avoiding conflict
Dealing with their frustrations or outbursts
Selling them on your product decisions
So the question becomes: How do you build stakeholder partnerships?
How to build Stakeholder Partnerships
There are 3 key ingredients that underpin all of the recommendations in the remainder of this post:
Empathy: Understand your stakeholders, and help them understand you.
Transparency: When both sides understand clearly the other’s goals, it gets easier to resolve conflicts.
Structure: Product managers should lead these discussions, and in doing so, there will be better discussions, and you will be less likely to have significant conflict.
If you’re looking to hit the reset button to stop managing stakeholders and start making them partners, here’s the key things to do:
1. Understand the needs and motives of your stakeholders
The first thing to do is to consider who your stakeholders are. Based on that, you’ll be able to think about what you need to get to know about them.
For example, if someone is in the sales org, we know:
Quota: They have a number they have to hit that will always be top of mind.
Closer’s mindset: When you tell them something, they’ll be thinking about it through the lens of how it will help them close more deals.
Successful customers: No one wants to sell a lemon, so they’ll be interested in being sure they’re selling something that will work for the leads they work to close.
Also keep in mind that depending on their level in the organization, they’ll be thinking differently:
VP: Is thinking about the high level number the entire organization has to hit, and how changes impact the entire organization. They’ll also likely be thinking more long term as they consider head count, and multiple future quarters numbers they have to build towards.
Director: Will be thinking about the sales team that reports to them. If that’s a specific vertical, territory, or other type, recognize it will change what they’re interested in and what they’ll be lobbying for.
Individual Contributor in Sales: They’ll be focused on their specific leads for their territory or vertical and their number to hit, and are less likely to be aware of things going on outside of their team. They’ll be the most short term thinking of all.
As you prepare for what stakeholders you’re going to engage, keep in mind what level they are in the organization and how that may impact what they need from you, what they may lobby you for, and how they can help you most.
If you’re unsure, the best thing you can do is ask a few questions to really learn what matters to them like:
What’s your biggest priority this quarter? (or next quarter if approaching EOQ)
How do you fit into your organization?
Can you help me understand how your responsibilities are part of your department’s larger goals?
Based on what I’ve shared we’re working on, who else should I talk to? Why did you choose them?
While the first few questions give you the foundation for your relationship with the stakeholder you’re talking to, the last one is really underrated; they can help you navigate the other departments more effectively as they’ll know who else to talk to who could be helpful, has been talking about things you want to learn about, or that complement what they share.
Most importantly: Don’t assume. It’s always better to ask and be sure, than make a guess and then jump to the wrong conclusions.
2. Consider them one of many inputs you have
You should be sourcing data, input, feedback, and information from all over. Just a few of an endless number of examples would include:
Data and analytics from Looker, SQL queries, your analytics tools, Full Story, heat maps, etc.
Support ticket patterns, bugs, and biggest pains from the Customer Success team.
Top reasons you’re losing deals from the Sales team and Salesforce reports.
Key requests from big and important customers from your Account Managers.
Market research and analysis as well as surveys and other data from Marketing.
Financial impacts to changes in pricing, payouts, and onboarding experiments from Finance and Ops.
Error and bug reports, site and specific page speeds, and overall health of your product from the Engineering team.
Usability issues and customer-product interaction problems from the Design team.
Insights from your own direct customer interviews, surveys, and feedback mechanisms.
A key skill of being a great PM is turning requests from these many teams into actionable, and prioritizable insights.
To do that, you need to develop the skill of asking them the right questions when they come to you with a request. Some simple questions that can tell you a lot include:
How often does this happen?
What is the root problem or cause you think that’s leading to this?
How does this impact customers? (What kinds of deals are we losing because of this? Are people churning or rage tweeting about it?)
How can you help me quantify the potential impact of the change you’re suggesting?
My priorities right now are to focus on [X]. Do you see a way this would help with that goal? How?
What you’re doing here is teaching them how to take their requests and put them into a format you can act on one way or the other (either address it, or have good reason not to). It also gives you a way to easily push back, because something is far outside your focus right now.
A Sales Example…
For example, if an Account Executive comes to you and says, “We really need to build X! I just lost a deal because of it!”
If you then ask, “How often does this happen?” and they say, “Well, it’s the first time,” you can easily then tell them:
“Okay. I understand it’s not fun to lose deals like this. If it happens 5 more times, I’ll sit down with you and we’ll go over all 5 deals to look for patterns and figure out what we can do to help.”
What’s particularly important here is you’re teaching them how you work. You’re not only letting them know the information you need, but also the threshold (“5 more times”) for it to matter to you.
I used such an approach with a past Customer Success team I worked with. That led them to only raise concerns for issues they had to address 10 or more times in a single month. This took me from getting dozens of requests every time we met to an organized list of 2-3 asks per month.
This proved to be a huge win-win:
We fixed their most important problems, reducing their time spent working around the same issues over and over.
Because they knew I was listening, they put in more work to organize the information I needed so I could quickly and easily take back the bug information to the engineering team to fix.
Your other department stakeholders can be a wealth of information, and even help you prioritize problems when you bring the right questions to the table, and teach them how you think like in the examples above.
Remember: “Not yet”, instead of “No.”
One thing to keep in mind is that constantly hearing “No” from the product team can be really frustrating, especially if they don’t feel like other things are coming fast enough.
That’s why a key phrase for you to remember is to say, “Not Yet” often.
When you say that, you can then explain your current priorities and reasoning to them. That will often help them understand why they have to wait for what they asked for. It may even help them remember something else they need that *is* related to your current goals.
3. Bring the structure to your relationship and every meeting
Every meeting you have with a stakeholder should have a purpose (or multiple).
Prepare an agenda and bring it with you to the meeting. Let them know so they can add things as well, and plan ahead for any questions you ask (especially if it involves asking for numbers or other data).
Most importantly, keep in mind you should be consciously driving the relationship.
By bringing an agenda, questions to ask them, and a plan for what you want to get from the relationship you will effectively make the switch from stakeholder management to building stakeholder partnerships.
Just like the Product Thesis challenges you to make sure you’ve thought through everything you need to kickoff a major project, following the approach outlined here in this post will help you think through everything you need to do with your stakeholders.
Take time to plan ahead, and the meetings with your stakeholders will go much better.
4. Iterate on the relationship as you work more with them
Stakeholder management is not one-size-fits all. You will need to adapt to their work styles, personalities, how helpful they are, and how relevant their work is to yours.
This is all likely to change over time, so be prepared to make changes accordingly. A few examples that you should keep in mind:
Frequency: Meet with stakeholders that are key to your project more often, and as they become less critical, meet less often. These recurring meetings are sometimes called Peer 1 on 1s.
Helpfulness: If someone is difficult to work with, and doesn’t add a lot of value to your efforts, consider if someone else is better to meet with in that department.
Triangulation: If another team is critical to your work, a single point of contact may not be enough, so consider getting multiple perspectives varying by seniority, focus, or other vectors that give you the best view.
Your Needs: When you’re doing exploratory research, someone who can introduce you to the perfect fit is most helpful. Meanwhile, when thinking strategically, someone more senior may be a better fit. Adjust and adapt accordingly
Over time, you’ll develop instincts around this, which will help you know who to reach out to and how often will be ideal to talk to them. You’ll also start to recognize what questions are best to ask each person you speak with.
If you’re new to this, or hitting the reset button in a big way, keep in mind this is a process. It will take time.
The goal of this post is to help you re-frame your relationships around this new approach, and you’ll work with them and your other stakeholders over time to perfect these partnerships.
Recap: Remember these 3 things
There’s been a lot in this post, so here is a reminder of the most important things for you to do to turn stakeholder management into stakeholder partnerships:
1) Set the rules and manage their expectations
Teach them to fish by setting thresholds for escalating to you vs. sending everything. Communicate why you choose that and be open to tweaking it with their feedback.
Frame the relationship by bringing an agenda every time and asking good questions of them. Over time they’re likely to start doing the same.
2) Show your thinking and priorities:
When they understand what you’re working towards, they can share ways to help you with insights, data, and introductions to key customers.
They’ll also understand why you may need to say “Not yet” to some of their requests.
But that only happens if you share it with them, so work to provide a concise overview of your work and thinking.
3) Get to know them and iterate:
When you build rapport with them, and listen to their needs, too, they’re more likely to have empathy for you as well.
You and their needs will change. Iterate on the frequency of meeting, topics you cover, how you explain your thinking, and questions you ask them to evolve the relationship effectively.
Tell them this is an iterative process as well, so they can help shape and improve them, too. You never know where a good idea or insight may come from!
Have questions? Leave a comment, or if you want hands on help for yourself or your product organization, you can learn more about my coaching and consulting here: BeCustomerDriven.com
To continue your learning to improve your stakeholder relationships, read these: