What It Takes To Be An Exceptional Product Manager

A holistic approach to PM Core Competencies

In 2016, I applied to be an astronaut in the most recent Canadian Space Agency Recruitment Campaign.

While I didn’t get selected, I did get through initial rounds and it really opened my eyes to not only the type of characteristics and skills NASA/The CSA look for in people that they think will make great astronauts, but also to the parallels that exist between being fit for space and what it takes to be an exceptional product manager.

This is an excerpt from the Canadian Space Agency:

Notice any similarities?

My thinking on what it takes to be an exceptional PM has been shaped largely from my experiences working across very small early stage startups, mid-size startups, and a FAANG/MAANG/MAMAA company, being PM #1 at a startup, and working as a product coach to junior and mid-level PMs. It’s also been influenced by some great product thinkers like Ken Norton and Shreyas Doshi.

This list is general intentionally and is intended to be used as context for anyone getting into product management, those already knee-deep in their careers and looking to upskill, and product leaders figuring out what qualities to look for in PMs to build out their teams.

I’ve broken it down into five key buckets:

1. Human Skills

These are the things that are often called “soft” skills or “intangibles”. It’s hard to teach them. You mostly have to learn from life experiences, putting in reps in various circumstances, de-briefing with yourself, and above all, having a growth mindset to WANT to learn and grow in these areas from these experiences. This includes things like being/having:

Empathetic and emotionally intelligent
Self-aware
A growth mindset (I think of this as “ABL”: Always Be Learning)
Curious and able to ask great questions
Creative and able to be a divergent thinker
Self-driven and able to take initiative
A quick learner
Adaptable
A critical thinker and analytical
Calm and focused under stress — having an internal locus of control
Grit — the ability to overcome failure and setbacks and reframe them to be positive and growth-provoking experiences that get you to your North Star
Someone who thinks in terms of service to others — how are you using your skills and the things you care most about to help others?
Ethical

2. Foundational Skills

These are the skills that build on your human ones — the things that help you get the most out of the efforts you put into things, and to choose the right things in the first place to put your efforts into. They include things like being a good:

Problem finder — able to find meaningful problems to solve
Stitcher — able to easily identify ideas and concepts that are related and bridge any gaps to bring them together
Time manager — able to make good, conscious decisions about how you use your time (this includes the ability to say, “No” if something doesn’t mesh with your priorities)
Researcher — the ability to find, consolidate and organize large, disparate pieces of data into digestible, easy to synthesize information
Data analyzer — the ability to look at data and extract relevant and meaningful information (i.e. “Why is this important?”, “How was this measured?”, “What does this mean?”, “How big of an issue is this?”, “What can we do based off of this?”, “What levers do we have?”)
Problem framer — the ability to ask eigenquestions and to pre-emptively identify constraints and potential constraints (i.e. what kinds of things to think about and what kinds of questions to ask to create a clear “sandbox” with guardrails to define the problem very clearly)
Risk Assessor — the ability to understand actual and potential risks tangibly, to make decisions based on your risk assessment, and to know what questions to ask to better assess risk
Entrepreneur — having basic business skills and an entrepreneurial spirit (i.e. Understanding how to generate value for customers, economics, marketing, finance, sales, business analytics, etc.)
Problem preventer — understanding how to pre-emptively conduct mortems to identify things that CAN go wrong to put plans in place to address risks early and prevent these things from happening
Reflector— understanding, retroactively, what went wrong with an objective and critical eye through post-mortems and retrospectives, to know specifically where to focus efforts to improve
Self-controller — Knowing when to push, pull, or get out of the way
Subject Matter Expertise — While having a deep subject matter expertise isn’t always required to get into a product management role, it definitely helps. If you can be a T-person — that is, to have a set of broad skills to form the top of the T and a set of deep expertise that form the vertical portion — you will have a distinct advantage.For example, you could be a PM with deep subject matter expertise in health tech, fintech, wearables, AR/VR, machine learning and computer vision, e-commerce, mobile apps, cloud software, hardware, operations, and the list goes on. Having this backbone will help you in terms of making decisions because you have greater relevant context with anything from positioning to figuring out what features to prioritize, when, to maintain a competitive advantage, in what to include as requirements when you are writing a PRD, or constraints you need to think about to develop a product in the space (i.e. regulatory).

3. Team Skills

No matter how good your human and foundational skills are and no matter how deep your subject expertise, unless you’re a solopreneur, you won’t even scratch the surface of your potential unless you’ve got the ability to work well as part of a team, but also as a leader of a team. I’ve written extensively about team skills — everything from cultivating an exceptional team, to stakeholder management to how to lead meetings with teams — and truly believe this is what makes or breaks great products from existing. Some of the things you need to be good at to work well with groups of people include:

Information synthesis — the ability to take in vast amounts of information and parse it to distill its meaning
Efficient communication — the ability to clearly and concisely exchange different types of information with different groups of people so that everyone understands
Ability to “speak multiple languages” — the ability to know how to communicate what depending on who you’re communicating with (i.e. knowing how to explain a problem to an engineer vs. the CEO vs. a designer)
Storytelling — the ability to share information in a way that creates emotional connections between the information you’re sharing and the people you are sharing it with
Collaboration — facilitating discussions and brainstorming sessions early, knowing who to bring in for input, when, valuing the contributions of others, and making others feel included
Team building — the ability to hire and build an effective team from the ground up
Alignment across teams — understanding how to approach getting the people around you to agree on a path forward, whether it’s leadership, your direct development team, design team, marketing, etc.
Leadership — the ability to paint a picture of what the future looks like and light the way for the team to get there in practical and achievable ways
Asking for help — the ability to acknowledge when you need help, and knowing how to ask for the right kind of help in the moment
Listening — knowing how to stay present, be connected with who you’re communicating with, and actively retain important information
Asking for alternate perspectives — the ability to bring others in to think divergently, to ask questions like, “What am I missing here?” “Is there a better way?”, “Please poke holes in this plan so we can make sure we’re on the best path”
Recognize contributions of others — both 1:1 and publicly

4. Product Skills

THESE are the skills most people focus on. But I would argue that the ones I have already mentioned are the most important to focus on, first. Foundational product skills can be learned over time and with experience and build on human, foundational, and team skills. I wrote an article about the order of operations to take a product from 0 to 1 recently that describes starting at the base of the pyramid below and working your way up from there.

To me, foundational product skills are things like:

Problem finding and framing: Deciding WHY something needs to be built
Product discovery: Deciding WHAT to build
Product execution: Deciding HOW to build it
Product processes: Figuring out the most efficient ways to work together to build it
Working with other PMs, designers, engineers, and other key stakeholders in different job functions
Measuring success: defining what success looks like in a tangible way, and setting and analyzing performance metrics
Product vision
Product strategy
Product pillars
Product roadmaps
Prioritization and making informed product decisions
Product requirements and specifications
Defining scope
Competitive landscaping
Product pricing
Product marketing
Go-to-market strategy
Scope reviews
Product launches
Organizing and running Alpha and Beta testing
Conducting user interviews
UX and design best practices
Voice of the customer
User research
User interviews
User experience
Customer journey mapping
Understanding the product life-cycle
Usability testing
Mock-up and prototype development
Choosing and adapting frameworks, processes, and workshops to fit your product strategy, roadmap, goals, and product team (i.e. Scrum, Kanban, Shape Up, Design Sprints)

5. Technical skills

This is a controversial one.

While there are lots of schools of thoughts on this (i.e. A Technical Guide for Product Managers and The Top 5 Things PMs Should Know About Engineering) here’s my current thinking:

Knowing more about your particular product tech stack/tech used in the industry you work in is always better. But you also don’t need to have an engineering background or know every nut and bolt to be able to do a great job.

The main things you need to be exceptional at from a technical perspective (IMHO) as a PM are:

Developing great relationships 1:1 with technical leads and design leads — take the time to build meaningful connections and trust. Work to understand how they think, what they care about, and what drives them so you can form a great team and leverage each other’s strengths.
Understanding how all of the pieces fit together and what role they each play in the greater product (i.e. tools used, language, and infrastructure, and how they all fit together and communicate). Two resources that can help here for non-technical PMs are Tech Talk for Non-Developers and Technically.
What the design, development, and release process looks like — this can apply to both hardware and software
Understanding how to translate well across languages — this covers everything from taking business requirements and turn them into technical requirements or design requirements, to understanding what hardware changes mean for firmware and software, to understanding how to communicate a small change in design to a technical change that is now required because of that design change.
Understanding and articulating impacts and what they mean — when evaluating paths forward, potential changes to the plan of record, updating the roadmap, etc. you absolutely need to be able to understand what the technical implications are and what these mean for the greater business and other individual teams (i.e. Does a marketing plan hinge on a product feature that’s extremely risky? What if we can’t make it happen? What can we do as a backup? If we decide to change how we handle security, what does that mean for the customer? What does that mean for our business? If we change the interaction model, what impacts does this have not only on the visual design of each individual screen, but also software changes that may be required as a result?)
Understanding and articulating risks, both up front and along the way as the product is being built — if a particular implementation choice is is high vs. low risk, if a particular decision is made that involves many unknowns, or if you’re working with a brand-new technology that hasn’t been tried and tested, these are absolutely things you need to know to be able to make informed product decisions
Knowing which questions to ask, who, how, and when in order to highlight and prevent potential issues
Bringing technical leads into discussions early to identify challenges, assumptions, risks, and unknowns as early as possible so they can be included and addressed in discussions, inform product vision and strategy, roadmap decisions, and individual product requirements
Accounting for tech debt — being aware of how much tech debt is being accumulated and what the implications are of working on this now to fill in the gaps vs. putting it off until later

What do you think? What’s missing from this list? Let me know in the comments below.

-Lisa

Follow me on Twitter: @lisazane15

🧠 Join 800+ people interested in building products and their product careers more consciously: https://www.consciousproductdevelopment.com/newsletter