Professional Background

I am a Product Manager focused on turning operational complexity into clear, practical, and usable software. My experience sits across product management, transport operations, software delivery, systems thinking, and technical design. I work best where customer needs, commercial priorities, operational realities, and technical constraints all intersect.

I have worked on software used by transport and logistics businesses to manage complex operational workflows, including order management, quoting, costing, planning, resource allocation, tracking, reporting, and invoicing. That experience has given me a broad view of how digital products connect commercial, operational, technical, and financial requirements inside real businesses. I am particularly interested in products that reduce manual effort, improve visibility, support better planning decisions, and reflect how people and organisations actually work.

One of the reasons I find product management interesting is that products are not just technical systems. They are shared models of reality. Yuval Noah Harari argues that large groups of people cooperate through shared stories: money, companies, markets, institutions, and processes all work because people collectively accept them as meaningful. That does not make them unimportant. Quite the opposite. These shared stories are what allow complex organisations to function. Software products work in a similar way.

A product is not just a database, a set of screens, a workflow, or a backlog of features. It is a shared model of how an organisation believes work should happen. It defines what matters, what gets seen, what gets measured, what gets prioritised, and how different people coordinate. That is why product management is not simply about gathering requirements or shipping functionality. It is about shaping a coherent model that customers, users, engineers, commercial teams, and operational stakeholders can all understand, trust, and act upon.

For me, product management is the discipline of improving that shared model over time. It means making decisions in conditions where the evidence is incomplete, the priorities are competing, and the impact is uncertain. Complexity theory is useful here because organisations are not simple linear systems. A change to a process, metric, workflow, pricing model, integration, or user experience can create effects elsewhere in the business. The role is not to pretend certainty exists. It is to create enough clarity for better decisions to be made. That requires understanding the real problem before defining the solution, then using discovery, evidence, prioritisation, delivery, measurement, and iteration to keep the product aligned with customer value, commercial impact, operational reality, and technical feasibility. My approach is based on:

  • Understanding the workflow behind the request
  • Turning unclear requirements into testable specifications
  • Working closely with engineering, QA, implementation, support, and commercial teams
  • Prioritising outcomes over output
  • Using evidence, feedback loops, and practical constraints to shape direction
In software, small decisions can have large downstream effects. A change to how work is planned, rated, allocated, or invoiced can affect planners, drivers, customers, finance teams, and reporting. Good product work means understanding those connections before committing to the design.

Core Competencies

  • Product Strategy & Design
  • Research Methodology & Analysis
  • Agile Development & Leadership
  • Data Analysis & Visualisation
  • AI/ML Applications & Strategy
  • Business Process Optimisation

Philosophy

Businesses are networks of constraints, dependencies, delays, exceptions, feedback loops, and trade-offs. Depot capacity, driver hours, fleet availability, planning rules, customer requirements, integrations, commercial logic, and reporting obligations all interact.

That is why I am interested in research and practice that helps explain complex systems and improve decision-making. I draw on ideas from across disciplines, the common thread is using better models, clearer thinking, and stronger feedback loops to make better product decisions. For me, theory only matters when it improves practice. A good product decision should not just add functionality, it should improve the wider system: reducing friction, increasing visibility, improving flow, removing avoidable manual work, or helping users make better decisions.

Software and Technical Interests

Although my role is product-focused, I also build software myself. I use personal development projects to deepen my technical understanding, test ideas, and explore how design decisions affect usability, maintainability, and delivery.

This Site

This site brings together my projects, product thinking, and personal development work.

It is intended to show:

  • How I approach product problems
  • How I think about systems, constraints, and trade-offs
  • How I connect technical detail with business value
  • How I use personal projects to learn and test ideas
  • How I communicate complex topics clearly

The common theme is practical product management: understand the problem, design with constraints, and build software that improves the system it sits within.