What I Learned About Facilitation the Hard Way

For about six months, I participated in a facilitation enablement program run by an external facilitator working with cross-functional teams at Geotab. We didn't just study facilitation — we ran real sessions, reflected on what happened, and iterated. These are the things I took away from that experience, mapped to three concrete experiments of my own.

The framework I didn't know I needed

Before the program, I thought of facilitation as something you did intuitively — you had an agenda, you kept things moving, you ended on time. What I learned is that facilitation is a craft with before, during, and after phases, each with its own set of traps.

A few principles from the program that genuinely changed my approach:

• One goal, clearly communicated. If participants can't articulate the session goal in one sentence, you don't have one — you have a topic.
• Plan for 75% of your time. The remaining 25% is where the real conversation lives.
• Distinguish workshops from meetings. Workshops are activity-driven. Meetings are discussion-driven. Mixing them produces neither.
• Silence is data. When a room goes quiet, don't rush to fill it — read what it's telling you.
• Name what you need. Telling participants exactly what kind of feedback you want (reactions? decisions? priorities?) dramatically raises the quality of what you get back.

Experiment 1: UX Scorecarding — Simplify the Scenario

My first experiment was a UX scorecarding session — a structured method where participants rate two design alternatives against a set of criteria, generating a prioritized list of improvements. My first attempt ran significantly over time and didn't give me the data I needed.

What went wrong: I overcomplicated the scenario. Too many tasks, too many scoring dimensions, documentation on a Figma board (unfamiliar tool for some participants), and no buffer for context-setting.

The insight that generalized: Complexity is the enemy of participation. The more steps you add to a session, the fewer people complete any of them fully. Simplify relentlessly, even when it feels like you're leaving value on the table.

My next iteration: involve stakeholders in the task creation process itself, so the scenarios are grounded in real pain points rather than hypothetical ones.

Experiment 2: Design Review — Structure as a Superpower

My second experiment was a design review with a key stakeholder — Alex Castro from Product Ops — focused on making rapid decisions about an in-app communication blueprint. The complication: an external PM had already started building a component without design approval, creating a risk of fragmented experiences across the product.

The stakes were high and the time window was tight. My approach:

• Ran a dry run beforehand to tighten the agenda
• Used a timer visibly during the session to prevent discussion from expanding
• Separated discussion from decision-making — no conflating the two
• Documented decisions and problem descriptions in a shared doc in real-time, so participants who needed to drop could still track what happened

Result: five critical action items resolved in under 50 minutes. The session worked because it was structured enough to contain the scope but flexible enough to let the most important conversations breathe.

Experiment 3: The Scorecarding Session for Roadside Assistance

A colleague ran a scorecarding workshop with 12 participants to validate two design versions of a roadside assistance feature. The session generated useful data — two distinct scores, actionable feedback — but engagement was uneven. Only about two-thirds of participants actually completed the scoring responses.

The diagnosis: stakes weren't set at the beginning. Participants weren't brought into the story — why this feature mattered, who it was for, what a bad outcome looked like. Without that frame, scoring felt abstract and the energy dropped.

The recommended fix — and one I now apply to every session — is to spend the first few minutes telling the human story behind the work. Not the ROI framing, not the stakeholder priority, but the person: what their day looks like, what goes wrong, what a better experience means for them. That story is what makes the rest of the session feel worth doing.

Principles I now bring to every session

• Start with a check-in. Ask participants to name any obstacle that might prevent them from being fully present. It humanizes the room and surfaces real constraints early.
• Have a decision log. Every session should end with documented decisions and owners, not just "great discussion." The decision log is what connects your workshop to the roadmap.
• Follow the energy — intentionally. Letting a productive conversation run past its agenda slot isn't failure. But know why you're doing it, and have a recovery plan for what you're cutting.
• Write detailed meeting descriptions. Many stakeholders decide whether they're the right person for a session based on the invite description. A well-written description gets you the right participants — and lets the wrong ones decline gracefully.
• Keep stakeholder character sheets. Know your participants before the session. What do they care about? What triggers them? What kind of feedback do they give vs. what you need? (More on this in the Stakeholder Characters post.)

The program ended with a 90-minute "playbook" session — a synthesis of all the experiments, principles, and tools we'd accumulated. What I'm taking forward isn't a checklist: it's a practice of reflection. The habit of asking, after every session, what worked, what I'd change, and which principles I actually applied in the room vs. only in the planning phase.

That gap — between the facilitator you plan to be and the one you are when things go off-script — is where the real learning lives.