What Makes a Product Manager Great
“Being a Product Manager is a lonely job,” one of my colleagues quipped, and given how often we eat at our desks, I’d say we have the data to back up that claim. However, it’s also one of the most satisfying jobs out there, and we can also back up that claim with the elation you feel when a customer raves about a feature you released, or when you see a revenue graph climbing the proverbial “up and to the right”. But what does it mean to be a Product Manager (PM), and how do you go from being a good one to a great one?
As to be expected from a job that’s nebulous in nature, the answer to that question is just that — nebulous. Of course, being data driven is a necessity, and you need to be a decisive and strong communicator. You’re like the much touted mini-CEO for your product — you need to keep things moving forward, make sure everyone’s aligned, and measure impact.
But there are other qualities I’ve noticed during my seven years as a PM at SurveyMonkey and VMware that truly take your impact to the next level, and I’d put these 5 tips at the top of my list for any PM to keep in mind.
Master these three types of empathy
I recently read an article that talked about different kinds of empathy, and a light bulb went on in my head. I’ve always understood having empathy is important as a PM, but learning how to talk about different kinds of empathy really drove the point home.
- Cognitive empathy, or perspective-taking, is when you put yourself in someone’s shoes and see the world from their perspective — without feeling their emotions.
- Emotional empathy is when you can identify or feel someone else’s emotions and see their pain points.
- Compassionate empathy goes one step beyond emotional empathy — it’s when you’re moved to act or help based on how someone is feeling or what they’re experiencing.
A PM needs all 3 types of empathy in varying amounts depending on the situation. For example, you need cognitive empathy when you’re trying to monetize your product and need to understand how the user personas you’re targeting perceive its worth — you are not necessarily looking to understand their emotions but rather trying to decide what the product is worth from their perspective. And when you’re prioritizing a backlog and assessing a bug impacting a particular user segment, tap into compassionate empathy. Is it really something you should push out to a future sprint, or should you prioritize it? Have you walked the metaphorical mile in their shoes?
So how can you develop empathy? Talk to your customers, and more importantly, listen to them! Invest in user research, both quantitative and qualitative (SurveyMonkey ftw). Quantitative research helps you identify product issues and opportunities at scale and determine their pervasiveness, while qualitative research allows you to really zoom in on the workflows and validate specific ideas with a smaller group of users.
Another way to be empathetic, is to really know your product inside out. You have to be a subject matter expert of your product and if possible, use it on a regular basis. Nothing contributes to developing empathy more than personally struggling through a product flow.
Lastly, develop personas for your product — these are fictional, representative users that denote a certain section of your user base. These could be based on use cases for the product, demographic or firmographic attributes or something else. Personas help to humanize your users and enable you to build products based on the motivations of what these personas are hoping to achieve from your product.
Tune into the company strategy
Back in 2014, I worked on a partnership with one of the Android Original Equipment Manufacturers (OEMs). As a newly minted PM, I set out to make this partnership and the product a success. I worked hard to ensure the integration was developed, launched, and marketed in an optimal way. Fast forward 6 months, and I was still working on optimizations for OEM partnerships, among other things. One day, my VP came over and asked me what I was working on. I told him about the OEMs improvements, and he goes, “Oh, is that still a thing?” I was so entrenched in the project that I failed to see it was a build-it-and-move-on type thing and stopped being a company priority 6 months prior! Ever since, I diligently make sure I fully understand how my product ladders up to the company’s goals.
Throughout my career, I’ve seen a number of talented PMs with incredible teams go off-track just because they failed to identify fundamental shifts in the business and how it impacted their product lines. Sometimes inefficient communication is to blame. But in many cases, I’ve seen it attributed to (1) getting stuck on a project that’s close to their heart, so it’s hard to pivot away from, or (2) the PM not having the courage to tell the team the project isn’t a priority anymore.
So what can you do? Be aware of, and truly internalize, the company OKRs. Share them with the team, and refer to them regularly in conversations. If a project is close to your heart, make sure to create a solid business case for it that you share with company leaders. And create a rapport with the team, so if you need to deliver tough news when there’s a pivot, it doesn’t feel as daunting.
Remember you’re a leader, not a manager
You often hear PMs say, “It’s hard to lead the team when they don’t report to you”. And yes, it definitely is, but accomplished PMs, and leaders in general, agree that there’s one key ingredient to good leadership — trust. Connection at a human level plays a key role in leading a team, and a shared sense of trust is an intrinsic part of creating that connection.
In my view, trust comes from three things: being communicative, having each other’s back, and celebrating the wins together.
- Of course, good communication is easier said than done. I’ve definitely been guilty of not being communicative enough when I’m busy, but that’s no excuse. I know the value and impact the team can make when we’re all communicating, and making an intentional effort is critical. Identifying when communication is breaking and making time to find solutions is the first step. Teams work differently and once you find the best communication channel — it makes all the difference.
- Having each other’s back comes easily when everything is going well, but it’s much harder when things aren’t going well and people start to point fingers. An interesting and effective strategy is when companies or teams have a no blame policy. If you have the power to implement this, I highly suggest it, but make sure the team understands what it means to be accountable. If you can’t implement a no blame policy, you can create a culture of confronting the problem not the person. Retrospectives are a great way to eek out underlying problems with collective discussion.
- Celebrating wins together strengthens team camaraderie. A team that celebrates together wins together and hence a team that wins together should celebrate together. This is the easiest to implement, but also the easiest to forget. Celebrate product wins, but more importantly celebrate people. And do it often — sometimes it’s even on the company dime. 😉
Be comfortable with ambiguity
This is one of the most underrated skills a PM can have. Designers and Engineers would love for requirements not to keep changing at the drop of the hat. And yet, as many PMs can attest to, keeping requirements locked down is not always possible, especially when you’re working in an agile environment, and doing your upstream diligence of crafting data-driven, customer-validated and strategy-oriented requirements.
Depending on your level, there’s a ton of upstream ambiguity a PM is expected to unriddle before handing over the hallowed requirements. And even as you socialize the requirements with your cross-functional team, you’ll uncover edge cases, dependencies, or more requirements. New information from a competitor’s release may cause you to pivot your strategy. Legal or security teams may uncover compliance issues with your feature. Database and infrastructure considerations may cause you to change your requirements. So how do you adjust to the ever-changing landscape and keep the team focused on the release?
A few things come to mind. Keep an open line of communication with the execution team and with cross-functional teams to iterate rapidly on edge cases and missed requirements — there will, undeniably be a few (if you are one of those who never have some, SurveyMonkey is hiring 😉). Learn to say no, then you can say yes to the most important things. Release an MVP wherever possible — it’s always better to release and learn and release more, than to put in a massive effort up front only to learn you were way off track with the product-market fit. Above all, embrace ambiguity — chaos is a teacher!
Stay curious and be fearless
Running experiments is integral to the job of a PM — defining big-swing hypotheses, supporting claims with data, carefully picking cohorts, and pushing ideas out the door, all within a week’s time, to test. To do this well, you need to stay curious and be fearless.
Stay curious. Curiosity helps you explore different ideas. Think about what might happen if you push the envelope on what’s considered the norm. Give yourself space to create highly-impactful hypotheses, and allow your team room to brainstorm solutions.
Be fearless. Fearlessness allows you to go out and implement ideas. Don’t be afraid to actually get out there and test, put ideas in front of users. Encourage the team to be brave with their solutions. Sometimes you’ll be proven right, and others you’ll need to stomach the results if they’re not what you expected. But that’s okay! Learn from them and go on to the next.
Once Chris Small, Director of Growth at SurveyMonkey, quoted an article he’d read, “hypothesis is not a prediction, but a belief.”
This really resonated with me when it comes to making a hypothesis. Trust that your ideas are rooted in sound understanding of the users and the business (this is where all the user research and competitive research comes handy), and remember that if you’re limiting the hypothesis, then the outcomes will most likely be limited as well. Take big risks to get big gains.
In summary, these are some of the characteristics that might not be on a PM job description, but I’ve found to be just as essential. Whether you’re just starting out or a little more seasoned, but still learning like me, I hope these learnings are helpful. If you have other ideas, feel free to comment below. I’d love to hear what you think!
I want to take a moment to appreciate the work done by my colleagues at SurveyMonkey on this article. Huge thanks to Chris Chan, Irene Falgueras, and Jasmine Rosen for helping steward the blog, Lizzie Burns for her writing tips and feedback, and to Marco Bakker for the beautiful illustrations.
