| name | workshop-use-case-researcher |
| description | Research and brainstorm practical use case ideas for custom AI workshops and training proposals. Use this skill whenever Shaw is preparing a workshop, training session, or proposal for a client and needs to identify relevant use cases for a specific audience. Triggers include: "brainstorm use cases", "what use cases should I cover", "help me prep the workshop for [company]", "I need use case ideas for [role/audience]", "research topics for the training", "what should I demo", or any reference to building out a custom workshop or training proposal. Also trigger when Shaw mentions a specific client engagement where the deliverable is a training session, workshop, or enablement program. Even casual mentions like "what should I teach them" or "I need to figure out the use cases for this one" should trigger this skill.
|
Workshop Use Case Researcher
Shaw delivers custom AI workshops for organizations. Each engagement has a different audience
(role, seniority, industry), different tools (M365 Copilot, Claude, ChatGPT, etc.), and different
adoption maturity. This skill helps research and brainstorm practical, demo-able use cases
tailored to that specific context.
The goal: produce a tight shortlist of use case ideas — each grounded in a real business problem,
backed by reference links, and scoped to what's actually possible with the client's tool stack.
Phase 1: Gather Context
Before any research, assemble everything known about this engagement. The quality of use cases
depends entirely on how well you understand the audience's daily work, pain points, and tools.
Step 1: Check Notion for existing context
Look for the client in the ABA Calls database (page ID: [database-id]).
If a call record exists, fetch it — the call notes typically contain:
- What the audience does day-to-day
- Current tool access and adoption level
- What they can't do today that they should be doing
- Stated goals and pain points
- Any specific use case directions already discussed
Also check the Active Leads database via the CRM skill if relevant — there may be email threads
or pipeline context that adds detail.
Step 2: Identify gaps and ask Shaw
After reviewing available context, assess what you still need to know. The essential context for
good use case research is:
- Company & industry — What does the company do? What sector? What's unique about their work?
- Audience role — What is the specific job function? (e.g., "product managers in cell therapy R&D" is much better than "employees")
- Daily workflows — What does this audience actually spend their time on? What are the 5-6 recurring tasks that eat their week?
- Tool stack — What AI tools do they have access to? What's the specific product/version?
- Adoption maturity — Are they brand new, dabbling, or already using AI daily? What have they tried so far?
- Pain points — What's frustrating, slow, or manual about their current work?
- Goals — What does the client or their leadership want to get out of this?
- Session format — How long is the session? How many use cases needed? Is it demo-heavy or discussion-heavy?
If any of these are unclear from the Notion context, ask Shaw directly. He often has additional
insights about where to research — specific platforms, communities, or content sources that are
especially relevant for this particular audience. Ask for these explicitly:
"Before I start researching, are there any specific sources you think would be especially
relevant for this audience? For example, specific communities, YouTube channels, learning
platforms, industry publications, or people who cover this role?"
Present a brief research plan before kicking off. Shaw should approve or adjust before you
spend tokens on broad searches.
Phase 2: Research
Research plan structure
Based on the context gathered, design a research plan with 2-4 parallel threads. The specific
threads depend on the engagement — don't default to a fixed set. Instead, choose threads based
on what will yield the most relevant results for this audience and tool stack.
Common thread types (pick what's relevant, not all of them):
-
Role-specific AI adoption — How are people in this role actually using AI today? Search
for practitioner content: courses, talks, blog posts, newsletters by people in this role
sharing their workflows. Shaw may point you to specific sources (e.g., Maven for PMs,
specific YouTube channels for engineers, industry Slack communities).
-
Tool capabilities audit — What can the client's specific tool stack actually do today?
Go to the official documentation and recent feature announcements. Don't rely on general
knowledge — tools change fast. Search for the tool name + recent features/capabilities.
-
Industry/domain context — What's unique about this company's industry that shapes how
the audience works? For regulated industries (biotech, finance, healthcare), there are
specific constraints and workflows that generic AI use cases won't address.
-
Broad web / practitioner stories — Search for real examples of people in similar roles
using AI. Look for blog posts, podcast episodes, newsletter issues, and articles that
describe specific workflows, not just tool lists.
Depth over breadth
A common failure mode is shallow research — running a few web searches and skimming the
snippets without actually reading the content. To avoid this:
- When a search result looks promising, use
web_fetch to read the actual page. Snippets
are often too compressed to extract real workflow details.
- For tool capability research, go to the official docs and recent release blogs. Don't rely
on third-party summaries which may be outdated or wrong.
- For practitioner content (courses, talks, podcasts), read the description, syllabus, or
transcript to understand what specific workflows they're teaching — not just the title.
- Aim for at least 3-4 web_fetch calls per research thread to get real depth.
What to extract from research
For each source, look for:
- Specific workflows — not "AI helps with research" but "upload 50 interview transcripts
and get a themed synthesis in 30 minutes"
- Time savings claims — concrete before/after numbers that make the business case vivid
- Tool-specific features — which exact tool or feature enables the workflow
- Relevance to this audience — does this map to something the client's audience actually does?
Phase 3: Synthesize
Cross-reference research with context
Map what you found in research against the audience's actual daily work:
- Which use cases address a stated pain point?
- Which use cases are possible with the client's tool stack today?
- Which use cases will land with the audience's adoption maturity? (Don't propose agent
architectures to people who haven't used chat yet.)
Rank by these criteria
- Business problem clarity — Can you articulate the specific daily pain this solves in
one sentence that the audience would nod at?
- Tool feasibility — Is this actually doable with their specific tools today?
- Demo-ability — Can Shaw show this live in 10-15 minutes?
- Wow-to-effort ratio — Does this feel impressive relative to how simple it is to do?
- Complexity ramp — The final set should progress from simple to complex.
Phase 4: Output
First pass: Tight shortlist
Present 5 use case ideas in this exact format:
**1. [3-Word Label]** — [One sentence describing what the audience does with the tool to solve a specific problem.]
- [Link title (Source)](URL)
- [Link title (Source)](URL)
- [Link title (Source)](URL)
No descriptions on the links. No extra commentary between items. Keep it scannable.
Shaw will pick the top 3 (or however many he needs). Only then expand.
Second pass: Expanded use cases (on request)
When Shaw picks his top choices, expand each one with:
- The business problem — 2-3 sentences grounding it in the audience's specific daily work
- Prerequisites — What needs to be true for this demo to work (licenses, data, files)
- Demo steps — Numbered list, as few steps as possible (aim for 4-5), each one an
action Shaw performs live
Order the final set from simplest to most complex so the workshop narrative ramps up.
Failure modes to watch for
- Shallow research — Skimming search snippets instead of fetching and reading actual pages.
Fix: use web_fetch on promising results. Read the actual content.
- Feature-first thinking — Describing what the tool does instead of what problem it solves.
Fix: always lead with the business problem. "Researcher agent" is not a use case. "Compress
6 hours of competitive analysis into 30 minutes" is.
- Overfitting to generic roles — Proposing the same use cases you'd give any audience.
Fix: ground every use case in something specific to this company, industry, or role.
- Ignoring adoption maturity — Proposing advanced workflows to beginners, or basic
features to power users. Fix: calibrate to where the audience actually is.
- Skipping the context phase — Jumping straight to research without understanding the
audience. Fix: always do Phase 1 first. The 10 minutes spent gathering context saves
hours of wasted research.
