Frame a Problem Your Team Agrees On | Heidelberg AI Curriculum
T17-L02
Frame a Problem Your Team Agrees On
Turn a vague request like "we need an AI tool for X" into a one-page problem statement your team signs off: who has the problem, what's hard, what a useful result looks like and how you'll know. Includes a short stakeholder conversation and an assistant that challenges your framing.
Your group leader comes back from a conference and says it in the Monday meeting: "We need an AI tool for the literature." Everyone nods. You're asked to sort it out. Over coffee you find that each person heard something different. The PI (principal investigator, the group leader) imagines a chatbot over the group's 900 PDFs. A PhD student wants an alert for new papers. The lab manager hopes it will write the background section of the next grant.
In a company it sounds the same. The managing director of a 25-person lab-supplies distributor says: "We need AI for our supplier contracts." Purchasing wants to find cancellation terms fast. Finance wants to spot price-increase clauses. The director, it turns out, is still annoyed about a service contract that renewed itself for two years.
If you pick one of those and build it, two people will be disappointed and one may not use it either. You are at Level 2 Power user: when your framing is wrong, your team pays for it, in weeks spent on the wrong thing and a tool nobody opens. This book shows you how to turn the request into one page the team agrees on, before anyone chooses a tool.
After this you can
Turn a request that names a tool into a problem statement that names people, a hard step and a result.
Run a 20-minute conversation that finds what the people involved actually need.
Use an assistant to find the gaps in your framing without letting it write the framing for you.
Write a test for the result that someone other than you can run.
Get two colleagues to agree to the same page, in writing.
A real request from your group or team that names a tool or says "AI" before it says what's wrong.
A shared document your team already uses: a Word file in your shared drive, a Google Doc, a wiki page. Pick whatever your colleagues open without a new login, because they have to read and sign it.
A chat assistant for the challenge step. Use Claude if your lab or company approves it: it's good at reading a short text closely and asking pointed questions. ChatGPT works as well. Your problem statement should contain no or confidential terms, so it's safe to paste. If it does contain them, take them out first ().
Two colleagues who are affected by the problem and have 20 minutes each.
About 105 minutes: 14 to read, about 90 to do, spread over a few days.
The idea in one page
A request that names a tool is a solution looking for a problem. "An AI tool for the literature" tells you what someone wants to buy, not what hurts. When five people hear it, you get five problems. None of them is written down, so nobody notices they differ until something has been built.
The fix is one page with four parts. Each part has a question and a test for whether you've answered it:
Part
The question
You've answered it when…
Who
Who has the problem, and how often?
You can name the roles and put a number on it: "four PhD students, every week".
What's hard
Which step is slow, error-prone or annoying today?
You can describe the step without naming a tool, and give one figure from today: minutes, errors, money.
A useful result
What would be good enough, in their words?
Someone affected says "yes, that would help" when they read it.
How you'll know
What check will show the result works?
A colleague could run the check without asking you, and it has a pass mark.
Add two short lists: out of scope (what you've decided not to solve now) and open questions (what you don't know yet). Then a line for two names and a date.
The page grows through the Structure it ⇄ Understand it loop. You write a first draft from what you think you know (Structure it). You test it against the people who have the problem and against an assistant that argues with you (Understand it). Then you rewrite it. Two rounds are usually enough.
Why the conversation matters. The person who made the request knows why they asked. The people doing the work know where it actually hurts. You need both, and the gap between them is where the real problem usually sits.
Why an assistant helps, and where it stops. An assistant is good at spotting what's missing from a short text: an assumption nobody checked, a group you forgot, a test that could pass while the problem stays. It knows nothing about your team, so it can't tell you which problem matters. Ask it to challenge the page. Don't ask it to write the page.
Why two signatures. At Level 2 your team acts on what you write. A signature turns "I think this is what we want" into "we agreed this is what we're solving". When someone later asks for the grant-writing feature, you can point to the page and say it's out of scope for now.
Worked example: from a request to a signed page
Both versions follow the same steps. Follow the one closer to your work. The conversations and assistant answers are typical examples written for this book.
Lab: "an AI tool for the literature"
Structure it: the first draft (15 min). The postdoc writes what she thinks the PI meant:
Who: everyone in the group. What's hard: too many papers. A useful result: a chatbot over our PDFs. How you'll know: people use it.
It's honest, and it fails every test in the table. "Everyone" has no number in it. "Too many papers" isn't a step. The result names a tool. "People use it" can pass while the problem stays.
Understand it: two conversations (2 × 20 min). She books twenty minutes with the PI and twenty with a second-year PhD student. She asks the same five questions and writes down the answers word for word:
When did this last cost you time? Tell me what happened.
What did you do instead?
How often does that happen?
If it were solved, what would you do differently next week?
What would make you stop using a solution?
The PI's story: in last month's lab meeting someone asked which paper showed the knockout phenotype in the liver. Nobody could find it. It took twenty minutes after the meeting. The PhD student's story is different and sharper. In his first three months he didn't know which forty papers the group relies on. He read the wrong ones, and he still can't find the page that supports a claim in his thesis draft. His answer to question 5: "If it gives me a paper without the page, I'll go back to asking people."
Now she knows two things she didn't. The hard step is finding the paper and the page behind a claim, not reading. And the people who suffer most are new students, not the PI.
Understand it: the assistant challenge (10 min). She rewrites the draft, pastes it into Claude, and asks it to argue. The prompt, the text she sends to the assistant, asks for challenges only, and the <statement> tags mark where her page starts and ends:
You are a sceptical colleague reviewing a one-page problem statement.
Do not rewrite it. List, briefly:
1. Assumptions we state as facts but have not checked.
2. People affected by this problem who are not named.
3. Ways our test could pass while the problem stays unsolved.
4. The simplest way to get the result without AI.
Then ask me the three questions you would ask in the meeting.
<statement>
[paste the page]
</statement>
Three points in the answer are worth keeping. The test uses questions the PI can answer from memory, but the users are new students, so their questions should be in the test. The page assumes a list of "the group's key papers" exists, and it doesn't. And the non-AI option: an annotated reading list, forty papers, one line each on what the group uses them for. Its other points (a data-protection review, a budget line) don't apply to forty published papers, so she drops them. The assistant can't know which of its points matter. She can.
Structure it: the rewrite. The loop has changed the problem. Here is the page, trimmed:
Who: new group members, about three a year, in their first six months; and anyone checking a claim before a paper or thesis goes out.
What's hard: finding which of the group's papers supports a claim, and on which page. Today it takes 10 to 20 minutes per claim, or someone asks the PI.
A useful result: a new student asks a question about the group's core papers and gets the paper and the page within two minutes, then reads the passage themselves.
How you'll know: the PI and two students write 12 real questions. For at least 10, the result names the right paper and page. A new student runs the check, not the builder.
Out of scope for now: alerts for new papers; drafting grant text.
Open questions: which 40 papers are "core"? Who keeps that list current?
Agreed by: PI, second-year PhD student, date.
The PI signs it and adds one line: the core list comes first, and he'll write it. That's the annotated reading list the assistant suggested, and it may solve half the problem on its own.
Choose tools and Build it (briefly). Only now does the question of a tool come up. The page says what the tool must do (answer with paper and page) and how it will be judged (10 of 12). Choosing one is T16-L02 · Choose Tools Your Team Can Use, and Afford. Building a collection of papers the group can ask questions of, with answers that cite the page, is T04-L02 · Curate a Document Set Your Team Can Ask. Both start from this page.
Company: "AI for our supplier contracts"
Structure it: the first draft (15 min). The office manager writes: "Who: purchasing and finance. What's hard: contracts are hard to search. Useful result: an AI that answers questions about contracts. How you'll know: saves time."
Understand it: two conversations (2 × 20 min). Same five questions, to the head of purchasing and the director. Purchasing's story: finding a cancellation clause means opening four PDFs, perhaps ten minutes a week. Annoying, but small. The director's story is the one with money in it. Last year the service contract for the warehouse scanners renewed for two more years because the three-month notice period passed and nobody noticed. The replacement they'd planned had to wait. His answer to question 4: "I'd get a list every quarter of what's coming up, and I'd decide in time."
The hard step isn't searching. It's knowing a notice deadline is coming before it passes.
Understand it: the assistant challenge (10 min). He removes supplier names and amounts, pastes the rewritten page into the assistant the company approved, and uses the same prompt. Worth keeping: Which contracts are only on paper? (about thirty, in a cabinet). Who adds new contracts, and would they update anything? And the non-AI option: a spreadsheet with one row per contract and a column for the notice date, with a calendar reminder. He recognises that a spreadsheet could do the reminding. What takes time is filling it from 180 PDFs the first time, and that's where AI might help.
Structure it: the rewrite.
Who: the director and head of purchasing, who decide on renewals; about 180 active contracts.
What's hard: noticing a notice deadline before it passes. Last year one was missed, and that cost two years on the wrong service contract.
A useful result: a list, updated monthly, of every contract whose notice deadline falls in the next 90 days, with the clause and page it comes from.
How you'll know: purchasing picks 15 contracts whose terms they know. The list gets every notice date right and marks any it can't find as not found, not guessed.
Out of scope for now: price-increase clauses; the 30 paper-only contracts until they're scanned.
Open questions: who adds each new contract to the list?
Agreed by: director, head of purchasing, date.
In both cases the first draft named a tool and the signed page named a deadline or a page number. The conversations found the real problem. The assistant found the gaps. Neither could have done the other's job.
What goes wrong
The tool stays in the problem.Symptom: the "useful result" line says chatbot, agent or dashboard. Fix: rewrite it as what someone can do afterwards that they can't do today. The tool goes in Choose tools.
Only the person who asked gets a say.Symptom: the page reflects the PI's or director's view, and the people doing the work don't recognise their problem in it. Fix: talk to at least one person who does the task every week. Ask for a story, not an opinion.
The test can't fail.Symptom: "saves time" or "people find it helpful". Fix: write a check with a number and a pass mark that someone else could run on real cases: 10 of 12 questions, all 15 notice dates.
The assistant writes the page.Symptom: a smooth, complete statement that nobody in the team would have written, full of interest groups and risks that don't apply to you. Fix: ask only for challenges, as in the prompt above. Keep the points that match what you heard and drop the rest.
Everything is in scope.Symptom: three problems on one page, because each person should get theirs. Fix: pick the one with the clearest cost today and put the others under out of scope for now. They're recorded, and they can have their own page later.
Agreement by silence.Symptom: you send the page round, nobody answers, and you take that as a yes. Fix: ask two named people to sign by a date. If someone won't sign, find out why. That objection is the next round of Understand it.
Do it yourself (90 minutes, over a few days)
Structure it (15 min). Take a real request from your team. Write a first draft of the four parts in your shared document, plus out of scope and open questions. Don't polish it. Mark every line you're guessing.
Understand it: conversations (2 × 20 min). Book two people: the person who asked, and someone who does the work. Ask the five questions. Write their answers word for word, especially the stories and the numbers.
Structure it (10 min). Rewrite the page from what you heard. Check each part against its test in the table.
Understand it: challenge (10 min). Take out names, amounts and anything confidential. Paste the page into your assistant with the challenge prompt. Keep what matches your conversations, drop the rest, and write down which points you dropped and why.
Structure it (10 min). Final rewrite. Make sure the test has a number and a pass mark, and that the out-of-scope list names what people asked for and won't get yet.
Agree (5 min, plus waiting). Send the page to your two colleagues with a date. Ask them to sign it, by adding their name and the date to the Agreed by line, or to tell you what's wrong.
Exit check
What you hand in: a one-page problem statement for a real request in your team, with:
Who, with roles and a number.
What's hard, with one figure from today.
A useful result, with no tool named.
How you'll know, with a pass mark someone else could check.
Out of scope and open questions.
Two names and a date.
It passes when two colleagues who are affected by the problem have read it and signed it, and neither has an open objection.
Rule to remember
Get the problem signed before anyone names a tool.
Eric Migicovsky - How to Talk to UsersY Combinator
T17-L02: Learn to ask about concrete past experiences and existing workarounds instead of pitching your solution. Adapt the startup interviews to colleagues; the recap's timestamps are not timestamps for this recording.
