Asking for Assumptions and Unknowns
Unit ID: PAW-M05-U02 Estimated active time: 20-25 minutes
The most valuable section in an output
Add this to almost any structured request:
> End with two short sections: "Assumptions I made" and "What I would need to know to be more useful".
These two sections routinely turn out to be the most useful part of the answer, and they are almost never produced unless asked for.
Why assumptions stay hidden otherwise
To produce a fluent answer, a tool must fill gaps. Given an incomplete request it will make reasonable choices — about audience, timescale, scale, budget — and then write as if those choices were given.
The assumptions are load-bearing and invisible. Asking for them makes them checkable.
What good looks like
A useful assumptions section is specific:
> - I assumed "small team" means under 10 people. > - I assumed this is for internal use, not customers. > - I assumed the deadline is this quarter. > - I assumed no budget approval is needed under £500.
A useless one is generic: "I assumed you want a helpful answer." If you get that, ask again naming the decisions you want surfaced.
The unknowns request
CLOSING SECTIONS TO REQUEST
## Assumptions I made
- each one specific enough to be wrong
## What I do not know
- facts that would change the answer if supplied
## What I would check first
- ranked, with why each matters
## What this does not cover
- scope the answer deliberately leaves outFour short sections. On a long output they take a few lines and save a re-run.
Feed the unknowns back
The "What I do not know" list is the input to your next prompt.
Answer two or three of its items and re-run. This is usually a bigger improvement than any rewording of the original request, and it is Module 7's whole subject.
Mini practice
Re-run a recent request with the four closing sections added.
Read the assumptions first. Mark any that are wrong.
Note whether the main answer would change if you corrected them.