What Do You Actually Need? Requirements From Real People
🎯 Today's mission briefing
We are learning to elicit requirements from a real user by interviewing and observing rather than guessing, and to write those requirements as user stories with acceptance criteria that can actually be tested.
You'll know you've got it when:
- I can run a structured interview using open, non-leading questions about the past rather than the future
- I can observe a user working and record the say-do gap as separate evidence
- I can write user stories in the form 'As a ... I want to ... so that ...' that describe a need, not a feature I already decided on
- I can write acceptance criteria that are testable, so two people could agree on whether the story is finished
Sixty-eight million dollars, and nobody used it
Connects to what your guest already knows and makes them curious. Activating prior knowledge is one of the strongest predictors of new learning.
Somewhere in Australia right now, a government department or a hospital or a large company is switching off a system that cost a fortune, took three years, and worked exactly as specified — because the people it was built for would not use it. Not could not. Would not. The requirements were signed off by managers who did not do the job, built by developers who never watched anyone do the job, and delivered to staff who took one look, worked out it added four steps to something they did ninety times a day, and quietly went back to the spreadsheet. Nobody wrote a single line of bad code. The whole thing failed before the first line was written, in the room where somebody asked the wrong question and wrote down the answer.