What does the DEVELOP phase of workshop design produce?

DEVELOP is the third of the five phases in the Workshop Doctor Roadmap. Its job is to produce only the specific tools each activity DESIGN specified actually requires — pre-work that arrives warm, breakout materials with prompt and role and deliverable and debrief, comprehension checks at transitions, debrief structures that consolidate learning, participant templates filled in during the work. Everything else is weight the session absorbs without benefit. The discipline is build-then-subtract: build a complete first pass, then cut everything that didn't earn its place. A 75-slide deck and a 30-page workbook are not signs of thoroughness — they're signs that DEVELOP is being used to solve DESIGN problems, and the session is going to feel it.

What does "death by PowerPoint" actually cost a workshop creator?

Slides packed with text the presenter reads aloud cost the workshop both attention and retention. Working memory holds roughly four items for fourteen to thirty seconds, and forcing the participant to read on screen and listen to the same content out loud occupies the same cognitive channel twice while teaching nothing through the visual one. The fix isn't better-looking slides. It's slides that carry something the verbal channel can't (a diagram, a comparison, a structure to fill in), running alongside narration that needs the visual to fully land. If the deck reads as a standalone document, it's a document — and the session became a read-aloud.

How do I make sure a breakout actually produces something useful?

Every breakout needs four specific things built before the session starts: the prompt the group gets, the role structure (three people, one scribe, rotating speakers, or whatever the activity calls for), the deliverable the group returns with, and the debrief question that connects the breakout back to the session's outcome. "Break into threes and discuss" is a breakout slot in the agenda; without those four pieces it isn't actually a breakout, it's unstructured time. Breakouts are where most of the active learning in a session actually happens, which makes them load-bearing — when they default to open conversation, the session loses the moment it was built around.

DEVELOP

Most workshops are overbuilt. Slides multiply, workbooks thicken, templates accumulate. The participant ends up with more material than the session can actually use, and what felt like preparation to the creator lands on the participant as too much to absorb.

The DEVELOP phase — the third of five phases in the Workshop Doctor Roadmap — decides what the session actually needs, and lets go of everything else. Its job is narrower than most creators expect: build the specific tools the participant needs in order to do the activities DESIGN specified, and nothing beyond that.

Workshops that carry the right minimum produce more, because every asset the participant touches is one the session was actually built around. Workshops that carry everything the creator thought to build produce less, because the material crowds out the experience — and the participant leaves having consumed material instead of producing change.

Why DEVELOP Matters

After DESIGN is done and before the session runs, it's easy to keep building material beyond what the session actually needs. The creator sees the empty slide deck and fills it. Sees the workbook outline and expands it. Adds a worksheet "in case people want more context." Builds a reference guide "in case they want to go deeper." None of these feel wrong individually. In aggregate, they replace the experience with a library.

The problem isn't thoroughness. Every asset the session carries that isn't actively used during the session is noise — something the participant has to look at, parse, and set aside. The session that carries extra assets runs slower, feels more cluttered, and produces less learning than the session that carries only what it needs.

DEVELOP is also where most of the late-night work happens in workshop creation. The creator has a reasonable PLAN, a workable DESIGN, and then spends sixty hours in the week before launch making assets. Most of that time goes into assets that won't do much work in the room. When DEVELOP is disciplined, most of those hours disappear. When DEVELOP is undisciplined, they multiply — and every extra asset adds complexity that DELIVER will have to absorb.

Recognizing DEVELOP as production work — producing the specific tools each activity DESIGN specified requires — is the shift that lets the creator stop solving design problems by building more material, and start building the right assets in the first place.

Every Asset Earns Its Place

Most creators — especially coaches and course builders who have spent years producing content for a living — have been trained to equate volume with value. More slides, thicker workbooks, longer resource lists: in a content-selling business, all of it reads as more of what's being sold. This isn't a character flaw. It's an inherited measurement system from industries where content is the product.

Inside a workshop, that measurement inverts. The participant doesn't judge a workshop by how much material they received. They judge it by what they can do on the other side of the session that they couldn't do before they walked in. A thirty-page workbook that doesn't produce a behavior change is thirty pages of nothing. A one-page template the participant actually fills in, defends, and walks out using is a workshop.

Volume isn't value. Outcomes are value. An hour spent producing an asset that doesn't serve a specific activity is an hour that doesn't move the outcome.

Once that reframe is actually held, DEVELOP-phase work runs on one decision rule: every asset the session carries has to earn its place by being actively used during the session. What earns a place is anything that makes active learning happen — pre-work that arrives warm, readiness checks that open the session, breakout materials that give three people something specific to do together, templates the participant fills in during the activity, comprehension checks that catch confusion before it compounds, and debrief structures that turn raw activity into consolidated learning. These aren't decorations around slide-based teaching. They are what the session is actually built from.

What doesn't earn a place belongs elsewhere. Reference documents that could be sent after the session belong in post-work. Slides the creator reads aloud belong in a cue sheet, not a deck. Worksheets that restate content already covered belong in the trash.

You are a master of your content. The DEVELOP-phase work is a different craft — it asks you to trust that the session produces more from fewer assets than from more, even when every instinct inherited from a content-first business is telling you to thicken the package. That trust is where the discipline of this phase actually lives.

The Core Questions DEVELOP Answers

For every activity DESIGN specified, do you have the asset it needs? Workshops built for transformation run on active-learning activity: pre-work that converts cold information to warm, readiness checks that open the session, breakouts, templates the participant fills in during the work, comprehension checks at the transitions, and debrief structures that consolidate what the activity produced. DESIGN names which of these activities the session runs. DEVELOP's job is to produce the specific asset that makes each one possible. If DESIGN specified a breakout in the second segment and DEVELOP didn't produce the prompt, the role structure, the deliverable, and the debrief question, the breakout has been scheduled but not built — and the live session is going to improvise around a gap.

Does the pre-work actually arrive warm? Pre-work isn't a reading list. It's the asset that converts cold information to warm so the live session can spend its time in the higher-order work only a live session can do — applying, analyzing, synthesizing, creating. The test is simple: if the participant skips the pre-work, can the opening activity still run cleanly? If yes, the pre-work is optional — which means it isn't pre-work, it's supplementary reading. If no, the pre-work is doing structural work for the session.

What does the breakout actually produce? Breakouts are where most of the active learning in a workshop actually happens, which makes them load-bearing, not optional. They fail when they're treated as filler — "break into threes and discuss." They produce when DEVELOP has built four specific things: the prompt the group gets, the role structure (three people, one scribe, rotating speakers, or whatever the activity requires), the deliverable the group returns with, and the debrief question that connects the breakout back to the session's outcome. If the breakout lands as unstructured time, the breakout asset wasn't built.

How do you catch confusion before it compounds? Comprehension checks — polls, multiple choice, short-answer prompts, structured share-outs — are how the session stays honest about whether learning is actually happening. "Any questions?" isn't a comprehension check; it's a question most participants can't answer because they don't know what they don't know. A check is a specific prompt with a specific format that produces a specific signal. DEVELOP builds those checks into the session at every transition where the next segment depends on the previous one landing.

Are your slides a visual anchor, or are they a script? Slides work when they give the participant a focal point for the current activity — a prompt, a framework to apply, a question to answer, a structure to fill in. Slides break when they carry the content the creator should be speaking, turning the deck into a teleprompter and the session into a read-aloud. If the slide could be printed and handed to someone who didn't attend the session and they would get the same thing from reading it as attending, the deck has become the workshop and the workshop has become a document.

Are you subtracting, or only adding? Build-then-subtract is the discipline: build a complete first pass, then cut everything that didn't earn its place. Creators who only add produce overweight packages. Creators who never finish a first pass never ship. The move is to get to a working version fast, then be willing to delete from it.

How to Recognize When DEVELOP Was Compressed

Observable signs that the DEVELOP phase got over-built, or got skipped into panic-mode production:

Breakouts are specified in the agenda but have no prompt, role structure, or deliverable — "break into groups and discuss" is the only instruction
Pre-work exists but doesn't connect to the opening activity — participants who did it and participants who skipped it can start the session the same way
The session has no built-in comprehension checks at the transitions — "any questions?" is the only check, and silence is being read as understanding
The slide deck is densely worded — full sentences, bullet points to be read aloud, speaker-note-style copy on the slides — because the deck is doubling as the creator's script
Workbooks are thick but mostly reference content the participant won't open during the session
The package includes assets the creator can't explain a use for when asked ("this is in case you want to go deeper")
Tech has not been tested in the actual delivery environment under actual load
Multiple tools are being used for overlapping functions — two platforms for polls, three places where the same asset lives
The creator cannot find a specific file in under ten seconds when asked cold — files are scattered across drives or services, named inconsistently, or tracked with labels like "final," "final_v2," "final_v3_revised"
Facilitator-side materials don't exist separately from participant-side materials, so the creator ends up reading from the participant deck
The package expanded significantly in the final week — a sign that DEVELOP was being used to solve DESIGN problems ("I'll add a handout to make that clearer")
Assets that look polished on the build desk fall apart in the first rehearsal because they were designed for the build view, not the session view

These aren't craftsmanship problems. They are volume problems. A package that leaks at any of these is carrying weight it doesn't need, and the session is going to feel it.

How to Work the DEVELOP Phase

DEVELOP-phase work doesn't require a bigger production budget or more polish. It requires the discipline to build the specific tools each activity DESIGN specified requires, and to subtract everything else.

Build pre-work that lets the opening activity assume readiness. Pre-work is a structural piece of the session, not a supplement. Its job is to arrive warm, so the live time can start in application rather than lecture. Specify one task the participant produces or attempts before the session, and design the opening activity to depend on it. Passive reading is not pre-work; a primer that asks the participant to produce something small is.

Build breakout materials that specify what the group produces. Every breakout needs four things DEVELOP produces: the specific prompt, the role structure (three people is the working default — one scribe, rotating speakers, or whatever the activity requires), the deliverable the group returns with, and the debrief question that connects the breakout back to the session's outcome. A breakout slotted into the agenda without these four pieces defaults to open discussion — energetic, maybe enjoyable, and rarely outcome-aligned.

Build comprehension checks into transitions. At every point in the session where the next segment depends on the previous one landing, DEVELOP produces a check: a poll, a multiple-choice prompt, a short-answer capture, a structured share-out. The format is less important than the principle — the check produces a specific signal about whether to move forward or to pause and clarify. "Any questions?" is not a check; it's a hope.

Build debrief structures that consolidate what the activity produced. Breakouts, individual work, and paired exercises don't produce learning on their own. They produce raw material that the debrief turns into consolidated learning. DEVELOP produces the specific debrief prompt, the share-out structure, and the synthesis move that lets the participant name what they just did and what it changed. A session that ends its activities without a debrief asset leaves the learning on the table.

Treat slides as visual anchors, and keep the creator's cue sheet separate from the participant's deck. One idea per slide, minimal text, visual emphasis over textual. The creator's cue sheet — run-of-show, timing, verbatim prompts, what to watch for during each activity — is a different document than the participant's deck. When the two get merged, the creator reads from the participant deck and the session defaults to lecture. Keep them separate so the creator's notes never become the participant's experience.

Pick fewer tools, and test them deeper. A polling tool, a breakout tool, a slide tool — most workshops can run on two or three integrated platforms if the activities were scoped carefully at DESIGN. Fewer tools rehearsed to invisibility beats more tools rehearsed lightly. Build a backup plan for the one or two most likely to fail, not a hopeful assumption that none of them will.

Build then subtract. First pass: get the package to a complete state — every activity has its asset, every breakout has its four pieces, every transition has its check. Second pass: cut everything that didn't earn its place. The second pass is the one most creators skip, because it feels like undoing work. It's actually where the package gets sharp.

Test the assets in session conditions, not build conditions. Run through the session with the assets in the context they'll actually be used — with real timing, real transitions, real pace. Does the template work when the participant is filling it in at speed? Does the comprehension check produce a clean signal? Does the breakout prompt produce the deliverable, or produce confusion? Assets that look polished on the build desk frequently fall apart in the session, not because they're bad but because they were never tested under delivery conditions.

None of this requires a bigger design budget, a fancier tool stack, or a longer build timeline. It requires the discipline to build the assets DESIGN's activities require, and to cut whatever arrived along the way that didn't earn its place.

Where this goes next: DEVELOP produces the tools DELIVER uses. DELIVER is where PLAN, DESIGN, and DEVELOP decisions meet the live room — where the package either supports the session or exposes what was overbuilt. See DELIVER — Facilitate Like a Coach.

Read this next:

DELIVER — Facilitate Like a Coach — the next phase; where DEVELOP's assets meet the live room

Foundations of this concept:

Cognitive Load — the reason slides have to be visual anchors, not dense walls of text; working memory can't carry both listening and reading at once
The 80/20 Workshop Engagement Ratio — the structural ratio DEVELOP's assets are built to serve (participant doing, not creator presenting)
Dual Coding — the principle behind visual-plus-verbal asset design; the slide image plus the creator's words is denser than either alone

Where this leads:

DELIVER runs the session DEVELOP's assets were built for. A weak DEVELOP forces DELIVER to improvise around missing or overloaded materials; a sharp DEVELOP lets DELIVER focus on the room rather than the deck.