How I work
I do not apply the same framework to every problem
Understand what is happening in reality, make the problem concrete, test the smallest useful change, and work through the trade-offs with the people who will build it, operate it and use it.
Product requests often arrive disguised as solutions. Add a button, build a dashboard, automate a step, integrate a provider. I start by asking what is actually failing.
Seven things I actually do
I state the trade-off in me first
I lean perfectionist about my own work, and I will go back over something after it is already good enough. I know this about myself and I am working on calling things finished sooner. With other people's work it stays out of the way. I trust their expertise, and if something feels off I raise it and work through it rather than push for my version. The same attention to unhappy paths, pointed at what it is like to work with me.
Start with the problem behind the request
Who experiences this problem. How often. What work is already happening around the existing system. What improves if we solve it, and what happens if we do nothing. That means more than the external customer. Support, operational users, compliance, partners and engineering are all part of the product reality.
Build something to learn from
Abstract discussion runs for weeks while everyone quietly imagines a slightly different solution. I would rather make something the team can react to. A flow, a prototype, realistic test data, a small calculator. It does not have to look finished and the code does not have to survive. Once people can click through it, missing states become visible and the questions get better. AI made this faster, not easier. It produces a plausible answer very quickly, including a plausible wrong one, so framing, scope and decisions stay mine.
Work with engineering, not around it
I bring engineering and design in before a solution has hardened. My prototypes are starting points for a conversation, not instructions handed over from a distance, because implementation knowledge should shape the decision and not just the estimate. I am literate enough to discuss APIs, failure states, deployment and security risk, and clear about where that ends. That literacy came from years of working next to developers rather than from a course, and I am a good deal more technical now than I was ten years ago. Building a discovery prototype still does not make me the engineer accountable for production.
Look for the unhappy paths
The normal journey is rarely where the expensive problems hide. I pay attention to what happens when
- information is missing or wrong
- an integration fails
- a customer changes their mind
- a user lacks permission
- two systems disagree
- support has to intervene
- a process has to be reversed or repeated
- the apparent automation still leaves manual work behind it
Clicking through a real prototype exposes those gaps before they become production incidents.
Prioritise the whole outcome
A roadmap is not a collection of stakeholder requests. It should help the team make trade-offs, weighing customer value, commercial impact, operational effort, risk and the complexity we leave behind. Sometimes the answer is a new capability. Sometimes it is a better internal tool, or removing something that no longer earns its cost. Fewer manual checks, faster investigations, fewer support contacts.
Stay in it through delivery
Discovery is not finished when a specification is written, and delivery is not finished when a ticket closes. I stay in it, keeping the original outcome without getting attached to the original implementation. Then I want to know what actually changed. Did people adopt it. Did it remove the friction we expected. Did it create new operational work. That is the job, not producing artefacts.