How I work
I do not apply the same framework to every problem
I find out what's happening, make the problem concrete, test the smallest useful change and work through the trade-offs with the people who'll build it, run it and use it.
Product requests often arrive disguised as solutions, like adding a button, building a dashboard, automating a step or integrating a provider. I start by asking what's failing.
Seven things I do
I state the trade-off in me first
I lean perfectionist about my own work, and I'll go back over something after it's already good enough. I know that about myself and I'm working on calling things finished sooner. I don't bring that to other people's work. I trust their expertise, and if something feels off I raise it and we work through it, instead of me pushing for my version. It's the same attention to unhappy paths I give a product, pointed at what it's like to work with me.
Start with the problem behind the request
I want to know who has the problem and how often, what work already happens around the existing system, what improves if we solve it and what happens if we don't. That goes beyond the external customer, because support, operational users, compliance, partners and engineering all live with the product too.
Build something to learn from
Abstract discussion can run for weeks while everyone imagines a slightly different solution. I'd rather make something the team can react to, like a flow, a prototype, realistic test data or a small calculator. It doesn't have to look finished and the code doesn't have to survive. Once people can click through it, missing states show up and the questions get better. AI has made this much faster. It also produces a plausible answer very quickly, including a plausible wrong one, so the framing, scope and decisions stay with me.
Bring engineering in early
I bring engineering and design in before a solution has hardened. My prototypes are there to start a conversation, because implementation knowledge should shape the decision as well as the estimate. I can discuss APIs, failure states, deployment and security risk, and I know where my knowledge ends. I picked it up from years of working next to developers, and I'm a good deal more technical now than I was ten years ago. Building a discovery prototype still doesn't make me the engineer accountable for production.
Look for the unhappy paths
The expensive problems rarely sit in the normal journey, so 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 should help the team make trade-offs between customer value, commercial impact, operational effort, risk and the complexity we leave behind. A list of stakeholder requests doesn't do that. Sometimes the answer is a new capability. Other times it's a better internal tool that means fewer manual checks, faster investigations and fewer support contacts, or removing something that no longer earns its cost.
Stay in it through delivery
Discovery doesn't end when a specification is written, and delivery doesn't end when a ticket closes. I stay involved and hold on to the outcome we wanted without getting attached to the first implementation. Afterwards I want to know what changed, whether people adopted it, whether it removed the friction we expected and whether it created new operational work.