When someone new joins a team, most organizations follow a familiar playbook: share company materials, walk through project history, and explain roles and responsibilities. The documents exist, yet the same questions keep coming back once work actually starts.
"Who should I ask first in this situation?" "Can we implement this client request right away?" "Should we delay launch because QA found an issue?" "Is this a developer call or a PMO decision?"
According to Gallup, only 12% of employees strongly agree that their organization onboards new hires well. SHRM reports that just 29% of new hires feel prepared and supported to perform in their new role. Onboarding is hard not only because information is missing, but because new members have not yet practiced making decisions inside real work context.
Onboarding Is Context Learning, Not Document Delivery
Good onboarding does not stop at explaining company rules. It helps new members understand how the company works, how decisions flow, what project standards look like, and what each role owns.
Many programs still rely on documents: company PDFs, project overviews, process guides, tool manuals, and role checklists. Those materials matter. The gap is that reading them is not the same as judging what to do when a deadline slips or a client changes scope mid-sprint.
A Case From Week One on a New Project
Imagine a new PMO joining a global website build. The project folder has timelines, owners, deliverables, and reporting rules. In the first week, the client asks for an extra feature before launch.
The change process is documented. In practice, the new PMO still wonders: reply yes immediately, ask developers first, estimate schedule impact, treat it as scope change, or escalate internally first?
What they need is not a definition. They need judgment order. Scenario-based onboarding gives that practice before the real stakes arrive.
Why Scenario-Based Onboarding Works
Scenario onboarding presents situations close to real work and asks people to choose a response.
Example: A client requests a new feature one week before launch. As PMO, what should you do first?
1. Say yes because the client asked. 2. Ask developers if they can work overtime. 3. Clarify the request and check schedule, scope, and risk impact. 4. Reject it and push everything post-launch.
The point is not picking "3" alone. It is explaining why 3 is safer and what risks the other options create.
What Changes When You Turn Scenarios Into Quests
First Run turns these scenarios into in-game quests. New members join Make Feelbetter, a fictional IT company, choose a role—Developer, PMO, Publisher, Planner, or Designer—and meet NPCs across a campus map.
PMO NPCs focus on schedule and risk decisions. Developer NPCs present API and debugging cases. Planners practice turning vague requests into clear requirements. Designers judge CTA hierarchy and UI consistency.
Players make choices, get immediate feedback, and follow role-specific paths that can be reused for repeat training.
Choices and Feedback Matter More Than Points
Game-based onboarding is not automatically better. Points, badges, and rankings alone can distract from learning. Research suggests scenario design works when learners judge realistic situations—but excessive game chrome can get in the way.
Strong onboarding quests should:
- Reflect situations that happen often in real work.
- Include plausible wrong answers, not obvious traps.
- Give specific feedback after each choice.
- Reflect role responsibilities.
- Increase difficulty gradually.
- End with a report showing strengths and gaps.
That is the direction First Run aims for: not a trivia game, but a way to rehearse how the company and project actually operate.
Closing Thoughts
Documents still belong in onboarding. They just cannot carry full work context alone. The shift ahead is from reading training to experiencing it. First Run is one attempt to do that through scenario quests.
---