4 Common Misconceptions of Product Managers — How You Can Break Through Them
Product Management has become a holistic discipline that brings together business, design, and technology. Here’s how to encourage that view of the discipline — and discourage common misconceptions.
Product Management has come a long way since the days when it was indistinguishable from marketing or project management. The success of startups and large tech companies such as Google and Amazon and the rising profile of product leaders such as Marisa Mayer (former Yahoo CEO, Google Maps) and Panos Panay (Microsoft Surface) has led to a growing appreciation for the discipline. In fact, search interest in product management has doubled in the last five years alone. At its best, modern product management has become a holistic discipline that functions at the intersection of business, design, and technology to help teams drive towards product/market fit.
But despite all the progress, we’ve still got work to do as Product Managers to help leaders and organizations fully embrace a more modern view of product management. I know this because, while working in Product at BCG Digital Ventures, my colleagues and I have the opportunity to build new products and businesses on behalf of large corporate clients. From this unique vantage point, we are able to observe product trends and patterns across many client organizations at once.
Based on this experience, we’ve put together a list of four common misconceptions that still persist regarding product managers. For each misconception, we’ve provided our preferred reality and some concrete steps that PMs can take to break these misconceptions. We hope these are helpful for PMs and change agents as they navigate their respective organizations.
Four Misconceptions of Product Managers
Misconception #1: We are the feasibility or “IT” people
PMs are not always seen as a strategic business function and, particularly at larger organizations, we can get relegated to being viewed as a feasibility, “IT” or engineering-focused function, rather than a more holistic discipline that cuts across business, design, and technology. This can hinder our ability to have a seat at the strategic table with business stakeholders.
Our Preferred Reality: We are the product/market fit people
A PM’s superpower is to turn an idea into reality and to drive towards product/market fit. As part of this, we must balance what customers want, how an idea makes money, and technical feasibility. If we were just the feasibility people, the product would have a much lower chance of succeeding. By focusing on product/market fit, we can reframe our role from a technical or feasibility function to one that is more holistic and directly connected to driving business value.
Meet with business stakeholders at the outset of a new project to articulate the role of product in driving towards product/market fit. Here’s a set of talking points that can help drive the right conversation:
- Articulate the Problem Your Role Addresses: The number one reason businesses (and products) fail is because they solved a problem with no market need.
- Show How PM is Critical to Addressing this Problem: Building something is easy, building something that people want and use is hard (aka finding product/market fit) — our job is to work across disciplines to drive the latter.
- Build External Credibility: Don’t take our word for it. The PM is a critical function at the best unicorn startups (Airbnb, Uber, etc.) and they achieved success using the hypothesis and experiment-driven approach that we are advocating.
- Tie Back to Business Value: For these reasons, our success and activities will be measured by KPIs that link back to business outcomes and not just feature output.
Connecting your role to product/market fit and critical business outcomes in this way will help business stakeholders to see you as a strategic function that can drive value for the business.
Misconception #2: We lack “hard” skills and don’t own customer experience / validation / business model
Many people have trouble concretely identifying what a PM actually does. PM skill-sets also often overlap with other disciplines (ex. Business Development, Marketing, Design). This can prompt the question: “Engineers build, designers design — what do you do?”
Our Preferred Reality: We’re T-shaped and add value by applying product thinking across disciplines
Most PMs tend to be generalists that have broad knowledge across many different disciplines and deeper expertise in one or two functional areas (“T-Shaped”), such as engineering, design, or business. We can use this broad knowledge to our advantage by becoming the connective tissue across functions. The key is to first build empathy for each function on the team and then help them see how product thinking can enhance their role.
How to Break the Misconception:
Build empathy across a cross-disciplinary team by trying this quick exercise at your next project kickoff:
- Pair up each member of your team with someone from a different discipline (ex. marketing partners with engineering, sales partners with product, etc.) and break up into the two-person groups.
- Each individual in the two-person group covers the following for their respective function:
What are the top three critical things to know about your function?
What are the most common misconceptions about your function?
Can you teach something concrete related to your function (ex. line of code, etc.)?
- The two-person team then teaches the entire group, with each individual sharing the responses of their partner. For example, sales teach the group about product (based on the responses of their partner), product teaches about sales, etc.
Apply product thinking across disciplines to demonstrate value and build trust / credibility
- Share lean experimentation techniques with marketing or market research teams (if they’re not familiar) to demonstrate how they could go beyond traditional surveys by running live A/B tests and other experiments to connect user feedback with actual behavior. This is particularly relevant for marketing-led organizations or those that use Pragmatic Marketing.
- Run a design thinking workshop with business to generate and prioritize new ideas.
- Share rapid development tools and frameworks such as Bubble.is with engineering.
- Work with legal and security teams to develop a risk-based approval process to reduce time to market.
Ultimately, teams will best understand the value of product if we can show them, not just tell them. This may require some time and a deep enough understanding of each person’s role on the team to speak their language, but it’s worth the effort if done right and can quickly make you a go-to member of the team.
Misconception #3: We are the people who say “no”
A PM is often managing multiple stakeholders and tight timelines. This means that we are often the ones saying “no” and can become known as the “rules police.”
Our Preferred Reality: We ruthlessly prioritize to ensure success
PMs are on the hook to build, launch, and learn from customers, so continuously adding features without validated reasons will hurt the company as a whole. We make decisions based on priorities and evidence to keep everyone focused on the most important priorities, so saying “no” is actually priority and evidence driven, not by emotion or gut feeling.
How to Break the Misconception:
Articulate the why behind the “no” and include team members and clients in the decision-making process so they appreciate the tradeoffs. In your next roadmap or high-level planning meeting, be sure to include key stakeholders from the sales or business teams and try the following exercise:
- Start by reviewing the overall goals of the product or feature and what you’re solving for.
- With the group, develop a list of potential customer problems to address along the customer journey and brainstorm corresponding high-level feature ideas.
- For each feature or categories, work with the group to assign a rating from one to five for each of the following: Business Value (BV), Customer Value (CV), and Level of Effort (LE, estimated). You can also assign an overall score to each feature based on the following: Overall Value = (BV + CV)/LoE. Note that this is just a data point intended to help drive discussion, not a hard and fast rule for prioritization. Ultimately, prioritization is a subjective activity based on a number of strategic considerations, not just one set formula.
- Work with the stakeholders to prioritize product features to optimize for customer value, strategic fit, and level of effort. Keep in mind any critical product or business assumptions that you are trying to test with a particular release, so you can prioritize to maximize learnings and not overbuild and ensure that the prioritized features for a release complete a core user journey.
- These high-level prioritization conversations will inform more detailed planning and estimation conversations with engineering. Repeat this exercise regularly to ensure ongoing alignment.
For visually communicating these priorities back to larger stakeholders, try a two-by-two bubble chart (Customer Value on Y-Axis, Level of Effort on the X, and Business Value as the size of the Bubble).
By involving key stakeholders in the tough tradeoff decisions, you can help drive alignment and help them to understand the rationale behind your decision-making.
Misconception #4: We are feature builders / roadmappers
People think being a PM is about building lists of features. We are often asked to provide detailed feature roadmaps for long time horizons that encourage waterfall thinking, rather than a true hypothesis-based product development approach.
Our Preferred Reality: We drive the vision and build a plan that responds to market feedback
Since the market and its needs are constantly changing, PMs need to adapt the product with the market. Hence, we should not be building off a checklist of features. Rather, we have a hypothesis driven mindset to help the company continuously de-risk and evolve with the market.
How to Break the Misconception:
Try a thematic roadmap instead of a feature roadmap to anchor stakeholders on general themes and customer problems rather than specific features.
- A traditional feature roadmap with fixed dates and specific features can prematurely lock you into specific solutions.
- A thematic roadmap frames the plan in terms of the problems and themes that will be tackled at a particular point in time. Rather than fixed dates, it has general time horizons, focusing on “Now,” “Next,” and “Later.”
- Including a confidence level also helps to articulate that these features are not set in stone and will be dynamic.
By focusing on themes, you can provide your stakeholders with directional clarity, while still giving yourself flexibility to adapt and respond to market feedback.
For more on thematic roadmapping, check out this great article Feature-less Roadmap: The Balance Between Delivering Concrete Features vs. Planning with High-level Themes by Victoria Fitoussi on the Amplitude blog.
Product has come a long way in the past 20 years. For the community of Product Managers who believe in the discipline and want to see it continue to grow and evolve, we must keep breaking through misconceptions. This means continuously applying a product lens and using concrete frameworks to add value and drive business outcomes across our many interactions at all levels of the organization. As a simple example, I’ve seen dramatic shifts in mindset in short periods of time when our corporate partners are exposed to product concepts such as hypothesis-driven thinking and lean experimentation. As all of us continue to push the envelope on product thinking within our respective organizations, Product will continue to grow in importance and fully secure its place as a strategic, holistic discipline that is critical to both large and small organizations.
We would like to hear from you! What are the misconceptions you’ve encountered as a PM? And what frameworks and tools have you used to break through them?