Version 1.0 · Entirely hypothetical. Mira, her business, conversations, dates, staff and capacity are invented for testing the worksheet. They are not research, endorsements, actual bookings or measured performance.
1. Audience and purpose
Mira is a fictional project-delivery adviser with experience leading design-agency operations. Her business sells scoped delivery reviews. She can explain how work passes between people and where ownership becomes unclear. A real profile would need to substantiate that experience.
Audience: owners of 8–25-person design agencies whose approved projects stall before the next stage starts. Decision: whether to change workflow, capacity or software. Purpose: help owners recognise the problem and understand when a delivery review might help. Outside this test: solo designers seeking clients and enterprise transformation teams.
Why this choice: Mira can demonstrate a specific judgement. A productivity audience would include many different needs. Team size describes this example's coordination problem; it is not The Tom Tribe's eligibility rule.
Starting channel: LinkedIn, based on a fictional observation that target owners discuss operations there. In real use, inspect those conversations or ask customers. This example-specific choice does not change Puro's Instagram priority.
2. Five questions
Every origin below is simulated. Real users must replace these with actual anonymous records. Dates demonstrate traceability, not research completed here.
On smaller screens, scroll the table sideways to see every column.
| ID | Question | Simulated origin and date | Decision | Demonstration |
|---|---|---|---|---|
| Q1 | Why does work sit untouched after the client approves it? | Fictional discovery note A, 3 Sep 2026; paraphrase | Inspect handoff before buying a tool | Approved task with no next owner |
| Q2 | Do we need another project manager or fewer active projects? | Fictional owner conversation B, 7 Sep; paraphrase | Coordination versus capacity | Unassigned work versus assigned overload |
| Q3 | How do we stop feedback arriving in five places? | Fictional process review C, 9 Sep; paraphrase | Feedback consolidation | One approver consolidating comments |
| Q4 | How can I tell a project is slipping before the deadline? | Fictional owner email D, 11 Sep; paraphrase | Earlier checkpoint | Blocked dependency and next checkpoint |
| Q5 | Which delivery decisions should still come to me? | Fictional workshop E, 14 Sep; paraphrase | Escalation boundary | Routine revision versus scope change |
Q1 first: recognisable moment, relevant expertise, simple board, no private footage required. Verify: missing ownership is the issue in the scenario; never claim it explains all delays. Real use also requires checking this wording with an actual owner.
3. Three series
S1 — Inspect this handoff
- Questions: Q1, Q4. Promise: spot one place approved work can become stuck and know what to inspect next.
- Sequence: stalled task → inspect transition → show missing instruction → limit and next check.
- Variation: stage, missing information and responsibility; the diagnostic sequence stays fixed.
- Three episodes: approved design with no next owner; approved copy with no completion criterion; launch waiting on an unscheduled dependency.
- Inputs: Mira's judgement and fictional board. New premises are hypotheses, not additional observed questions.
- Treatment: talking head plus reusable board graphic. Boundary: an owner cannot solve insufficient capacity or a missing client decision.
S2 — Which problem are you solving?
- Questions: Q2, Q3. Promise: distinguish similar-looking problems before choosing an intervention.
- Sequence: two explanations → diagnostic question → two examples → next step for each condition.
- Variation: coordination/capacity, scattered/conflicting feedback, missing brief/changing scope.
- Three episodes: another manager or less work in progress; one feedback channel or one authorised approver; clearer brief or paid scope change.
- Inputs: credible scenarios and reviewed decision rule. Treatment: talking head with two-column graphic.
- Boundary: problems can coexist; one sign is not a complete diagnosis.
S3 — The decision I would delegate
- Questions: Q5, Q3. Promise: see a routine decision an owner can hand over, with a clear escalation limit.
- Sequence: bottleneck → delegated rule → worked decision → exception that returns to the owner.
- Variation: decision type and escalation trigger.
- Three episodes: choose revisions within an approved brief; consolidate stakeholder feedback; move an internal checkpoint while preserving the client commitment.
- Inputs: agreed authority and fictional examples. Treatment: talking head plus rule/exception card.
- Boundary: commercial and specialist decisions remain with the authorised person; this example grants nobody authority in another business.
S1 diagnoses a transition, S2 compares interventions, S3 sets decision authority. Start with S1, then try an episode from S2 and S3. Three prepared series need not create three simultaneous commitments.
4. Complete episode
Series/question: S1/Q1. Title: Approved doesn't mean ready to move. Viewer outcome: inspect an approved task for next owner, action and checkpoint. Format: talking head and fictional task card. Duration must be established by an actual read and recording; neither was performed here.
On smaller screens, scroll the table sideways to see every column.
| Beat | Full spoken script | Screen direction |
|---|---|---|
| Situation | “The client approved the design on Tuesday. It's Thursday, and the next stage hasn't started. Before you buy another project-management tool, inspect this handoff.” | Camera, then card labelled FICTIONAL EXAMPLE: Design approved Tuesday / next stage not started Thursday. |
| Demonstration | “On this fictional task, the status says approved. But there's no next owner, no next action and no checkpoint. I'll add: Sam checks the approved files and confirms the production handoff by Friday afternoon.” | Show empty fields, then filled version. Sam is fictional. Keep text large; split across screens if needed. |
| Reasoning | “Now approval triggers an action someone can accept. That gives the team something specific to check instead of another message asking, ‘Any update?’” | Highlight owner → action → checkpoint, then camera. |
| Exception | “If Sam already owns the task but is overloaded, this won't fix capacity. Check the workload before changing the software.” | Ownership clear? Check capacity next. |
| Takeaway | “Open one approved task today. Can you name the next owner, the next action and the checkpoint? If one is missing, clarify it with the team. That's your first change to test.” | End on the three questions. No withheld answer. |
Caption: “Approval can be a status without a usable handoff. In this fictional example, we make the next owner, action and checkpoint visible. It is one diagnostic check, not an explanation for every late project. Try it on one approved task and check what happens next.”
Optional CTA for Mira: “Save the three questions for your next project review.” Puro would use the Content Map CTA when teaching this example to founders.
Assets: Mira supplies scenario and claim review; fictional coordinator Dev builds the card; editor Jules adds captions. Approver: Mira. Permissions: no real client data or outcomes. Business bridge: viewers see Mira's judgement before deciding whether a review is relevant. No enquiries or revenue predicted.
5. Sustainable arrangement
Pilot: four original videos per four-week cycle, starting with S1; one LinkedIn post weekly in this hypothetical plan. This is not Puro's cadence or a The Tom Tribe package. Capture: phone, tripod, quiet office, microphone, fixed camera, short audio check. Dev can prompt off camera. AI likeness production is unnecessary.
On smaller screens, scroll the table sideways to see every column.
| Work per four-episode batch | Mira minutes | Team minutes | Owner |
|---|---|---|---|
| Questions, evidence, assets | 20 | 40 | Mira + Dev |
| Scripts and claim check | 25 | 60 | Dev drafts; Mira checks |
| Setup and recording | 45 | 45 | Mira + Dev |
| Edit and captions | 0 | 160 | Jules |
| Review, corrections, approval | 20 | 40 | Mira + Jules |
| Publishing and response review | 20 | 40 | Dev; Mira interprets questions |
| Rework buffer | 20 | 35 | Mira + team |
| Total required | 150 | 420 | |
| Available in fictional cycle | 180 | 480 |
There are 30 expert and 60 team minutes spare. These are estimates, not timed results or a client-hour promise. An initial eight-episode plan doubles the variable preparation, scripting, edit, review and publishing rows, holding setup and buffer fixed: 235 expert and 760 team minutes. It exceeds both budgets; reduce to four.
Fallback: retry failed capture within the buffer; otherwise move the post. Never publish unapproved work. If the editor is unavailable, postpone or confirm replacement capacity and cost.
Illustrative action: Dev prepares Q1's card for Mira on 28 September; capture pencilled in for 30 September. Scenario dates only. Review: after four published episodes, compare actual effort, note relevant owners' questions and choose one explanation to improve. Sparse evidence means inconclusive, not market validation.
Finished map
Audience: agency owners facing stalled approved work. Questions: Q1–Q5, simulated. Series: Inspect this handoff / Which problem are you solving? / The decision I would delegate. Episode: Approved doesn't mean ready to move. Arrangement: four videos; 150 expert and 420 team minutes with owners and fallback.
This passes scenario specificity, distinct-series and capacity checks. The real-evidence check remains not satisfied for a real business: all question sources are invented. No episode has been recorded, published or measured.