Honest Take — Module 3: Backwards Design & Assessment — Outcomes First, Deliverables Over Quizzes #

The retrofit is the exercise where this module stops being theory, and I can predict the exact place it will bite. When you write the observable-outcome line for the artifact you audited in M1, you will resist stating it as concretely as the framework requires. The instinct is to write "the learner understands N+1 query optimization" — or whatever your stack's equivalent is — because that abstraction level is comfortable. Wiggins and McTighe will not accept it. The framework demands "the learner can identify three N+1 patterns in a codebase they didn't write and ship a fix that measurably reduces query count." The second sentence is harder to write, harder to assess, and harder to teach toward. That is the entire point. Forward-designed teaching lives at the first abstraction level; backwards design forces the second.

Your first attempt will be a level too vague, the framework will reject it, and the rejection is the framework working. "After this, the learner will be able to [specific verb] [specific object] [specific condition]" — if you cannot write that sentence, you do not have a course or a workshop yet. You have a topic and an instinct.

The honest framing the module implies: most engineering teaching, including most of yours, including most of the canonical teaching content in your ecosystem, is forward-designed. It starts from "what content should I cover" rather than "what should the learner be able to do." The shift is small in concept and enormous in operational consequence. A backwards-designed artifact has fewer lessons, sharper assessments, and graduates who can demonstrably do the thing. A forward-designed one has more content, easier completion, and graduates who feel like they learned something and often can't ship it. The first wins on outcomes; the second wins on satisfaction surveys, and the entire course-platform industry is built to reward the second.

Which brings me to the contrarian frame, and I am going to refuse to soften it: course completion is not the success metric. Graduate-shipped-real-thing is the success metric. You will resonate with that sentence intellectually in the first hour and resist it operationally in the second, because deliverable-based assessment is roughly ten times harder to grade than a quiz. A multiple-choice quiz is a unit test against mocks — fast, cheap, and passing it proves little about production behavior. A deliverable against acceptance criteria is an end-to-end test against staging. Engineers ship the mock-only suite because it is easy to write, then act surprised when production — the graduate's actual job — fails. You already make this argument in code review. The module just asks you to make it about your teaching, and to notice that almost nobody in the industry publishes graduate-outcome numbers because those numbers are small and computing them is work.

If you run a course platform or have shipped projects-based content, score your existing project specs against the evidence test honestly; my prediction is a uniform failure mode — specs that are too narrow ("build a CRUD app following these steps"), which grade easily and reveal nothing.

Two resistances to pre-empt. First, you will want to run the retrofit on a low-stakes artifact — the private guide, the internal doc — because the cost of admitting "this doesn't actually produce an outcome" is low there. Override it. Run the retrofit on the surface that matters commercially or reputationally; the higher-cost retrofit is the higher-leverage one. Second, once the retrofit reveals the gap, you will want to redesign everything you have ever shipped. Do not. Retrofitting an entire catalog at real depth is months or years of work and an aspirational trap. Retrofit one as proof, fix the next handful strategically, and design everything new backwards from the start. And when the first real submission against your new rubric fails to meet the bar, the urge to lower the bar will fire within minutes. Hold it. Lowering the bar is the precise mechanism by which completion theatre gets rebuilt.

Conclusion #

Backwards design forces the shift from "content covered" to "learner can demonstrably do the thing," and the assessment is the contract that makes the shift real. Retrofit one honest artifact; design one deliverable-based assessment with a rubric you would actually accept as evidence; write the contrarian-metric paragraph for your own teaching. The discomfort of grading deliverables is the diagnostic that you are no longer building completion theatre — and it is what makes M11's pricing math defensible later, because a price is only honest if the assessment behind it is.

Predictions #

• Your first observable-outcome sentence will be too abstract, and sharpening the verb will take three or four passes. "Understands" is the word to hunt; every appearance is a flag.
• The retrofit will reveal that at least one lesson or section in your chosen artifact is not load-bearing for the outcome. That content is debt, not teaching, and noticing it will sting slightly.
• You will be tempted to retrofit a low-stakes artifact. If you catch yourself choosing the surface where honesty is cheap, that is the tell.
• The minimum-content scaffolding you derive will be shorter than the existing artifact. Forward-designed teaching accumulates content past what the outcome requires; the shrinkage is the method working.
• Cathy Moore's action mapping will land first because it speaks engineering vocabulary; Dirksen second; Wiggins & McTighe third, because the academic register is heavier. Push through — the three-stage framework is the one you will still be using in five years.
• The first time you hold the rubric bar on a real submission, you will feel like you are being unkind. You are being the only kind that compounds: the graduate who is made to actually do the thing is the one who recommends the course on outcomes rather than vibes.