Product Thinking

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.

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.