The principles, questions and observations that shape how I approach product.

Why this page exists

Most of my work happens in product organisations, so that’s what this page is largely about. But these ideas aren’t really about product.

They’re about helping groups of people make good decisions in uncertain situations.

I don’t believe there’s one “right” way to build products. Every organisation has different customers, different constraints, different goals and different people. Context matters.

So rather than sharing a framework or a set of best practices, this page is an attempt to explain how I tend to think. If it resonates, we’ll probably enjoy working together.

Why shared understanding matters

When teams get stuck, I rarely think it’s because they’re not smart enough.

More often they’re making decisions from different mental models.

Leaders often carry years of context in their heads without realising it. Teams can’t make good decisions using context they don’t have.

My job isn’t to arrive with all the answers.

It’s to help teams build enough shared understanding that they can make good decisions together. Confidence doesn’t come from certainty.

It comes from understanding.

Why I believe product is a team sport

I’ve never believed great products come from brilliant individuals.

The best products I’ve worked on have come from Product, Design and Engineering building a shared understanding of their customer’s problem, then bringing their different expertise to solving it.

Each discipline should own its craft. Product shouldn’t make design decisions. Design shouldn’t make engineering decisions. Engineering shouldn’t make product decisions.

But every discipline should influence the solution.

One of my favourite signs of a healthy team is when nobody can remember whose idea something was.

Why context beats best practice

One thing that frustrates me about product management is how often people assume the way product works in their organisation is the way it should work everywhere.

That’s not my experience.

A startup doesn’t need the same product practices as a scale-up. A platform team doesn’t have the same problems as a consumer-facing team. Different organisations have different cultures, different incentives and different constraints.

Best practice is useful.

Understanding your context is essential.

What discovery is really for

I think discovery is often misunderstood.

For me, discovery isn’t about validating ideas.

It’s about reducing uncertainty.

The goal is to move as much as possible from “we believe” to “we know”.

That means understanding customers deeply enough to separate what they say from what they actually do, and learning enough about the problem that the team can move forward with confidence.

Most delivery problems I’ve seen started long before delivery began.

How I think about strategy

Strategy isn’t about finding the perfect answer.

It’s about making thoughtful trade-offs.

I like Amazon’s idea of two-way and one-way doors.

If a decision is easy to reverse, make it quickly.

If it’s difficult to reverse, spend more time understanding it.

I’ve also found that it’s much easier to compare two options than to point at a single solution and ask, “Is this the right one?”

Good strategy isn’t just about deciding what to do.

It’s also about deciding what not to do, or simply saying, “Not yet.”

Why shipping isn’t the goal

I like shipping.

I just don’t think shipping is the goal.

Shipping creates opportunities to learn.

Learning is what creates progress.

Small changes reduce risk. They make it easier to understand what’s happened, easier to recover when something doesn’t go to plan and easier to build confidence over time.

Fast doesn’t have to mean careless.

In my experience, shipping less, more often usually improves quality rather than reducing it.

How I think about AI

AI is changing software development incredibly quickly.

I’m excited by that.

But while it might be easier to build software than it has ever been. That doesn’t mean it’s automatically easier to build the right software.

As building becomes cheaper and faster, deciding what’s worth building becomes more valuable.

The organisations that succeed won’t just be the ones that build the fastest.

They’ll be the ones that understand their customers and make better decisions.

The questions I keep coming back to

When I’m working with a team, you’ll probably hear these questions more than any others.

• What do we know?
• What do we believe?
• What assumptions are we making?
• What would have to be true?
• What do we need to learn next?
• Is this decision reversible?
• Who sees this problem differently?
• How will we know we’ve improved things?

I’ve found that asking better questions is often more valuable than having quicker answers.

What you can expect

If we work together, you can expect curiosity before certainty.

You can expect thoughtful questions.

You can expect Product, Design and Engineering to solve problems together.

You can expect decisions to be explained, trade-offs to be discussed and evidence to matter more than opinion.

Above all, you can expect us to keep learning.

First published July 2026. This page is a living document. I’ll update it as my thinking evolves rather than treating it as a historical archive.