How I work
I do not apply the same product framework to every problem. My basic approach is simpler:
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, operate, and use it.
Start with the problem behind the request
Product requests often arrive disguised as solutions: add a button, create a dashboard, automate a step, or integrate a new provider.
I start by asking what is actually failing. Who experiences the problem? How often does it happen? What work is happening around the existing system? What would improve if we solved it, and what happens if we do nothing?
That means considering more than the external customer. Support teams, operational users, compliance, commercial stakeholders, partners, and engineering are all part of the product reality.
Build to learn
Abstract discussions can continue for weeks while everyone imagines a slightly different solution.
I prefer to create something the team can react to: a flow, a functional prototype, realistic test data, a simple calculator, or a small working tool. It does not have to look finished, and the code does not have to survive.
Its purpose is to expose assumptions.
Once people can click through something, the conversation becomes more useful. Missing states become visible. Edge cases appear. People ask better questions. The team can decide what should be built properly, changed, or abandoned.
Use AI to shorten the feedback loop
AI has expanded how far I can take an idea myself during discovery.
I use it to explore alternatives, create prototypes, test workflows, map edge cases, build small internal tools, and prepare clearer material for engineering. I can move from a vague idea to something functional quickly enough to learn from it rather than merely describe it.
That does not remove the need for product judgement, design expertise, or engineering discipline. AI can generate a plausible answer very quickly, including a plausible wrong answer. I remain responsible for the problem framing, scope, logic, and decisions.
Production architecture, security, reliability, and maintainability still require proper engineering ownership.
Work with engineering, not around it
I prefer bringing engineering and design into the work before a solution has hardened.
My prototypes and specifications are starting points for discussion, not instructions handed over from a distance. Technical constraints, existing architecture, and implementation knowledge should influence the product decision, not merely the delivery estimate.
I am technically literate enough to discuss APIs, data flows, integrations, failure states, deployment, and security risks. I am also clear about where my responsibility ends. Being able to build a discovery prototype does not make me the engineer responsible for the production system.
Look for the unhappy paths
The normal journey is rarely where the most expensive problems hide.
I pay attention to what happens when:
- information is missing or incorrect
- an integration fails
- a customer changes their mind
- a user lacks permission
- two systems disagree
- support needs to intervene
- a process has to be reversed or repeated
- the apparent automation still leaves manual work behind it
Functional prototypes help because I can click through the journey rather than relying entirely on boxes and arrows. That often exposes logic gaps before they become blocked development work or production incidents.
Prioritise the whole outcome
A roadmap should not be a collection of stakeholder requests. It should help the team make trade-offs.
I weigh customer value, commercial impact, operational effort, risk, dependencies, engineering cost, and the complexity we leave behind. Sometimes the right answer is a new capability. Sometimes it is a smaller change, a better internal tool, or removing something that no longer earns its cost.
I am interested in both visible growth and quieter improvements: fewer manual checks, faster investigations, clearer decisions, fewer support contacts, and systems that are easier to operate.
Stay involved through delivery
Discovery is not complete when a specification has been written, and delivery is not complete when a ticket has been closed.
I stay involved while the solution develops, clarify decisions when new information appears, and help the team preserve the original outcome without becoming attached to the original implementation.
After release, I want to know what actually changed. Did people adopt it? Did it remove the expected friction? Did it create new operational work? What did we learn, and what should happen next?
That is the point of product work: not producing artefacts or shipping output, but changing something useful in the real system.