Approach
I'm a business-minded product designer. Before product design, I worked in project management, and product ownership has always been part of my job, even without the title. So I'm as comfortable with vision, strategy, OKRs, and business requirements as I am with flows and prototypes. I help decide where a product should go, then design, and increasingly build, the path to get there.
Good design serves a goal the business cares about. Before a single screen exists, I want to know what will be different for users and for the organisation if we get this right, and how we will know.
I help write product visions and strategies that give teams a fixed point: what will be true for users and the business because this product exists, and what it deliberately won't do. Most recently, I co-authored the product vision for an enterprise AI platform.
I translate strategy into objectives and key results, so teams know what success looks like and can choose the work that moves it. Roadmaps follow from outcomes, not the other way around.
Product ownership work has always been part of my role. I know how to turn business and user needs into clear requirements, make trade-offs explicit, and prioritise what delivers the most value first. I speak the language of analysts and product managers, which makes design decisions easier to explain and defend.
A shipped feature isn't the result; a change in behaviour or business performance is. I keep asking what outcome we are creating, and for whom, so the team doesn't fall into the build trap.
Most of my work is complex business software for professionals. That means designing for the flow of real work, with all its exceptions, rather than for an idealised happy path.
Most product opportunities begin with friction: errors, slow work, unclear decisions, duplicated effort, or tools that make people work around the system. I use Jobs to be Done to look past feature requests to what people are actually trying to get done, and what gets in their way.
Before improving a workflow, I look at how people actually do the job now: their shortcuts, handovers, exceptions, documents, mental models, and hidden dependencies.
Designing complex software is less about isolated screens and more about the flow of work. Journey maps make that flow visible: every step, handover, and moment of doubt, across roles and tools. From there, clear direction connects the job to be done, the decisions users face, and the sequence that helps them make progress.
I prefer small, testable moves: prototypes, user feedback, usability testing, and continuous learning loops that reduce risk before teams commit too deeply.
A design only creates value once it is in people's hands. With a background in project management and product ownership as part of my daily work, I think beyond the design phase.
Planning, stakeholders, dependencies, and the handover to engineering are part of the job. I make scope and priorities visible, so teams can make trade-offs early instead of discovering them late.
I use AI to move from idea to working software fast: coded prototypes instead of static mockups, and real tools that teams can try, test, and build on. Stakeholders react to something that works, which makes conversations sharper and decisions faster. This portfolio is one of them: designed and built with AI.