Here's how I approach product problems in practice
Product thinking is how I connect strategy, customer problems, operational reality, and technical delivery. It is not just about writing requirements or managing a backlog. It is about understanding the system a product operates within, identifying the constraints that matter, and making disciplined decisions that improve outcomes for users, customers, and the business.
My approach is shaped by product management, software delivery, systems thinking, and operational problem solving. I am particularly interested in products that sit inside complex workflows, where small design choices can have a large impact on planning effort, visibility, cost, and decision quality.
Where I can help
Competing priorities across transport products
Customer requests, operational needs and engineering capacity pull the roadmap in different directions. I help make the trade-offs explicit across TMS and optimisation, connecting priorities to customer value and delivery constraints.
Explore my roadmap and governance work →Disconnected operational systems
Transport, warehouse and freight-tracking systems each hold part of the picture. I help define the information and workflows that need to connect, so integration requirements reflect how the operation works.
Explore my systems integration work →Planning decisions made under uncertainty
A delivery date or capacity plan can hide assumptions about queues, dependencies and available resources. I use models to make those assumptions visible and compare scenarios before committing to a plan.
Explore Work Simulator, my personal forecasting project →The Clarity Cycle in practice
Understand the system, model the complexity, then design for decision-making. Each stage should produce something useful for the next decision.
1. Understand the system
What I do: Map workflows, dependencies, constraints and exceptions with the people doing the work.
What I produce: A shared system map and a problem statement that identify where information, ownership or capacity breaks down.
How it changes a decision: Helps the team decide whether the problem calls for a product change, an integration or a change to the process, and spot consequences elsewhere in the operation.
2. Model the complexity
What I do: Test assumptions and compare options through scenarios, prototypes or simulations.
What I produce: A model that exposes its assumptions, constraints and the trade-offs between alternatives.
How it changes a decision: Shows which assumptions matter most and where more evidence is needed before choosing scope, allocating capacity or making a delivery commitment.
3. Design for decision-making
What I do: Translate the findings into workflows and requirements that support the decisions users need to make.
What I produce: A prototype or specification with acceptance criteria, exception handling and the information users need at the point of action.
How it changes a decision: Gives the team a concrete basis for deciding what to build and how to validate it, while helping users understand the choices the software presents.
How I Think About Product
Good product work starts with a simple question: what real-world decision, workflow, or constraint are we trying to improve? From there, the role of product management is to reduce ambiguity, create shared understanding, and turn messy operational problems into deliverable software.
I tend to look at products through three connected lenses:
- The user lens: What is the user trying to achieve, what slows them down, and where does the current experience create friction?
- The system lens: How do data, people, processes, integrations, constraints, and feedback loops interact?
- The commercial lens: What problem is valuable enough to solve, and how does the solution support customer retention, growth, efficiency, or differentiation?
Core Principles
1. Start With the Constraint
Many product problems are not caused by a lack of features. They are caused by a constraint in the wider system: poor data, unclear ownership, planning bottlenecks, manual rekeying, weak integrations, or decisions being made too late. Finding the constraint helps avoid building attractive but low-impact functionality.
2. Understand the Workflow Before Designing the Screen
A good interface reflects the workflow behind it. Before thinking about screens, I want to understand the job being done, the sequence of decisions, the exceptions, the handovers, and the information needed at each point. This is especially important in operational software where the cost of friction compounds over time.
3. Make Trade-Offs Explicit
Product management is rarely about finding a perfect answer. It is about making informed trade-offs between speed, scope, usability, technical complexity, commercial value, and long-term maintainability. I prefer decisions to be explicit, documented, and linked back to the outcome they are intended to support.
4. Use Data, But Do Not Hide Behind It
Data is essential, but it does not replace judgement. Metrics can show where something is happening, but discovery is often needed to understand why. Strong product thinking combines quantitative signals, qualitative insight, operational knowledge, and commercial context.
5. Write Requirements That Create Shared Understanding
Requirements should not simply describe a feature. They should explain the problem, the user need, the expected behaviour, the edge cases, and the value of solving it. Well-written specifications reduce rework, improve engineering conversations, and make testing easier.
Influences
My product thinking is influenced by several disciplines and thinkers. I use these ideas pragmatically, not as theory for its own sake.
- Systems Thinking: Understanding feedback loops, dependencies, incentives, delays, and unintended consequences.
- Theory of Constraints: Identifying the bottleneck that limits the performance of the wider system.
- Probabilistic Thinking: Recognising uncertainty and using ranges, scenarios, and confidence levels rather than pretending every estimate is certain.
- Lean and Iterative Delivery: Reducing waste, learning quickly, and validating whether a solution is moving the right metric.
- Operational Product Management: Designing software that supports real work, not just clean process diagrams.
What This Means in Practice
In practical terms, this means I focus heavily on discovery, structured requirements, stakeholder alignment, and delivery clarity. I like product artefacts that help people make better decisions, not documents that exist purely because a process says they should.
Useful product artefacts include:
- Problem statements that clearly define the operational or commercial issue.
- Outcome-based roadmaps linked to measurable value.
- User stories supported by clear acceptance criteria and edge cases.
- Workflow diagrams that expose handovers, constraints, and failure points.
- Decision records that explain why a particular trade-off was made.
- Prototypes, spreadsheets, simulations, or lightweight tools that help test an idea quickly.
My Product Philosophy
I believe strong product management sits between strategy and detail. It needs enough commercial awareness to choose the right problem, enough technical understanding to work effectively with engineering, and enough operational empathy to design software that genuinely improves the way people work.
The best product decisions are rarely the loudest or most fashionable. They are the ones that remove friction, improve decision quality, reduce avoidable effort, and create a clearer path from user need to business value.