Case Study · 03 · Own The Room
AI Coaching Tool · Product Strategy
An AI that makes you rehearse the room before you walk in.
You know the work is right — but the words don’t come out under pressure. Own The Room simulates the CEO, CTO, and PM you’re about to present to, asks what they’d actually ask, and scores how you answer.
The premise
The most important question in building an AI tool isn’t what the AI does. It’s what the human never gives up.
Overview
Practice the translation before the real conversation happens.
You know the work is right. You know the research backs it. But the moment a CEO, a CTO, or a PM asks you to justify it on the spot — the words don’t come out the way they should.
Designers are trained to think inside the work. We’re not trained to translate that thinking on the spot, under pressure, to people who weren’t in the room when the decisions were made.
Own The Room lets you document your design context, define your stakeholders, and rehearse against each persona — asking the questions they’d actually ask, scoring your responses, and telling you specifically what to fix.
01 — The problem
It’s not a design problem. It’s a translation problem.
A presentation was coming up — a CEO, a CTO, and a PM in the room. I’d spend hours writing notes on what I wanted to say, then walk in and answer like a designer: context-first, methodology-heavy, when what they needed was a business answer in 30 seconds.
I knew the work. I couldn’t explain it to the room. And this isn’t unusual: when communication breaks down, it doesn’t just lose a meeting — it loses budget, roadmap influence, and trust.
02 — Landscape
Every existing tool solves an adjacent problem.
Speech coaches
They grade how you talk, not whether your answer maps to the room’s actual priorities.
Deck builders
They polish the artifact, but don’t rehearse the pressure of defending the thinking behind it.
The gap
Own The Room trains you for this meeting, with these stakeholders, about this design.
03 — Research & framework
Two frameworks became the architecture.
Top-down decomposition
Who owns what?
I took the full workflow and asked one question of each task: does AI do this better, or does the human? Simulating questions and scoring performance are exactly what AI is good at. Writing context and choosing stakeholders require insider knowledge AI is structurally bad at.
Output-first
What does good actually look like?
Instead of designing the workflow first, I started with the artifact I wanted at the end: probing questions rooted in this designer’s project, feedback tied to what was actually said, and hard stops for hollow praise or generic prompts.
AI owns analysis, synthesis, and simulation.
The human owns context, judgment, and authorization.
04 — Design decisions
Six choices, and the tradeoffs I accepted.
Confirm the context before coaching
The AI produces a five-part context summary and stops until the designer confirms it’s accurate. The cost is friction at the start; the protection is that every later question is grounded in the right version of the work.
Research the role, not the stereotype
The AI pulls from trusted sources to understand company and role priorities. It slows setup, but guessing would be faster and wrong.
State the limits every session
The biggest risk isn’t failure. It’s that the tool works well enough that you forget it’s not a prediction. The disclaimer can become wallpaper, but letting it fade is worse.
Hide the questions until they’re asked
If you know the questions in advance, you’re memorizing answers. The discomfort of not knowing what’s coming is the point — even when it makes early sessions harder.
Feedback must quote the moment
Every note anchors to what the designer actually said and grades it Strong, Adequate, or Weak by how the stakeholder would react. Vague coaching is treated as a failure mode.
Separate validation from coaching
A validation skill verifies the setup; a coach skill runs the simulation and cannot run until validation completes. Two files mean more maintenance, but the check can’t be skipped by coaching logic.
05 — The human ownership model
A design philosophy, not a feature list.
Every task where AI is genuinely strong — analyzing documents, synthesizing data, simulating at scale — is one where the input is defined and the output can be evaluated.
Every task where AI fails — understanding your context, knowing your relationships, reading the room — requires being inside the situation. So the tool doesn’t try to own those things.
The designer decides what context to share, names the stakeholders, approves the summary, decides which feedback to act on, and decides when they’re done. That’s not a compromise. That’s the design.
06 — The moment that changed the build
I handed my own skill files to a fresh AI and asked where they fail.
1 — The memory promise
The skill claimed continuous memory even though each session starts fresh. The fix kept the behavior as a spec, while leaving the storage mechanism open.
2 — Unwritten dynamics
The AI can’t infer politics that aren’t written down. The prompt shifted from asking what stakeholders care about to why they care — returning that judgment to the designer.
3 — Undefined scoring
A numeric score became outcome-based levels: Strong, Adequate, or Weak, tied to how a stakeholder would actually react.
07 — The build
A system prompt and two skill files — testable the same day.
The governing rules — tone, data rules, what the human controls, and hard stops
The coaching simulation skill — its sequence and what it must never do
The verification check — five-part summary, hard stop, and limitation reminder
The artifact spec that preceded the build — what good looks like, what to avoid
08 — The test
It caught something I didn’t anticipate.
I ran the full session as a designer would. The tool didn’t just ask expected stakeholder questions — it revealed where the tool itself needed clearer boundaries: how memory should work, what political context AI cannot infer, and what “good” feedback must actually contain.
The result wasn’t a finished product pretending to be perfect. It was a working coaching system with its own limits visible enough to keep improving.
09 — Reflection
Test with other designers earlier.
The biggest open question isn’t whether the AI can simulate stakeholder pressure. It can. The question is how different designers respond to that pressure, and where the tool should create ramp-up without turning practice into comfort.
The next version should test anxiety, confidence, repeat use, and whether designers actually carry the stronger answers into real meetings.
The Five Capabilities
Applied honestly.
Reasoning
Separates what AI can infer from what only the designer can know.
Research
Uses trusted sources to make stakeholder questions less generic.
Simulation
Creates pressure without revealing questions in advance.
Evaluation
Scores what was actually said, not a generic speaking checklist.
Guardrails
Makes human ownership explicit, repeated, and operational.
Built to make designers harder to dismiss in the room.
The tool doesn’t make the case for you. It makes you practice making the case yourself — with pressure, specificity, and a clearer line between what AI can help with and what the designer must still own.