AIQ
AIQ
Part of the Design Thinking for AI lesson guide. Teaching a different grade? 🌈 Explorer (5–7) · 🔧 Builder (8–10) · 💻 Hacker (11–14)
This age group is close to internships, first jobs, or building their own projects — frame the lesson as professional practice, not classroom theory. Open with:
"Building real AI products means balancing design, tech, ethics, and business. Let's learn the product development process from concept to launch."
Ask: "If you've used ChatGPT, a recommendation feed, or any AI feature that later got criticized publicly — biased outputs, a privacy backlash, something that just didn't work as advertised — what do you think went wrong in the process that built it? Was it a technical failure, or a process failure?" Let students debate for a minute; most real-world AI failures trace back to a process gap (skipped user research, no fairness review, unclear success criteria) rather than a purely technical bug, and that's the through-line for today.
Bridge: "Today's framework — discovery, definition, development, deployment — is close to what product teams at real companies use. If you end up building anything with AI, in a class project, an internship, or your own startup idea, this is the process that separates 'it works in the demo' from 'it works for actual users.'"
If your class includes students considering computer science, business, or design as a college path, note explicitly that this framework isn't unique to AI — it's the same product-development thinking used for any software or hardware product. What makes the AI case distinct is that two extra questions get added to every phase: what data would this need, and who could this get wrong or harm. Everything else — understanding users, defining requirements, shipping incrementally, monitoring after launch — is standard product practice they'll encounter again regardless of whether their future work involves AI specifically.
Present the lesson's content through the four-phase product lens named in this age band's summary — discovery, definition, development, deployment — mapping it onto the same three scenes, but treating each as a real engineering and business decision rather than a classroom exercise.
Discovery (maps to Scene 1, Find a Problem). Cover Empathize and Research as rigorous practice: user interviews, competitive analysis, and validating that a problem is real and significant enough to justify investment — not just interesting. Use the Problem Statement example ("Farmers waste 30% of water because they can't tell which crops need it") as a case study: ask students what data would need to exist to validate that 30% figure before a team committed resources to it — a plausible answer is measured irrigation records compared against actual crop water needs across a representative sample of farms, not a single farmer's anecdote. Push further: "If that 30% figure came from a study of ten farms in one region, how confident should a team be that it holds everywhere they want to sell this product? What would change their confidence?"
Cover Not Everything Needs AI as a genuine business decision: "Every AI feature carries ongoing costs — compute, monitoring, retraining, liability if it fails. A team should be able to articulate why AI specifically beats a rules-based system or a human process, not just that AI is available." Give a sharper example than the earlier age bands can handle: "A soil-moisture sensor with a simple threshold — 'water if moisture drops below X' — solves the farmer's problem without any AI at all, and it's far cheaper to build, explain, and maintain than a machine-learning model. AI becomes worth the added cost and complexity only when the pattern is too complex for a simple rule — for example, predicting water need days in advance from weather forecasts, soil type, and crop growth stage together. Discovery should identify exactly which version of the problem you're actually solving before committing to either approach."
Definition (maps to Scene 2, Plan the Solution). Data Check becomes a discussion of data strategy: sourcing, consent, representation, and whether the team has (or can ethically obtain) enough data before committing to an approach. Prototype and Success Metrics map onto defining measurable requirements — what would "working" actually mean, quantitatively, before writing code. Spend the most time on Ethics Check here: "Responsible teams run a bias assessment and impact evaluation before building, not after — asking who could be harmed, whether the training data represents everyone affected, and what the plan is for when (not if) the system gets something wrong."
Development and Deployment (maps to Scene 3, Build & Test). Introduce MVP with the added nuance of technical debt: an MVP is fast to ship but often accumulates shortcuts — fragile data pipelines, no automated tests, no plan for model drift over time — that a team has to consciously manage rather than ignore. Frame User Testing, Iterate, and Get Feedback as the deployment-and-monitoring phase: a real AI product isn't "done" at launch, it needs ongoing monitoring because real-world data shifts over time and a model that worked at launch can degrade.
Explain model drift concretely, since it's a genuinely important and under-taught concept: "A model learns patterns from data collected at one point in time. If the real world changes — new slang, a new product catalog, a global event that shifts how people behave — the model's old patterns stop matching reality, and its accuracy quietly degrades even though nothing about the model's code changed. That's why 'deployment' isn't the last step; a responsible team keeps watching the model's real-world performance indefinitely, not just testing it once before launch."
Ground the build-vs-buy tradeoff (which shows up in the quiz) with a concrete framing: "If your school wanted an AI chatbot for student questions, you could build one from scratch, fine-tune an existing model, or just use an off-the-shelf tool. Buying is faster and cheaper upfront, but means your data may leave your control, you're locked into someone else's pricing and roadmap, and you can't customize it as deeply. Building gives you control and customization, but costs far more time, expertise, and ongoing maintenance. Neither answer is universally right — it depends on the specific constraints."
These land well as a Socratic seminar or fishbowl discussion if your class has done that format before — the questions don't have single correct answers, and this age group is generally ready to sit with genuine ambiguity (e.g., "it depends on the stakes") rather than needing a clean resolution. If time is short, pick two rather than rushing all five; question one (good intentions, bad outcome) and question five (is a product ever "finished") tend to generate the most substantive back-and-forth.
Architect mode has no mascot and treats quizzes more like a portfolio checkpoint than a game — frame this one the same way in class: less "let's see who gets it right" and more "can you defend your answer the way you would in a design review." Encourage students to explain why the wrong options are wrong, not just why the correct one is right; that habit of eliminating plausible-but-flawed options is closer to how these decisions get made professionally, where there's rarely one obviously correct answer to begin with.
Close with: "Every AI product you'll ever build, or even critique, can be evaluated against this same framework: did the team really understand the problem, did they define success honestly, did they build responsibly, and are they actually monitoring what happens after launch? Most public AI failures fail at least one of those four."
For students heading toward a portfolio or career path in tech, note that this four-question framework (understand, define, build responsibly, monitor) is a genuinely reusable interview and self-assessment tool — being able to walk through it for a personal project is a stronger signal in a college application or internship interview than being able to describe the technology stack alone, precisely because it shows product judgment rather than just technical execution.
Extension activity (to fill a full class period): Have students work individually or in pairs to pick one real, publicly-known AI product or feature (something they use or have read about) and write a one-page "product post-mortem" or "pre-mortem": identify what problem it was likely trying to solve, one build-vs-buy or ethics tradeoff the team probably had to make, one way they'd measure whether it's actually succeeding, and one risk from ongoing monitoring (e.g., model drift, changing user behavior, a fairness issue that only shows up at scale) that the team would need to keep watching after launch. Have a few volunteers share their analysis and let the class push back with alternative interpretations — this mirrors the kind of design critique used in real product teams.
Remind students to be careful with claims they can't verify: it's fine to say "this product probably struggled with X" as a reasoned guess, but they should flag it clearly as speculation rather than stating it as confirmed fact unless they can point to a real source. That distinction — reasoned inference versus verified claim — is itself a professional habit worth reinforcing in any technical writing, not just this exercise.