Requirements Gathering
A request is rarely a complete brief. It may describe a symptom, assume a solution or leave out the difficult cases. I work back to the need, then turn it into a scope the team can understand, challenge and test. Good requirements make the intent clear while leaving space for thoughtful implementation.
01 / The practice
How I work.
Find the problem inside the request
I ask who is trying to do what, where the current experience breaks down and why fixing it matters. The answer gives the work a purpose and helps separate a genuine requirement from an early suggestion about the interface.
Walk through the whole journey
I map the important steps with the people who use and build the product. We look at the ordinary path as well as permissions, existing data, interruptions and dependencies. Those conversations help make the boundary of the first release explicit.
Agree what good looks like
I work with UX and engineering to shape user stories and acceptance criteria. The criteria describe observable behaviour, including what must remain true for existing users. The team should be able to explain how it will recognise that the need has been met.
02 / Something useful
What comes out of it.
- A problem statement and journey map
- A deliberately bounded release scope
- User stories and testable acceptance criteria
03 / In practice
The work behind the words.
Course Editions
New course editions needed to remain related while being independently editable. Protecting live content and making the next edition understandable were essential parts of the problem.
Content platform product ownership
At Imagine Learning, I partnered with UX and engineering to define clear acceptance criteria for changes to content structures and governance.