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

Why this page exists

Most of my work happens in product organisations, but I don’t really think of these ideas as being about Product Management.

I started my career in consulting, helping teams make sense of complex problems and make good decisions together. Twenty years later, although the job titles have changed, I still find myself doing exactly that.

Whether I’m working with a founder exploring a new idea, a scale-up trying to find product-market fit or an established organisation improving an existing product, I keep finding myself applying the same way of thinking.

The principles below aren’t really about product.

They’re about helping groups of people understand difficult problems well enough to move forward with confidence.

The model I keep coming back to

Almost every project I’ve worked on has followed the same pattern.

• Build shared understanding
• Make thoughtful decisions
• Ship to replace belief with evidence
• Repeat.

Everything else on this page is really an attempt to explain those four ideas.

Why shared understanding matters

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

More often they’re working from different mental models of the same problem.

Leaders carry years of context that others haven’t experienced. Designers, engineers and product managers naturally notice different things. Customers usually see something else again.

I’ve found that helping a team build a shared understanding of the problem is one of the most valuable contributions I can make.

Once a team has that shared understanding, conversations about solutions become much easier.

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 the problem before each discipline brings its own 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 hasn’t been my experience.

A startup doesn’t need the same practices as a scale-up. A platform team faces different constraints to a consumer product. Every organisation has its own culture, incentives, customers and history.

Best practice is useful.

Understanding your context is essential.

What discovery is really for

Discovery is one of the best ways I’ve found to build shared understanding and uncover the assumptions we’re making.

The most valuable customer conversations I’ve been part of weren’t valuable because Product heard them. They were valuable because Product, Design and Engineering all heard the same thing together.

Every conversation is an opportunity to replace belief with evidence.

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

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 choosing what to do.

It’s also about deciding what not to do, or simply saying;

“Not yet.”

Why I like shipping

I like shipping because every release is an opportunity to replace belief with evidence.

Sometimes we’re right. Sometimes we’re wrong. Either way, we’ve learnt something we didn’t know before.

I’ve also found that shipping smaller changes more often usually reduces risk rather than increasing it. Smaller releases 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.

Why building is becoming cheaper

AI is making software dramatically cheaper and faster to build.

I think that’s a good thing.

It means more ideas can be explored, tested and refined than ever before.

But it also shifts where value is created.

When almost anyone can build software, understanding which problems deserve solving becomes increasingly important.

That’s why I think the future of product is less about writing requirements and more about helping teams ask better questions, build shared understanding and learn quickly.

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 understand problems together before solving them.

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 give the problem at least as much attention as we give potential solutions.

Last updated August 2026. This page is a living document. I’ll update it as my thinking evolves rather than treating it as a historical archive.