AI Driven PM: S2E4 - Do We Have to be the Domain Expert?

I get this question all the time when I'm working with a new client or interviewing for a role.

"So Rick, are you an expert in the insurance industry?"

"No."

"Well... shouldn't you be? I mean, shouldn't a project manager understand the domain they're managing projects in?"

"Not really."

They look confused. So I follow up:

"How many people work here?"

"About 5,000."

"Great. So you've got 5,000 experts in insurance. What you need is someone like me who can get the best out of those 5,000 people."

That's the difference between domain expertise and project management expertise.

And most organizations don't understand it.

They prioritize hiring PMs who "speak the language of the business" over PMs who know how to facilitate, translate, and orchestrate expertise.

And that hiring bias? It backfires more often than you think.

The Conventional Wisdom (And Why It's Wrong)

Here's what most organizations believe:

• You need a PM who understands healthcare, finance, manufacturing, [insert industry here]
• They have to "speak the language" of the business
• Domain expertise signals credibility and competence
• Deep knowledge = better decisions

The reality? Domain expertise can be a hindrance just as often as it's a help.

Here's why.

When Domain Expertise Backfires

1. Domain Expert PMs Micromanage

When you know how to do the work, it's really hard not to tell people how to do the work.

A PM with deep domain expertise will hear an engineer say, "That'll take 10 hours," and think, "I could do that in two hours."

And then they start challenging estimates. Second-guessing approaches. Offering "suggestions" that aren't really suggestions.

That's not project management. That's micromanagement.

2. They Focus on WHAT, Not HOW

Domain expert PMs get obsessed with what's being built instead of how the team is building it.

They care more about the technical solution than the team dynamics, the stakeholder alignment, or the energy in the room.

And that leads to projects that might be technically perfect but operationally a disaster.

3. Personal Bias Takes Over

When you have deep domain experience, you carry bias—whether you're aware of it or not.

You think, "I've been there before. I've seen that approach. It doesn't work."

But here's the thing: Just because it didn't work when YOU tried it doesn't mean it won't work now.

Context matters. Teams matter. Timing matters.

And sometimes the team needs to try something, discover it doesn't work, and pivot. That's how ownership and learning happen.

When a domain expert PM shuts that down with "I already know that won't work," they kill ownership and innovation.

4. They Become Decision Bottlenecks

Domain expert PMs feel like they need to be involved in every decision because they "understand the implications."

So they become the bottleneck.

Every technical choice, every scope question, every trade-off discussion has to run through them.

That's not leadership. That's dependency.

What Great PMs Actually Do

Here's the truth most organizations miss:

A great PM knows how to ask the right questions—not provide the right answers.

Let me say that again for the people in the back:

You don't make decisions on scope, budget, timeline, or what's in or out. You make recommendations. You influence. But you don't own the decision.

Your job is to:

• Translate between domains (tech to business, business to customer, customer to tech)
• Facilitate expertise (create the conditions for experts to do their best work)
• Ask the "dumb" question (the one everyone assumed was already answered)
• Frame trade-offs (so the right people can make informed decisions)
• Orchestrate, not dictate (you're the conductor, not the soloist)

And here's the magic: Facilitation expertise + deep learning desire > domain expertise.

Why?

Because you're unafraid to ask the next question. You're not stuck in "how it's always been done." You bring fresh eyes, challenge assumptions, and force clarity where experts have gotten comfortable with ambiguity.

When Domain Expertise DOES Matter

I'm not saying domain expertise is useless. There are contexts where it absolutely matters:

1. Highly Regulated Industries

Healthcare, finance, government—anywhere compliance is complex and non-negotiable.

In these environments, knowing which questions to ask requires baseline domain knowledge. You need to know what regulations exist so you know who to pull into the conversation.

But even then, you don't need to be the compliance expert. You just need to know when to engage one.

2. Deeply Technical Domains

If you're building your own AI/ML systems, embedded systems, or highly specialized technology, some technical fluency helps with translation.

But notice I said fluency, not mastery.

You don't need to code the solution. You need to understand enough to ask, "What are the trade-offs?" and "What happens if we're wrong?"

3. When You're the Only Person in the Room

If you're a solo PM in a startup with no dedicated domain experts, then yeah—you might need to wear both hats for a while.

But even then, your job is to build the team that replaces your domain gaps as fast as possible.

How AI Helps You Bridge Domain Gaps in Days, Not Months

This is where it gets fun.

One of the most powerful uses of AI for project managers isn't writing status reports or generating meeting notes.

It's becoming a domain learning accelerator.

You can use AI to:

• Get up to speed on unfamiliar domains in days instead of months
• Build stakeholder expertise maps so you know who to ask what
• Generate facilitation scripts so you can lead technical debates without pretending to be the expert

Let me show you.

---

Prompt 1: Domain Knowledge Accelerator (Your Non-Negotiable)

This is your experiment for this week. Use AI to get up to speed on an unfamiliar domain—fast.

What it does:

• Identifies 5-7 core concepts you need to understand
• Explains each concept in plain language with analogies
• Maps key stakeholder types and what they care about
• Surfaces common PM pitfalls in that domain
• Generates questions to ask experts

What I got when I ran it for the Social Wishing app:

ChatGPT gave me concepts like:

• OAuth and API authorization flows
• Graph API rate limits
• Data privacy classification
• Viral growth and infrastructure scaling

And then—here's what I loved—it gave me analogies.

For "viral growth and infrastructure scaling," it said:

Plain language: If growth spikes, your system must handle sudden load increases.

Analogy: It's like a small coffee shop that suddenly gets national press—but you only have one espresso machine. Service will collapse.

That's gold.

Now I can explain infrastructure risk to a business stakeholder without using the word "horizontal scaling."

I can say, "We just got national press, and we've got a line around the block—but we only have one espresso machine. We need to decide: Do we buy more machines now, or risk turning customers away?"

That's translation. That's facilitation. That's what great PMs do.

---

Prompt 2: Stakeholder Expertise Mapper

This one helps you figure out who knows what and who cares about what on your project.

What it creates:

• 8-12 key stakeholders by role (not name)
• What domain expertise each brings
• What each stakeholder's "win condition" is
• Who to rely on for domain expertise vs. business context vs. technical decisions
• Questions to ask each stakeholder type

What I got:

ChatGPT mapped out:

• Executive sponsor (cares about market differentiation and user growth)
• Product owner (cares about MVP clarity and scope control)
• Back-end engineer (cares about API stability and Facebook integration)
• Marketing director (cares about launch readiness and campaign metrics)
• QA engineer (cares about testing strategy for third-party integrations)

Then it gave me questions tailored to each stakeholder.

For the marketing director: "What needs to be true in terms of experience or metrics for you to feel confident running a full launch campaign?"

For the QA engineer: "If you were going to design the testing strategy for the Facebook API integration from scratch, what would you prioritize?"

These aren't generic questions. They're role-specific, expertise-tapping questions that show you're learning—and give you credibility without pretending to know.

---

Prompt 3: Facilitation Over Expertise Script

This is the one I use when the team is stuck in a heated debate and I don't have the technical chops to declare a winner.

The scenario I gave it:

The Social Wishing engineering team is debating architecture.

Option A: Microservices from day one (more complex, scales better)
Option B: Monolith first, split later (faster to MVP, potential refactor pain)

I don't have strong back-end architecture expertise. Two senior engineers are dug in on opposite sides. The debate is getting heated, and we're burning time.

How do I lead this without pretending I know what's technically right?

What AI gave me:

Questions to draw out expertise:

• "What's each of us assuming about how fast this app will scale—and are those assumptions written down anywhere?"
• "What would have to be true about our growth trajectory for Option A to be clearly the right call? Or Option B?"
• "Has anyone on the team built something similar before, and what happened?"
• "Is there anything about our team's current skills or bandwidth that should factor into this choice that we haven't mentioned yet?"

Framework to organize the discussion:

Claude suggested:

1. Structured input from both sides (5 minutes each, no interruptions)
2. Engineering lead makes recommendation
3. I confirm alignment with business constraints
4. If no clear owner exists, escalate ownership before debating substance

That last one is killer: Find out who's going to make the call before you go into a full debate.

Authority without expertise:

ChatGPT gave me this framing:

"I'm not here to declare the technically pure answer. I'm here to ensure we understand the trade-offs and align the architecture to our business goals."

That's leadership.

You're not pretending to know the answer. You're facilitating the process that gets to the right answer.

---

Your Non-Negotiable Experiment This Week

Use the Domain Knowledge Accelerator (Prompt 1) on an unfamiliar area of your current project.

Then ask at least one question from the expert question list AI generates for you.

Here's what I want you to notice:

1. Did asking questions instead of pretending to know earn you more credibility?
   (It almost always does.)
2. How much faster can you learn with AI as a tutor?
   (Days instead of months.)
3. Did the "dumb" question you asked surface something nobody else was saying out loud?
   (That's where breakthroughs happen.)

Because here's the truth: Asking questions doesn't make you look weak. It makes you look curious, coachable, and confident enough to admit what you don't know.

And that earns trust faster than pretending to be the expert ever will.

---

The Takeaway

Domain expertise is overrated for project managers.

Facilitation expertise is underrated.

Great PMs don't have all the answers. They ask the right questions and create the conditions for experts to thrive.

And with AI as your learning partner, you can bridge domain knowledge gaps in days—not months—so you can lead with confidence even when you're not the expert in the room.

So stop worrying about whether you "know the industry."

Start worrying about whether you know how to get the best out of the people who do.

---

Next time: Data-Driven Metrics 2.0—What metrics actually matter in the AI era, and how do we use AI to surface what's really going on in our projects?

If you would like to see the podcast live, check out this link: https://youtu.be/zqrspMN0gCM

Now go ask a "dumb" question. Your team is waiting.

— Rick A. Morris

---

The Prompts (Copy/Paste Ready)

Prompt 1 - Domain Knowledge Accelerator

You are a strategic learning coach helping a project manager quickly understand a new domain.

First, ask me 2–3 questions about the project, the domain, and what I specifically need to understand to lead effectively.

Then provide a learning plan answering:

1. What are the 5–7 core concepts or frameworks I must understand in this domain?
2. For each concept, explain it in plain language with an analogy to something more familiar.
3. What are the key stakeholder types in this domain and what does each care most about?
4. What are the 3–5 most common pitfalls or mistakes PMs make when they don't understand this domain?
5. What questions should I ask domain experts to demonstrate I'm learning and to uncover critical constraints?

Domain and project context: [Enter Context]

---

Prompt 2 - Stakeholder Expertise Mapper

You are a project stakeholder analyst.

Ask me 3–4 questions about the project, its goals, and who's involved or affected.

Then create a stakeholder expertise map answering:

1. Who are the 8–12 key stakeholders (by role, not name)?
2. For each stakeholder, what domain expertise or knowledge do they bring?
3. What does each stakeholder care most about (their "win condition")?
4. Which stakeholders should I rely on for domain expertise vs. business context vs. technical decisions?
5. What questions should I ask each stakeholder type to tap their expertise effectively?

Project context: [Add Context]

---

Prompt 3 - Facilitation over Expertise Script

You are a coaching expert helping PMs lead through facilitation rather than expertise.

Ask me 2–3 questions about a specific domain decision or technical choice the team is debating.

Then help me facilitate the decision by providing:

1. What open-ended questions should I ask to draw out the team's expertise?
2. What framework or structure can I offer to organize the discussion (without dictating the answer)?
3. How do I acknowledge my knowledge gaps while still leading with authority?
4. What decision-making process should I facilitate (consensus, consultative, executive call)?
5. How do I summarize and communicate the decision in a way that shows I understand the "why" even if I didn't provide the "what"?

Situation: [Enter Situation]