Reasoning Checkpoint
A design challenge, worked through in writing — no auto-grading, just a real attempt.
The Challenge
It's the end of Anna's first week. John hands her three sticky notes, each with a real problem from today's support inbox, and one question: "Who at BlueTicket should pick each of these up — and why?"
No code, no tools. This checkpoint is about the map you built in this Act: what kinds of companies exist, which roles do what, and how a feature travels from an idea to production.
What Your Answer Needs
- For "Payments are failing for some customers": name the role that should investigate first, and one other role that should be told.
- For "Fans say the checkout screen is confusing": name who decides whether to change it, and who would redesign it.
- For "The website is down for everyone": name the role that responds first, and explain why it isn't the designer or the PM.
- Say in one or two sentences whether BlueTicket is a product or a service company, and how you can tell.
- List the seven steps a new feature ("group discounts") would go through at BlueTicket, with the role responsible for each step.
Stuck? A Few Hints
- Ask "what part of the system is broken?" before "who is the best person?" — each role owns a part.
- Chapter 5's seat-selection table is the template for the last requirement.
Before You Move On
There's no single "correct" org chart — real teams overlap, especially at startups. What matters is the habit: when something breaks, first ask which part of the system it lives in. Anna will use exactly that habit for the rest of the year.
