You're three weeks into a new project. Healthcare, logistics, insurance, whatever the domain is, you barely understand it. The developers built the system. The PM has been on this roadmap for a year. The operations lead can walk through the workflow with their eyes closed. The domain expert can spot your bad assumptions before you've finished stating them.

And you're supposed to run the design workshop.

The Spiral

You try. You set up the Miro board, prepare activities, open with something about exploring the problem space. Within ten minutes, the lead developer starts driving. He's built the backend. He knows what's feasible and what isn't. And feasibility becomes the only thing anyone talks about. "That won't work." "We've tried that." "You don't understand how the system is structured."

The PM backs him up. They've been aligned for months. They've already decided what the next quarter looks like. Your workshop is, in their heads, a formality before you start making screens.

You push back once. Maybe twice. "Can we explore the user's perspective before we jump to constraints?" They look at you like you've said something cute. The domain expert says something technical that you don't fully follow. You nod. You lose the thread.

And then it happens. That quiet moment where you stop fighting. Not dramatically, not with a declaration. You just stop. You open Figma. You start making screens. You become the person who makes things presentable based on what the room decided without you.

And then the blaming starts. "This organisation doesn't value design." "The PM is too controlling." "They don't understand what I bring." The blaming feels righteous cos it's partially true. But it's also easy. Much easier than figuring out how to lead a room full of people who know more than you about the subject matter.

I've watched this spiral happen with designers at every level. Three years of experience, twelve years of experience. The pattern is the same cos the root cause is the same: identity.

Why This Happens

Your entire career has trained you to be the expert, the person who finds insights others miss, whose value comes from knowing things that other people in the room don't.

Then you walk into a room where you know the least about everything. The domain, the technology, the business model, even the users, cos the support team has been talking to them daily for three years and you've read five interview transcripts.

Your expert identity has nothing to grab onto. So you do one of two things. Fake expertise you don't have, which gets dismantled in about four minutes by people who actually have it. Or retreat into craft, the one thing you're confident about. Both responses turn you into a service provider in the room, someone who takes orders and makes them presentable rather than shaping what gets built.

You're the Director, Not the Lead Actor

Think about a film director. They don't act, can't do the stunts, don't operate the camera, probably can't write dialogue as well as the screenwriter. Every person on that set is more skilled than the director at their specific job.

Nobody questions why the director is there though. Without the director you get a bunch of talented people producing disconnected work, not a film.

The director's value is in seeing how everything connects. Knowing when the actor needs another take, when the cinematographer's framing supports the story and when it fights it, holding the whole vision while everyone else holds their piece of it.

That's your role in the workshop. You don't need to know healthcare compliance better than the domain expert or system architecture better than the developer. You're the person who connects what each of them knows into something none of them could produce alone. They're each looking through their own lens. You're the only one who can see the whole frame.

"But That's the PM's Job"

Some people will push back on this. The pushback is worth addressing cos it's not entirely wrong.

PM literature actively claims workshop facilitation as a PM competency. Emma Tucker, a product leader who's worked at Amazon and IBM, wrote that "while Design Thinking has Design in the name, it cannot be counted among the list of things PMs are not accountable for" [4]. LogRocket's PM guide states that "the best PMs don't just facilitate workshops, they design transformation journeys" [1].

The product trio model, PM and designer and engineer framing problems together, suggests that workshop ownership isn't fixed to any one role. Jeff Zych documented this at LaunchDarkly: "Both PMs and designers do user research, user scenarios, workshops and whiteboarding. Who owns these activities? The answer is both" [2].

So the question worth asking isn't "should the designer always run the workshop?" The useful question is: when you're the one running it, and you know less about the domain than everyone else in the room, how do you do it without losing the room?

That's what this blog is about. A practical approach for when it's you, and you're outgunned on domain knowledge.

Before the Workshop

Talk to the people who talk to users.Spend 30 minutes with customer support or the operations team before the workshop. Ask three questions: What do users complain about most? What workarounds have they developed? What question keeps coming up that the product should answer but doesn't?

This gives you something nobody else in the workshop has: the user's actual frustration, stated by people who hear it every day. When you bring this into the room, you're grounding the conversation in real pain rather than guessing from five transcripts. We wrote about this kind of preparation in the context of senior designer conversations, where the prep is about proximity to the user's reality rather than domain expertise.

Map the people, not just the topic.Find out who's in the room and what each person optimises for. The developer cares about feasibility, the PM about roadmap alignment, the domain expert about correctness, the business sponsor about ROI. When you know what lens each person looks through, you can anticipate where they'll block and structure the session to use those tendencies instead of getting wrecked by them.

Prepare a structure with one clear question. The workshop needs to answer one question. The State of Facilitation 2026 report found that effective facilitation now happens in 60-90 minute focused sessions, not multi-day marathons [3]. Build toward one decision.

During the Workshop: Five Moves

1. Say what you're there to do. Out loud.

Open with something like: "I'm not the domain expert in this room. You are. My job is to make sure we use everyone's expertise to reach a decision we can all stand behind. The content comes from you. The structure comes from me."

This removes the pressure to perform expertise you don't have, gives experts permission to be experts, and establishes that you're directing the process rather than competing for knowledge.

2. Make experts the heroes of their own knowledge.

When the domain expert explains something, don't just nod. Reflect it back. "So the adjuster needs to see claim history before deciding because without it they're essentially guessing. Right?"

The expert feels valued, which makes them an ally instead of a blocker. And the room gets the insight translated into shared language that everyone can work with.

If the support team told you something relevant, let the expert validate it. "Priya from support mentioned users call in most about claim status. Does that match what you see on the ops side?" Now the expert is building on data that validates their own observation rather than reacting to your problem framing. They own the insight. You connected the dots.

3. Redirect solutions back to questions.

The moment someone says "we should add a dashboard," redirect. "Before we design the solution, what problem would the dashboard solve? What decision would a user make with it that they can't make today?"

Solutions proposed early in workshops anchor everything that follows. They usually come from the loudest or most senior person, based on one perspective rather than shared understanding. Redirecting to the question is quality control. We wrote about why this matters in You Solved Exactly What You Were Asked to Solve. That's the Problem.

4. Handle the blocker without fighting.

"That's not feasible." You'll hear it. Don't argue with it.

"I hear that feasibility is a concern. Can we capture it as a constraint and keep exploring the user need for ten more minutes? Once we've defined what users need, we can evaluate which parts are feasible and which need a different approach."

You haven't dismissed them. You've parked their concern visibly and given the room permission to keep thinking before one person's lens becomes the only lens.

If they persist, try: "You clearly know this system deeply. If feasibility weren't a constraint, what would the ideal experience look like?" This reframes their expertise from a wall into a bridge. Most blockers soften when they're invited to contribute to the ideal instead of defending the current state.

5. End with decisions, not stickies.

The 2026 State of Facilitation report put it bluntly: facilitation gets credit for how people felt in the room, not for what changed after [3]. Most workshops produce nothing usable.

Close with three things documented. What we decided (specific decisions, not themes or insights). Who owns what next (name, action, date). What we explicitly did not decide (parked for a separate conversation). If you leave without these three, the workshop was a meeting with better snacks.

After: Cement the Director Role

Send the summary within 24 hours.One page covering decisions, owners, and parking lot. If you don't write this, the PM will, and the story will be told from their perspective.

Follow up on the actions. The director makes sure the film keeps shooting after the first day on set. Check in with the people who took ownership. Keep the momentum your workshop created.

Credit people by name."The insight about claim status visibility came from Priya in support, validated by Ananya in operations." People who feel credited become repeat contributors. People whose ideas got absorbed without acknowledgment become your blockers next time.

Beyond Workshops

The director approach applies everywhere you're the least knowledgeable person in the room, which is basically every new project.

During discovery, connect the domain experts, the support data, and the analytics into a shared understanding rather than trying to become the domain expert yourself. Your job is synthesis.

During ideation, structure a process where the developer contributes technical possibilities, the domain expert adds contextual constraints, and the business sponsor brings commercial reality. You hold the frame while everyone contributes their expertise.

During testing, involve the domain expert. They'll catch wrong terminology, unrealistic data, and workflow steps that don't match real practice. Things you'd miss on your own.

This is how you grow as a solo designerin organisations full of people who've been there longer. You become the person who makes their knowledge productive rather than competing with it.

The Identity Shift

The reason designers struggle with this is less about skill and more about identity.

We've been told our value is in knowing things. When we walk into a room where we know the least, that identity crumbles. We fight for it and lose, or abandon it and start churning screens, or blame the culture and nothing changes.

The designers who break through are the ones who let go of being the expert and embrace being the director. Sitting with not knowing, asking questions that expose your ignorance, watching someone else have the breakthrough insight and feeling genuinely glad about it cos you created the conditions for it to happen. That's leadership. The kind that's harder to perform but harder to replace.

If you want to develop this capability, whether as an individual designer in rooms that feel hostile to your contribution, or as a design leader building this skill in your team, that's what we work on at Xperience Wave. Through mentorship and through team workshops. Book a strategy call if you want to talk about where you stand.

Free Resource: Workshop Facilitation Cheatsheet

A one-page cheatsheet covering before, during, and after. The five moves, blocker-handling scripts, the summary template, and the three things you close with. Print it and keep it on your desk.

Free Download

Workshop Facilitation Cheatsheet

One page covering before, during, and after. The five moves, blocker-handling scripts, the summary template, and the three things you close with.

No spam. Just the cheatsheet.

Sources & References

[1] LogRocket. (2025). "A Guide to Designing Successful Product Management Workshops." blog.logrocket.com
[2] Zych, J. (2020). "Product Manager and Product Designer: Who Does What?" jlzych.com
[3] The Designer's Field Guide. (2026). "The Old Design Workshop Is Dead. Long Live Design Workshops." Referencing State of Facilitation 2025/2026. thedesignersfieldguide.substack.com
[4] Tucker, E. (2019). "7 Ways Product Managers Can Influence the Success of Design Thinking Workshops." LinkedIn. linkedin.com

About the Author

Almas Tasneem is Co-founder and CEO at Xperience Wave, a UX design studio based in Bangalore, working across designer mentorship, UX services for businesses, and a design community of 1,000+ designers.

- Almas, Co-founder & CEO, Xperience Wave