Live content — may be updated during class

What Do You
Actually Know?

I analyzed every assumption audit. Today: what I found, what worked, and then — your partner tells you where you're wrong.

What We're Doing Today

Why This Skill Matters
More Than You Think

If you can't see your assumptions, you can't improve anything — not a product, not a class, not your career.

The professor and the sleeping student

Imagine a professor designs their class. A student falls asleep in the back row.

The professor assumes: "They were up late playing video games. They don't care."

The reality: That student worked a night shift to pay rent and came straight to class.

Same behavior. Completely different problem. And if the professor can't see their own assumption, they can't help that student — or design a class that works for both kinds of students.

Why this connects to the assumption audit

This is what the assumption audit was for. Not a homework exercise — a muscle you need for the rest of your professional life. Every time you design for someone, interview a user, pitch to a client, or lead a team — your hidden assumptions are either helping you or sabotaging you.

Today we practice catching them.

What Worked

These students aren't smarter. They pushed past the first answer.

Caught their own projection

"I think that my solution to push him might be interpretation because that's what I needed to fix a similar issue."

Seeing yourself in the solution you're designing for someone else — and naming it — is hard. This student did it.

Distinguished stated problem from real barrier

"I initially assumed the issue would be forgetting to drink water. However, I learned the real barrier is taste and sensory preference... That shifted my understanding from designing a tracking system to exploring substitution strategies."

Started with one theory, let the evidence change direction. That's the move.

Designed two different paths depending on which assumption holds

"If tradeoffs-first: a keep/pause/reduce table. If planning-first: a weekly template with fixed commitments mapped and protected blocks."

Didn't just say "I'd change my approach." Built two artifacts. Ready for either answer.

Went deeper than the surface problem

"His family and how he was brought up — wasting time is a no-go. The internal factors must be handled first because the drive to help his family makes it hard to prioritize self-care."

Understood that the problem isn't scheduling — it's identity and cultural values. That changes everything about the solution.

Evidence vs.
Your Story About the Evidence

Quoting what someone said and interpreting what it means are two different things. Most submissions blurred them.

Quick note: several submissions were raw Dojo transcripts — not the extracted deliverable. The assignment asked you to write your assumptions as a structured list. A conversation is not a document. If your audit was a transcript paste, you'll need to extract during the sharpening exercise today.

See the weak vs. strong examples
What one student wrote as "evidence"

"He'd rather watch movies than go to the gym."

→ Conclusion: "He needs to stop being lazy."

That's evidence he sometimes chooses rest. "Lazy" is your word, not his. Preference ≠ character flaw.

What another student wrote

"He said he doesn't like the taste of plain water and described it as 'bland.' He mentioned liking the taste and fizz of diet soda."

→ Then admitted: "I'm assuming taste alone is the main barrier, but I don't have confirmation that caffeine or sweetness isn't also important."

Quotes what was said. Flags what was guessed. That's the standard.

In industry, a client will rarely correct your story about them.
They just stop returning your calls. Today your partner will tell you.

"If I'm Wrong, I'd
Change My Approach"

"I'd adjust" is not a plan. Name the specific artifact, feature, or question you'd pursue instead.

Escape hatch

"If this assumption is wrong, I would need to change my approach and focus on a different issue."

Change to what? Which issue? This doesn't tell you what to do on Wednesday at 2pm.

Actual contingency

"If tradeoffs-first is wrong, the artifact changes from a keep/pause/reduce table to a weekly template with fixed commitments mapped first, then protected sleep and interview blocks."

Two artifacts. Two plans. When the assumption breaks, there's already a next move.

Why this matters in 15 minutes

Your partner is going to challenge something you assumed. If your only plan is "I'll adjust" — you'll freeze. If you've already thought about specifically what changes, you can pivot in real time.

Professionals don't hope they're right. They prepare for being wrong.

You Built a Solution
For Yourself

Projecting your experience onto someone else is the fastest way to build something nobody uses.

From your own words

"I have no evidence. I just used my experience with the general dislike of apps from the popular opinion online."

"I think that my solution to push him might be interpretation because that's what I needed to fix a similar issue."

These students aren't ahead because they avoided projection.
They're ahead because they named it. You can't fix what you don't see.

What to watch for during the challenge

If your partner says something that surprises you, pay attention. That surprise is the distance between their reality and your projection.

Sharpen Your Assumptions

Write 3 assumptions — specific enough to be wrong. On paper. No screens. No AI.

12:00
Instructions for each assumption

If you completed the audit — pull your top 3 and rewrite them using what you just saw. If you submitted a transcript — extract your assumptions now. If you didn't submit — build them from what you remember.

For each one:

  1. The assumption — specific enough to be wrong. "They have bad time management" = untestable. "They delay because the assignment looks simple from the title" = your partner can say yes, no, or it's more complicated.
  2. What's evidence vs. what's your story? — Which part did your partner actually say? Which part did you fill in?
  3. If wrong, what specifically changes? — Name the different artifact, feature, or conversation you'd pursue. Not "I'd adjust."

The Challenge Session

The goal is not to be right. The goal is to find where you're wrong before you build.

The Move

  1. Read your assumption out loud — exactly as written. Don't soften it.
  2. Say what you're basing it on: "You said [X]. I assumed [Y]."
  3. Ask directly: "Am I right, wrong, or is it more complicated?"
  4. Write what they say. On the same paper. Right next to the assumption. Now, not later.
See an example exchange
Example

"I assumed your main problem is eating when you're not hungry because of cravings. You told me you eat ahead of your meal prep. But I'm guessing the 'why' — I don't know if it's cravings, boredom, or something else."

"Am I right about cravings, or is something else going on?"

What might come back

"Yeah, it's mostly cravings." → Assumption holds.

🔄 "It's more that I'm bored when studying." → Close but different trigger. Approach forks.

"Actually I cook too much and feel guilty wasting it." → Completely different problem.

Read Your Assumptions

Present your assumptions. Your partner responds. Write what changes — right now, not later.

15:00

Presenter

  1. Read each assumption exactly as written
  2. Say what evidence you have vs. what you guessed
  3. Ask: "Am I right, wrong, or more complicated?"
  4. Write their response on the same paper — right now
Guidance for the partner / stakeholder
  • If right — say what specifically they understood
  • If close — explain what's missing. Not just "not quite"
  • If wrong — say it directly. In industry, clients don't correct you — they just disappear. Your honesty here is more valuable.
  • If they projected — tell them: "That's your thing, not mine."

Your Partner Presents

Same rules, reversed. Being "nice" by confirming everything helps no one.

15:00

Your partner reads their assumptions about your problem. You respond honestly.

As the stakeholder: the most useful thing you can do is be specific about where they're wrong — and why.

You Can't Build What
You Don't Understand

Your partner just told you where your assumptions break. Now ask yourself: do you actually understand their world well enough to build something useful?

The Domain Learning Assignment

Your partner's problem lives in a domain — time management, health behavior, motivation, job searching, cultural identity. You're not an expert in it. That's the gap.

The Domain Learning assignment asks you to close that gap — not by becoming an expert, but by building a mental model strong enough to make good design decisions.

  • What does research say about the kind of problem your partner faces?
  • What do practitioners know that your partner might not articulate?
  • What patterns exist in how people actually solve (or fail to solve) this kind of problem?

The challenge session told you where you're wrong.
Domain learning tells you why — and what to do about it.

Why this matters for your demo

On Demo Day, you'll need to show that you understood your partner deeply enough to build something they couldn't have asked for. That requires more than interviewing — it requires developing your own knowledge about their world.

Students who skip domain learning build obvious solutions. Students who do it build solutions that make their partner say: "How did you know that?"

You Design
Your Own Demo

You choose the format. Think of it as: a hiring committee asks "Show us how you solved a problem for someone."

What format can your demo take?

Written report. Slide deck. Live demonstration. Interview / podcast style. A combination. It's up to you — as long as you can deliver it in your time slot.

Demo Day logistics — Wed, March 11

Two groups running simultaneously. 5 pairs per group.

20 minutes per pair:

  • Person A: 7 min presentation → 3 min for peers to complete peer evaluation
  • Person B: 7 min presentation → 3 min for peers to complete peer evaluation

Your partner validates live: "Did they get it right? What did they understand about me that I didn't expect?"

The 5 beats your demo must hit — in any format
  1. "Here's my partner and the problem I discovered."
    Not what you assumed. What you actually learned.
  2. "Here's what I assumed — and where I was wrong."
    Today's challenge session gave you this material.
  3. "Here's what I built and the key decisions I made."
    Why this approach and not a different one?
  4. "Here's what changed after the challenge."
    What did you revise, cut, or add based on your partner's feedback?
  5. "Here's what required my judgment — not just AI."
    What part of this solution couldn't have been generated by a tool?

The strongest demos show where you were wrong and what you did about it.
That's what separates understanding from guessing.

Plan Your Demo

Use the rest of class to work with your partner. You have real feedback now — translate it.

Right now, with your partner

  • What assumptions held? What broke?
  • What's your revised understanding of the problem?
  • What format will your demo take? Why?
  • What do you still need to find out before you build?
This week's assignments

Demo Design

Design how you'll demonstrate your work. How do you show that you understood someone deeply enough to build something they couldn't have asked for?

Thu, Feb 27

Domain Learning Plan

Your partner's problem lives in a domain — time management, health behavior, job search, motivation. What does science say about it? What do experts know that you don't yet?

Sat, Mar 1

Weekly Reflection

What changed in your understanding after today's challenge? What are you building differently?

Sat, Mar 1
→ Sprint 2 Landing Page
arrow keys to navigate