First: Form Your Teams
Yesterday was individual and exploratory. Today is the first time you're working as an actual team.
Take 5 minutes:
- Agree on who's on your team
- Agree on which domain you're working in
- Make a shared copy of the Day 2 Workshop Template (link above) — one doc, all three of you editing it together
From Yesterday to Today
Yesterday you ran a four-step prompt sequence to find your problem. Here's how that maps to today's six-section doc:
| Yesterday | Today |
|---|---|
| Step 1 — who's affected | → Section 2: Who, and how many |
| Step 2 — who's most exposed | → Section 2: Who, and how many |
| Step 3 — specific failure moment | → Section 3: What's happening now |
| Step 4 — one real data point | → Section 4: Evidence (data point 1) |
If you didn't finish Steps 1–4 yesterday, go to the Day 1 workshop and run the prompt sequence for your domain first. Then come back here.
Today adds three things that weren't in Day 1: scale (how many people), why it matters (who pays the cost), and what you still don't know.
Build the One-Pager
Work through the six sections in order. Each one is a short paragraph, not an essay. Use Gemini one piece at a time.
1. Headline
Take your sentence from yesterday and paste it into section 1. Don't try to perfect it yet — you'll rewrite it at the end once the other sections are done.
2. Who, and How Many
You already know who from yesterday. Today add the scale — an actual number, even a rough one.
I'm working on [your domain and pain point]. I already know the specific person affected is [from your Step 1-2 work]. Now I need scale: roughly how many people like this exist in [city / nationally]? Give me one real number from a named source. One sentence, no elaboration.3. What's Happening Now
You identified the existing attempt in yesterday's domain reading. Now say specifically what it gets wrong — not just that it's imperfect.
The existing attempt at our problem is [the chatbot / ACCESS NYC / FAFSA / Craigslist filtering — whichever fits]. What specifically does it fail to do for [your specific person from section 2]? Answer in 2-3 sentences. Be concrete about the gap — what does that person need that this doesn't give them?4. Evidence
You have one data point from yesterday. Find a second one today — different angle, same domain.
I already have this data point: [your fact + source]. What's a second concrete number that strengthens the case from a different angle? Give me one number, one source, one sentence on why it matters. Nothing else.Check both numbers against the actual source before they go in the doc.
5. Why It Matters
Who actually pays the cost when this goes unsolved — and what does that cost look like?
When [your problem] goes unsolved, who pays the cost? Think beyond the obvious — what are the second-order effects? Answer in 2-3 sentences maximum.6. What You Still Don't Know
One or two honest open questions you'd need answered before you could build a real solution. You're not expected to have everything figured out.
Here's our problem statement so far: [paste your doc]. What's the most important thing we still don't know that would change our approach if we found the answer? Give me one or two questions, one sentence each.Polish the Headline
Once all six sections are done, come back to section 1 and rewrite the sentence.
Here are our six sections: [paste the full doc]. Rewrite our headline as one tight sentence using this format: [Specific group] struggle with [specific pain point] because [specific reason], and current solutions fail because [specific gap]. One sentence only.How to Run a Stakeholder Interview
Tomorrow you'll interview a real industry guest — someone who works in or around the problem your team has been researching. This is probably the first time you've done something like this. That's fine. Here's everything you need.
What an Interview Is For
You've been working with data. Data tells you what is happening — how many people, how often, what the numbers say.
An interview tells you why — and what it actually feels like to be the person inside your problem statement.
Those two things together are what make a pitch convincing. Anyone can find a statistic. Not everyone can explain why the problem feels the way it does to the people living it.
People Don't Say the Real Thing First
This is the most important thing to know going into an interview.
Ask someone "what's difficult about this?" and you'll almost always get a safe, surface-level answer:
"It's complicated." "The process takes a long time." "There's a lot of paperwork."
These answers aren't wrong. But they're not the whole story. People give you the easy answer first because they don't know you yet, and they don't know what you're going to do with what they say.
The real answer — the one that actually helps you — usually sounds more like:
"I didn't know who to call and I was too embarrassed to ask." "I was scared of making a mistake that would affect my whole family." "I felt like the system assumed I already knew things I didn't know."
Your job in an interview is to get to that second kind of answer. You do that by asking good questions, listening carefully, and following up on the things that sound interesting — not moving on to the next question on your list.
How to Structure It: Open, Explore, Close
Open (3–4 min)
Don't start with your questions. Start with a brief introduction and make the person feel comfortable.
- Say your name, where you're from, and what program you're in
- Explain what your team is working on in one sentence
- Say clearly: "We're not here to pitch anything — we just want to learn from your experience"
That last line matters. It tells them you're listening, not selling.
Explore (10–15 min)
This is the main part. A few simple rules:
Ask about what actually happened, not what they would do.
The most useful questions are about real past experiences, not hypothetical ones.
Instead of: "Would you use a tool that helped with this?" Ask: "Can you tell me about the last time you had to deal with this problem?"
Instead of: "Do you think this is a big issue?" Ask: "Walk me through what actually happens when this goes wrong."
Look for the moment things break down.
There's usually one specific step in a process where people get stuck, give up, or have to figure it out themselves. That's the most useful thing to find. Listen for phrases like "that's when it gets complicated" or "usually I just..." — those are signals to follow.
Follow the interesting thing, not your script.
If they say something surprising or emotional, go there. Don't just move to the next question. Say: "Can you tell me more about that?" or "What did that feel like?"
Two simple techniques that help:
Repeat the last few words as a question. It sounds simple, but it works.
Them: "The whole process just feels really overwhelming." You: "Overwhelming?" Them: [explains exactly what's overwhelming and why]
Name the feeling you think you're hearing.
"That sounds really stressful." "It seems like that put you in a difficult position."
If you get it wrong, they'll correct you. If you get it right, they'll open up.
Close (<1 min)
- Thank them for something specific they said, not just "thank you for your time"
- Ask if there's anyone else they'd suggest you talk to
- That's it — keep it short
Before the Interview: Write Your Questions Down
Since you'll be speaking in English and may be nervous, having your questions written in advance matters. You don't have to follow them exactly — but they're your backup if you get stuck.
Use this prompt to help your team prepare:
Here is our problem statement: [paste it]. We're interviewing someone with experience in [civic tech / government / nonprofit]. We want to understand: [paste section 6 — what you still don't know]. Write two interview questions for us. Each question should: be about real past experience not hypothetical, be specific to our problem area, be open-ended and not answerable with just yes or no, take about 2-3 minutes to answer. One sentence each. Nothing else.What a Bad Question Looks Like
Before tomorrow, check each of your questions:
- Does it have a yes/no answer? → rewrite it
- Does it start with "would you ever..." or "do you think..."? → make it past tense
- Is it so broad that anyone could answer it the same way? → make it more specific
Bad: "Do you think AI could help people in this situation?" Better: "Has your organization tried using any tools to help with this? What happened?"
Bad: "How often does this problem affect people?" Better: "Tell me about a specific time you saw this go wrong for someone."
The One Rule
Listen more than you talk. If you're filling silence, you're doing it wrong. Give people time to think — the best answers often come after a pause.
Draft Your Interview Questions
Tomorrow's AM session includes a field interview with an industry guest. Before 1pm today, your team needs at least two questions ready.
Good questions come directly from the gap your problem statement identified — specifically what you wrote in section 6.
Here is our problem statement: [paste it]. We're interviewing someone with experience in [civic tech / government / nonprofit — pick what fits]. Based on what we still don't know (section 6), what two specific questions should we ask them? Each question should be answerable in 2-3 minutes and produce something we could actually use.Class Question Brainstorm
Last 20–30 minutes of the day, after the professor's session.
Each team shares their two questions. As a class:
- Cut anything too broad to get a useful answer
- Sharpen the strongest ones into something specific enough to actually use
Goal: walk into tomorrow's interview with 5–6 strong questions, not 20 vague ones.