This is an independently written lesson informed by Kent C. Dodds's public work. It is not an official MEGA lesson or a reconstruction of paid material. QueueCare, the appointment product used throughout this week, is an original teaching example. You need basic experience changing an application; no particular AI tool is required.
Learning goals
- Distinguish a product result from the implementation that supports it.
- Assign ownership across a whole user journey.
- Apply judgment to system tradeoffs before increasing implementation speed.
- Choose leverage that reduces repeated work without hiding its costs.
The shift changes the bottleneck
Kent distinguishes code output from the results people experience. He argues that judgment remains central as agents take on implementation. That is a useful starting point for deciding where to spend your attention. Read Kent's account of outcome ownership.
Consider QueueCare, a small booking service for community repair clinics. Volunteers open appointment slots. Residents reserve them. Coordinators want fewer unfilled slots and fewer people turned away. A request arrives: “Add AI reminders.” An agent can quickly create templates, a settings screen, and a scheduled job. None of those artifacts establishes that reminders help residents attend.
The first engineering task is to locate the problem. Perhaps residents forget. Perhaps the address is unclear. Perhaps the bus stops running before evening appointments. Each explanation calls for different software, and one may call for changing clinic hours. Fast implementation amplifies the consequences of choosing the wrong explanation.
A practical shift is to begin each task with an outcome hypothesis: changing a particular behavior for a particular group should improve a defined result under stated conditions. This is a claim you can later inspect. “Implement reminders” only names output. “Help residents notice a scheduling conflict early enough to cancel” connects behavior to a useful result.
Ownership follows the journey
Ownership means being accountable for the result while others perform parts of the work. It does not require doing every task yourself. For QueueCare, the journey crosses the booking page, calendar, email provider, cancellation route, coordinator dashboard, and clinic check-in. An owner needs enough visibility across these boundaries to identify where the result is lost.
Start by writing the path in ordinary language. A resident chooses a slot, receives confirmation, receives a reminder, attends or cancels, and sees an accurate final status. Then mark every transfer between components. A successful queue insertion only proves the scheduler accepted work. A provider receipt proves something different from the resident reading a message. A cancellation button is useful only if the capacity becomes available again.
Assign one person the decision to release and one person the follow-up review. Agents can gather evidence and propose fixes, but the product owner must resolve conflicts between attendance, messaging costs, privacy, and coordinator workload. Shared implementation is useful; an unspecified decision owner causes stalled or contradictory changes.
Judgment means choosing among real options
Judgment improves when options expose their costs. Ask your agent to propose several ways to address the same user problem, using the same comparison criteria. For QueueCare, options include clearer confirmation text, one fixed reminder, and a conversational assistant. Compare expected benefit, cost, failure behavior, reversibility, and operational burden.
Clearer confirmation is cheap and easy to reverse, but may not reach someone a week later. A fixed reminder creates a new delivery dependency, but its rules are inspectable. A conversational assistant can handle varied replies, but adds interpretation errors and more complex support. The right choice depends on what has been observed, rather than which option demonstrates the most AI.
Separate decisions that can change cheaply from commitments others will depend on. Button text can usually change quickly. An externally used cancellation API, a retention promise, or a billable messaging contract deserves more care. Record why a choice was made so later agents do not repeatedly reopen settled questions without new evidence.
Systems thinking exposes displaced costs
A local improvement can make the whole system worse. Sending more reminders might increase clicks while annoying residents. An automatic cancellation policy might improve apparent attendance by removing people who could still attend. A coordinator dashboard might save engineering effort while adding twenty minutes of manual reconciliation per clinic.
Use a small causal model. A reminder may increase awareness; awareness may increase early cancellation; early cancellation may make a slot available; availability only helps if another resident discovers and reserves it. This chain reveals missing work. A reminder feature alone cannot guarantee better capacity use.
Identify a primary result, a leading indicator, and a guardrail. In our example, the result is useful attended appointments per clinic. Early cancellations are a leading indicator. Complaints and incorrect cancellations are guardrails. These labels are an original design framework for this lesson, not terminology attributed to Kent.
Worked example: a decision that can be inspected
Here is a completed decision record for QueueCare. Numbers are hypothetical assumptions for teaching, not measured product results.
Problem: Residents discover conflicts too late to release slots.
Evidence: 8 of 12 recent missed bookings had no early cancellation.
Unknown: Whether those residents saw their confirmation email.
Chosen slice: One reminder 24 hours before a confirmed booking.
Message: Local appointment time, address, cancellation link.
Excluded: Free-form chat, automatic cancellation, SMS rollout.
Owner: Clinic product lead.
Result: More released slots get filled before clinic opening.
Guardrails: No reminders after cancellation; no duplicate sends.
Review: After three clinics, compare equivalent booking groups.
Stop: Any confirmed reminder to the wrong resident.The evidence supports investigating late conflicts; it does not prove forgetfulness. The chosen slice deliberately preserves uncertainty. It can test whether a timely prompt changes behavior while keeping the resident in control. An incorrect automatic cancellation would change the service promise and create more serious harm.
Suppose the first clinic produces six early cancellations instead of two, but none of those slots gets filled. The reminder mechanism may be working while the product outcome remains unchanged. The next decision might improve slot discovery instead of adding more reminder channels. If coordinator work rises sharply, the team must include that cost in its decision.
Leverage comes from making a reliable capability reusable. Kent's Kody introduction describes turning useful agent-authored work into durable packages available to other agents. The transferable idea is to preserve a proven capability instead of recreating it in every conversation. Read the first-party Kody introduction. For QueueCare, that capability could be an audited reminder dispatcher, with ordinary deterministic rules for ordinary recurring work.
Failure modes
- Counting merged pull requests as proof that residents benefit.
- Improving one component while pushing work onto coordinators.
- Using a polished demo to resolve an unanswered product question.
- Leaving follow-up ownership unspecified after release.
- Replacing a simple recurring rule with repeated model interpretation.
Practice
Choose one requested feature in your own product, or use QueueCare. Write a decision record with the same fields as the example. Draw the journey as a plain numbered list. Identify at least three component boundaries and explain what evidence each boundary can provide.
Acceptance requires three viable options, a justified choice, one explicit unknown, one result measure, two guardrails, and an assigned review date. Reject output measures such as lines written as the primary result.
A strong solution connects the proposed behavior to an observed difficulty. It does not claim the observation proves the hypothesis. It chooses the smallest useful way to learn and names what would cause a different decision. For QueueCare, a useful answer can select confirmation improvements instead of reminders if the evidence points to unclear instructions.
Check your understanding
- An agent finishes every ticket. Has the product outcome been achieved? Answer: No. Ticket completion establishes output; inspect the user result.
- Why track coordinator work? Answer: A feature may move costs rather than reduce them.
- What makes a reusable dispatcher useful leverage? Answer: Repeated work can use a tested capability with known behavior and operating costs.