Sprint 3: Complexity

"Build narrow. Test fast. Expand." — Solving for a real person in a domain you have to learn

Weeks 9–12 External Stakeholder Concepts: Human Value, Abstraction

The Ministry of Health of Bhutan has a 28-page clinical guideline for managing multidrug-resistant organisms — bacteria that resist most antibiotics. Globally, antibiotic resistance kills 1.27 million people per year. The guideline exists. The problem: no one working in a busy ER, an isolation ward, or a cleaning role can pause to read and interpret it in the moment they need it.

Piranavan Selvanandan, a technical consultant approached by contacts in Bhutan to make this guideline actionable, is bringing this challenge directly to you. He'll work with you in Weeks 10 and 11.

Your job is not to solve the whole problem. Find one specific human moment where the guideline fails the person who needs it. Design a human process that addresses that moment. Build something that supports that process. Iterate.

By Sprint End, You Will Have:

Sprint 3 Grading: Goals 20% (individual) · Weekly Reflections 20% (individual) · Demo 40% (individual) · Engagement 20%
🚦 The Differentiation Rule: No two students may work on problems that are more than 50% similar. In Week 9, you'll pitch your candidate problem in one sentence. The class decides if there's a collision. If there is, both students have 48 hours to differentiate their framing. First to stake a clear, specific claim owns the territory.

Before Week 9 Class

Transition + Preparation Sequence

Three things to do between Demo Day and Week 9. Do them in order — each one builds on the previous.

1 · 📓 Handwritten Reflection · Submitted

What I've Actually Been Building Toward

Five foundational claims about this course. After reading each one, write 2-3 honest sentences connecting it to your actual Sprint 1-2 work. Handwritten, photographed.

2 · 💬 AI-Discussion · Submitted

Claims in Practice

Structured AI-discussion that takes your handwritten reflection and pushes you to find specific evidence in your Sprint 1-2 work for each claim.

3 · 📖 Reading · No Submission

Sprint 3 Domain Primer

Tue, Mar 17

Read pages 1-8 of the Bhutan MDRO guideline and skim the rest. Come to class with one part you think is particularly hard for a clinical worker to act on.

Concepts: Staking a problem is a design act. Vague problems produce vague solutions.

📅 In-Class (Wednesday, Mar 19)

Collaborative Prompting + Problem Staking

  • Collaborative prompting session (individual → pair → quad → class → professor runs it live)
  • Piranavan introduction and context
  • Problem pitch round: stake your territory
  • First build: design the human process, then touch the computer
View Session Slides →
📋 Assignment

S3: Problem Stake Brief

Who is your user, what is the specific moment, what constraint makes it hard in Bhutan's context. 300 words max. This is a design claim, not a reflection.

IS● SDL

What human moment are you designing for? Describe the person as if you've watched them work. Handwritten, photographed.

SDL●

Concepts: AI simulation as a learning tool — finding the questions only a human expert can answer. Expert access used strategically, not generally.

Course Design — Live

Week 10 is being designed based on what Week 9 reveals

This is Adaptive Building in action — the same process you're being asked to demonstrate in your demos. Three possible paths depending on what happens in Week 9 class. The decision and reasoning will be posted by Saturday Mar 22.

🟢 Path A

If Week 9 lands well

+ more

Strong problem stakes, genuine Bhutan context engagement. Students move straight to AI persona simulation before Piranavan joins.

🟡 Path B

If execution hit friction

+ more

Problem stakes incomplete or still domain-level. Accelerated re-staking in pairs, then Piranavan validates. Simulation moves async.

🟣 Path C

If the design assumption was wrong

+ more

Genuine engagement but domain distance stalled rather than energized. Structured domain immersion first, then Piranavan as bridge-builder.

📌 Decision posted by Saturday Mar 22. It'll say which path (or hybrid) we're taking and exactly why — including what I observed in Week 9 that drove the call. This is the same process you're being asked to demonstrate in your demos: build something, get signal, adjust.

Assignments — confirmed after Mar 22

🥋 Dojo — AI User Simulation (structure depends on path) IS · AB
🪞 Weekly Build Reflection #2 SDL
📋 Build v1 submission — link + one decision + one known failure mode AB · IS

Concepts: MVP discipline — simplicity is a design decision, not a shortcut. Peer pressure reveals what expert review misses.

⏳ Tentative — plan confirmed after Week 10. What won't change: Piranavan joins for a second session, and you demo your current build to a peer role-playing your specific user. Two different kinds of pressure. Two different failure modes.

Assignments — confirmed after Week 10

🪞 Weekly Build Reflection #3 SDL
📋 Build v2 submission — what changed from v1 and why AB · SDL

Concepts: The demo shows the arc, not just the endpoint. Delta matters more than final state.

⏳ Tentative — plan confirmed after Week 11. What won't change: Wednesday Apr 9, live demo required. The demo shows the arc — where you started in Week 9, what changed your thinking, what exists now, and one known limitation. Slides alone are not sufficient.

Assignments — confirmed after Week 11

📋 Demo + Arc narrative AB · IS
💬 Sprint 3 Peer Observation IS
🌉 Bridge Reflection — Sprint 3→4: What does Sprint 3 tell you about whether you're ready for Sprint 4? SDL

What Comes Next

Sprint 4: Mastery — No curated options. You find the stakeholder, define the problem, and build the solution from scratch. Sprint 3 was scaffolded: the domain was given, the expert was provided, the document was there. Sprint 4 is what you do when none of that is handed to you.