The Expertise Trap: Why Knowing the Domain Doesn’t Make You a Product Leader

A project manager attempting to lead a meeting with a team of three other people

This article is a contribution to the Agile Product Management Initiative, which brings together Agile and product communities to improve how product leadership, discovery, and delivery work together.


TL;DR: Great products aren’t built by the ones who think they’re right, but by the ones ready to learn what’s wrong. 

In this article, we’ll explore why deep expertise doesn’t automatically translate into great product leadership and how SMEs can thrive without becoming bottlenecks or accidental blockers of innovation. 

Here’s what we’ll unpack: 

  • Product leadership is not a knowledge competition; it’s a discovery mission
  • How product leadership sits at the intersection of multiple disciplines
  • When SMEs unintentionally prevent discovery and innovation 
  • Uncovering unknowns: how product people succeed 
  • The expertise trap: how cognitive bias distorts product decisions 
  • Trust, innovation, experimentation: the role of Gen Z in shaping future products
  • How product owners and SMEs can become powerful partners 
  • Where SMEs bring depth, product leaders bring direction 
  • Product managers don’t need to be technical to be great 
  • Two successful career paths for SMEs in product-driven teams 
  • So, can SMEs be great product owners? 

The person who knows the most about the past isn’t always the right person to build the future. 

Can subject matter experts be good product owners? 

It depends. Generally speaking, the harsh reality would make us say that the answer is “no.” Being a subject matter expert (SME) is not enough to suddenly and magically become a good product manager or product owner. Or even a decent one.

The most dangerous person to put in charge of a product is the one who believes they already have all the answers because they know the domain. Experience builds confidence, but confidence can silence curiosity, and without curiosity, innovation dies. 

Amazon wasn’t built by bookstore owners. Netflix wasn’t built by Hollywood producers. Uber wasn’t invented by taxi drivers. Airbnb wasn’t started by hotel chains. Spotify wasn’t created by record labels. And PayPal, Stripe, and many other successful fintech companies weren’t launched by banks.

The products that reshaped entire industries did not come from the obvious experts inside those industries but from outsiders willing to question what the experts took for granted. And that leads to an uncomfortable truth: subject matter expertise alone does not qualify someone to lead product strategy. 

So, could subject matter experts ever be great product managers or product owners? Absolutely. But only if they are ready to evolve, to trade certainty for curiosity, and expertise for empathy. Product leadership is a journey, not a credential. 

Product management is customer advocacy, strategy, and change leadership 

Product management is a set of organizational practices, strategies, and principles that guide every step of a product’s life cycle (from inception to design, development, testing, release, positioning, pricing, post-production, maintenance, and beyond) by focusing on the product and its customers first and foremost. 

To build the best possible product, product managers advocate for clients within the organization and make sure the voice of end users is heard and valued. 

Thanks to this focus on the customer, product teams iteratively ship better-designed and higher-performing products. In tech, where products are quickly improved by newer and better solutions, there is more need than ever for an intimate understanding of users and the ability to create tailored solutions for them. That’s where product management comes in and where agility becomes an accelerating ingredient. 

Product management is not the mastery of a single domain, but the art of balancing many, and sometimes contradictory, realities. Product management is the responsibility of imagining and guiding what should exist tomorrow. It requires balance and skills across business, user experience, and technology, requiring empathy, storytelling, market awareness, and the ability to influence without authority. If you think about it, product owners are not rewarded for what they know, but for the value they help a team discover and deliver.

Venn diagram showing Product Management at the center where three circles overlap: User Experience (UX), Technology (Tech), and Business. Overlapping areas are labeled Experience Design between UX and Tech, Market Strategy between UX and Business, and Technical Strategy between Tech and Business.

Expertise in the domain is not expertise in the product 

Subject matter experts understand every rule, tool, and mechanism of their field. They possess depth. However, product leadership also requires breadth: vision, adaptability, collaboration, discovery, strategic prioritization, and commercial thinking. It demands comfort with ambiguity and a focus not on being right, but on learning fast. Accepting that failure is part of the learning journey is far better than getting stuck in disappointment when our knowledge fails us. 

You can be a brilliant clinician and still create a healthcare app that fails patients. You can be a gifted educator and build a school platform that students hate. Being an expert in doing the work isn’t the same as being an expert in creating tools for those who do the work. Expertise is a tremendous flashlight. But products often require us to explore beyond the known.  Product people need to master the science, strategy, and tools to do that. 

An academic or lecturer may have impressive knowledge but not be familiar with prioritization strategies, exploratory tools, brainstorming practices, the Johari Window, user journeys, or Design Thinking, which requires mastering different activities and tools (e.g., empathetic listening, brainstorming ideation, fast prototyping, action set group, liberating structures, etc.) which go beyond the SME or the PM, as some of these require working in teams and being guided by a coach or facilitator. 

Diagram titled “Stanford d.school Design Thinking Process” showing a left-to-right flow of five connected hexagons labeled Empathize, Define, Ideate, Prototype, and Test. Each stage includes example activities: Empathize with interviews and observation; Define with personas, objectives, and pain points; Ideate with idea sharing, divergence and convergence, and prioritization; Prototype with mockups, storyboards, and rapid iteration; and Test with learning what works, understanding impediments, role play, and quick iteration.

Can you know too much to build something new?

Knowing the answers is not a product skill; asking the right questions is. 

Subject matter experts are often hired and respected for having answers. Product people succeed by uncovering unknowns. When someone believes they already understand what users need, they stop asking questions, and that is when risk multiplies. So, can SMEs be great product people? Or are they too busy protecting the past to build the future? 

Product leadership is fundamentally a learning role. It is not about validating knowledge; it is about questioning it. Not about defending assumptions, but testing them. The moment a team stops listening to customers and users, they begin building for themselves instead of the people they serve. 

A product could go live smoothly and still fail if it solves the wrong problem. This may be due not only to overvaluing domain experts’ views but also to technical experts’ views. In a world where information has been made largely consultable and cheap (public libraries, Internet, Wikipedia, Stack Overflow), and now immediately available (apps, AI LLMs, vibe coding), holding tons of notions on a topic is not enough anymore. And knowledge alone was never a critical skill. 

The expertise trap: When knowledge becomes resistance 

The strengths that make SMEs invaluable can also turn into dangerous blind spots.  Overconfidence can make us prioritize assumptions over evidence. Anchoring can make familiar solutions feel like the only solutions. We cling to the status quo because we helped create it. We resist change because change challenges identity. 

In environments where authority is given to whoever has the longest tenure or deepest credentials, teams stop experimenting and start obeying. Decisions come from hierarchy instead of insight. In such cultures, innovation suffocates quietly. 

Agile coaches, leaders, and product facilitators are essential to help expose and address these patterns. They enable teams to see when experience becomes ego and reconnect decisions to learning. 

Let’s look at what science says. 

Psychologists have identified over 180 cognitive biases that systematically distort human thinking. These biases are commonly grouped into four families: 

  1. Too much information: We filter aggressively and miss critical signals
  2. Not enough meaning: We fill gaps with assumptions and past experience
  3. Need to act fast: We jump to conclusions to feel productive 
  4. What should we remember: We misjudge what really matters 

Domain experts, because of their depth and experience, are most vulnerable to the first two: information overload and over-interpretation through expertise. When you have a lot to process and a lot to protect, your brain tries to simplify. That’s where things go wrong.

Here are the most common cognitive traps SMEs fall into when they step into product leadership roles: 

  • Overconfidence bias: Assuming knowledge automatically equals correctness, so user research becomes optional (“We already know what they want.”) 
  • Anchoring: Fixating on familiar solutions and rejecting creative alternatives
  • Status quo bias: Defending “how things are done” instead of exploring what could be better 
  • Novelty aversion: Seeing new ideas as unnecessary risk rather than opportunity
  • Confirmation bias: Embracing only evidence that supports existing beliefs, ignoring contradictions 
  • Authority bias and HiPPO effect: Believing expertise gives your opinion permanent priority over customers, data, and discovery 
  • Familiarity heuristic: Oversimplifying complexity because “I’ve seen this before,” even when the market has changed

These aren’t weaknesses of intelligence; they’re just some side effects of expertise. The more we know, the harder it becomes to learn. And a product team that stops learning becomes irrelevant. That is why subject matter experts can be indispensable contributors to product success but risky product decision-makers unless they actively challenge their own assumptions. 

Experts know the rules. Product people break them. 

Innovation comes from those willing to challenge expertise. Experts understand the rules. Innovators question them. Companies don’t fail because they lack intelligence; they fail because they trust what has always worked more than what might work next. “This is how we  do it!” “This is a very regulated environment, we can’t innovate!” Meanwhile, users, especially Millennials, Gen Z, and the emerging Gen Alpha, continually reward products that rethink established norms, not reinforce them. 

Innovation comes not from the people most invested in the past, but from those most excited about the future. Great product leaders are future-oriented. They imagine before they optimize. They explore value, not just feasibility. That is why disruption comes from openness, experimentation, safety, and not (just) credentials. 

Of course, this is not an invitation to establish the dictatorship of product people. On the contrary! Separating deep knowledge from broad skills, we advocate for more inclusive teamwork where all voices are heard. At the same time, the good PM is able to balance needs, take responsibility for their decisions, take risks, and innovate. The team and stakeholders need to trust the PM, who, like every human being, will make mistakes. Similarly, the PM needs to understand the team’s, advisors’, and stakeholders’ reasons, using their expertise as an extension of their own knowledge. A super brain. A company’s collective intelligence. 

Expertise and product leadership: different responsibilities, one purpose 

Product success requires the full orchestra to participate and bring the best of their skills. Like conductors, product people need to listen to the various experts and coordinate requests, vision, and execution in a harmonious way. Imagine an orchestra where we would only hear drums because they have more years of music experience than any other peer. Or where a young, talented violinist is scared to use his full potential. The role of the product manager, as distinguished from a people manager, provides, together with transformational coaches, one of the best contributions to boost team experimentation and safety. 

The product lead integrates many voices, including the SME’s, to guide direction. The SME enriches understanding, reveals complexity, and informs risks. Each contributes from their strength; neither replaces the other. Tension arises when SMEs feel product decision-making should belong to them because they “know the field best.” But product leadership is not about who knows, it is about who learns. 

On the other hand, considering that nowadays the tenure in a role or a company rarely goes beyond 3–5 years, it is obvious that a good product owner will need to be able to navigate different sectors and areas, especially because many companies still keep including obsolete non-competition clauses that would forbid POs to change employers while remaining in the same role and competing sector. 

So, that’s why a good product owner will be good regardless of the specific sector, industry, or area they work in. Of course, someone with a great attitude to learn fast and self-motivate would have an exceptional advantage. Once again, these are key qualities and attitudes with nothing to do with the PO’s familiarity with a specific subject. You don’t need a pedigree to be a good PO. A different story is when someone (SME in a field or not) decides to start their professional journey to become a good product owner. A pure product manager not curious about the domain of application of their product or service will not be a decent product manager, no matter how many badges collected. 

Better together: Product people and SMEs as partners, not competitors 

Stop arguing about who brings more drama (or apparent value) to the team! A product team is never short of expertise. Architects bring technical foresight. UX researchers understand user behavior. Legal and compliance ensure safety. Marketing brings positioning and messaging. Operations and DevOps understand delivery realities. And domain experts ensure the product respects the logic of the industry it serves. All of these perspectives are essential, but they are not identical, and they do not always agree or need to agree. 

If every subject matter expert were permitted to lead product decisions based solely on the depth of their expertise, we would end up with multiple captains trying to steer the same ship in different directions. Agile frameworks evolved in part to avoid exactly that. Nowadays, building products and services requires a single point of accountability for product people to decide fast, take risks, and responsibility (without waiting for dozens of RACI matrix members or change approval boards), the product manager or product owner, precisely because product leadership is not a 1:1 debate with each expert. It is a one-to-many coordination effort. Someone must reconcile competing truths, and that’s the PM. 

“If every subject matter expert were permitted to lead product decisions based solely on the depth of their expertise, we would end up with multiple captains trying to steer the same ship in different directions.”

Some Agile frameworks provide systemic strategies to facilitate this coordination, providing clear accountability for the cycles of WHAT and HOW. The PM is responsible for building the right product. The Agile coach helps the organization to understand how to build it in the right way. The product role is designed for the coordination of the “What,” while the Agile coach coordinates the “How” (at least until the team can get mature enough to do it by themselves).

Where SMEs bring depth, product teams bring direction. The product manager is responsible for value outcomes, navigating trade-offs, and aligning customer needs with business strategy. They integrate the voices of many instead of amplifying the loudest or most senior. 

When SMEs step beyond their advisory space and attempt to own product direction, risk rises quickly. Stakeholder balance collapses into turf defense. User needs become secondary to specialist preference. Feature lists multiply because every expert wants “just one more must-have.” Assumptions dominate because authority replaces discovery. The product becomes optimized for internal correctness rather than customer value. 

But when SMEs collaborate with products as trusted advisors, something powerful happens instead. Risks are identified early. Complexity is made visible, not hidden. Opportunities are better understood. Decisions improve through dialogue rather than dominance, command, and control. Ownership becomes shared across the team, without diluting accountability. 

The product manager makes sure we are building the right thing. SMEs make sure we are building the thing right. They protect different forms of quality. And the product needs both. 

Product leaders don’t need to be technical, but they do need to  be curious 

There is a common misunderstanding in Agile teams: if product owners don’t need to be technical, then their job is simply to write stories and leave the “real work” to engineers and experts. That’s a dangerous interpretation. The point is not that a product owner should ignore technology. The point is that technical knowledge alone is not what qualifies someone to lead product decisions. A product owner succeeds not by knowing how the system works, but by knowing why it should exist and what outcomes it must deliver. 

However, this does not give product owners permission to disengage from technical conversations. On the contrary, it requires them to lean in with genuine curiosity, asking questions about feasibility, risks, integration, performance, security, data impact, scalability, and long-term sustainability. Their job is not to dictate how to build, but to deeply understand the implications of every choice, and to make informed trade-offs in service of value.

Technical subject matter experts help shine a light on what is possible. A strong product owner uses that light to make better decisions. When POs hide behind “I’m not technical,” they sever the relationship that allows strategy and implementation to influence each other. But when they engage with humility and a learning mindset, they build trust, elevate their product judgment, and enable the team to align around what matters most. 

A product owner does not need to be the smartest person in the room. They only need to be the one most committed to connecting expertise to outcomes. 

Two valuable paths for SMEs: Choose the path that fits you 

Many SMEs discover they do want to be product leaders. They want to shape vision, drive strategy, and champion the customer. If they embrace ambiguity, build market empathy, and learn to influence without authority, their expertise becomes an advantage. They evolve from experts in a domain to experts in delivering value in that domain. 

Others prefer to stay focused on their craft. They love the depth, the science, and the discipline, and have no desire to manage roadmaps, competing stakeholder needs, or product experimentation. That is fantastic. Their contribution as advisors is essential to product quality and safety. One path is not a promotion over the other. There are different ways of being responsible for impact. Expertise earns a seat at the table. Product leadership earns the responsibility for outcomes. Both matter deeply, and both deserve respect. 

So, can SMEs be great product owners? 

Again, it depends. Do they want to? Do they have the vocation or desire to? Are they ready to change their mindset? Experts know how things are. Product people imagine how things could be. Can SMEs cross that line? 

Studying, reading, observing, shadowing, being coached and mentored, gaining experience, or approaching other professional product people are all valuable ways to start. It is important to notice that merely passing an online test to get a certificate as a PO/PM doesn’t make people suddenly product experts. Certainly not good ones, and this is valid for any role and profession. Getting a true understanding of the Agile principles and values is more valuable than any badge. Acquiring a growth and agile mindset and focusing on being good rather than showing off that you have some formal qualifications makes a real difference. 

Subject matter expertise is a powerful foundation, but product leadership requires building on that foundation with curiosity, empathy, experimentation, and strategic thinking. The world changes. Products change. Markets change. Customers change. Organizations change. Expertise must change with them. Innovation doesn’t reward those who defend what exists; it rewards those who imagine and deliver what comes next. And anyone (expert or not) who chooses to lead products with openness and courage can become an exceptional product leader. So here’s the real question: Can SMEs stop knowing everything long enough to lead something new? 

As I always say to the Product Managers I train and coach: “You don’t have to know how the engine works to drive the car. But you’d better care where the road leads.” 


References Atlassian. (2023). Product Manager vs. Product Owner. Atlassian. (2023). What is Product Management? Benson, B. (2016). Cognitive Bias Cheat Sheet. (Based on the Cognitive Bias Codex). Cagan, M. (2017). Inspired: How to Create Tech Products Customers Love (2nd ed.). Wiley. Christensen, C. (1997). The Innovator’s Dilemma. Harvard Business School Press. Davi, D. (2022). MEET the meeting model: Art and science of meeting successfully. Davi, D. (2024). Beyond the Sprint. Insights from the Frontline of Agile Leadership. Grant, A. (2021). Think Again: The Power of Knowing What You Don’t Know. Penguin. Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux. Schwaber, K. & Sutherland, J. (2020). The Scrum Guide. Scrum.org Tversky, A. & Kahneman, D. (1974). “Judgment Under Uncertainty: Heuristics and Biases.”  Science, 185(4157), 1124–1131.

We hope you found this post informative

Before you move on, please consider supporting our non-profit mission by making a donation to Agile Alliance todayThis is a community blog post. The opinions contained within belong solely to the author or authors, and may not represent the opinion or policy of Agile Alliance.

Picture of Daniele Davi

Daniele Davi

Daniele Davì is a Lean & Agile Coach, Transformation Consultant, and Author passionate about enabling people and organizations to grow through meaningful, sustainable change. With over two decades of international experience (from Software Engineer to Chief Technology and Transformation Officer) across diverse industries, he blends structure and empathy to help teams become adaptive, high-performing, and resilient. Through his company, DADAKAI Coaching Training Consulting, Daniele supports individuals, teams, and leaders in developing agility, collaboration, and continuous…

Recent Blog Posts

Recent Posts

Join Agile Alliance!

$5 per month (paid annually)*

*Corporate plans are also available

Post your comments or questions

Recent Agile Alliance Blog Posts

Ready to join Agile Alliance?

Unlock members-only access to online learning sessions, Agile resources, annual conference discounts, and more! And when you join, you’ll be supporting our member initiatives, regional events, and global community groups.

Privacy Preference Center

IMPORTANT: We have transitioned to a new membership platform. If you have not already done so, you will need to SET UP AN ACCOUNT on the new platform to establish your user profile. Your previous login credentials will not work until you do this set up.

When you see the login screen, choose “Set up Account” and follow the prompts to create your new account. You can choose to log in using your social credentials for either Google or Linkedin (recommended), or you can set up your account using an email address.