How I Work

How I prepare decisions

Most of the time lost in product organisations does not go to wrong decisions. It goes to decisions everyone believes have been made. The argument surfaces months later — as a roadmap conflict, as contradictory external messaging, as sales frustration about a product that supposedly promised something else.

So before any discussion of substance I ask two preliminary questions: what exactly is to be decided here, and which existing work is being taken into account? Both sound bureaucratic. Both reliably separate a meeting that decides something from one that discusses something.

The second test comes at the end: which decision looks different after this than it did before? If the answer is none, it was a text document.

What that looks like in practice is in the case study on strategic alignment.

How I prioritise

At a roadmap, time horizons meet that have nothing to do with each other. A customer opportunity counts in weeks, strategic product development in quarters, technical stability in years. All three compete for the same people, and all three are right.

I do not resolve this with a scoring system carried to two decimal places. Such models produce a number everyone can hide behind. Instead I make the criteria visible — demand, resources, scope, timing, dependencies, rollout impact — and consider them together rather than in sequence.

The uncomfortable part is not the method but its consequence: visible criteria take away everyone's ability to treat undecided things as decided. That initially produces more friction, not less. Which is exactly what governance is for — structuring conflicts early instead of letting them escalate late in delivery.

At length in the case study on product governance.

How I approach transformation

The most common reflex in technology companies is to solve an operating problem with a tool. After all, you own the tool. That is precisely why the product side has to slow things down here rather than speed them up.

A screen is a technical asset. Sellable inventory is a defined operational product. The real work sits between the two: data model, accountability, rules for the exception. What is missing there cannot be retrofitted with software — it only becomes visible later, and more expensively.

So I pull the uncomfortable questions in front of the start. After launch they are not technically harder, they are political: by then expectations exist in the market.

In the case study on retail media readiness.

How I think about effect in the market

The market does not automatically follow the best product. It follows the clearest and most credible interpretation on offer. That is uncomfortable for anyone assuming good work speaks for itself.

For product work that means two things. Inwards: a portfolio needs a shared logic, otherwise you leave the customer to construct the connection themselves — and with it the decision whether one exists at all. Outwards: a position emerges from structuring the relevant questions better, not from saying your own answers more loudly.

Both in the case studies on the platform ecosystem and on thought leadership.

What I want to be measured on

Whether a decision is still traceable six months later. Not whether it was right — that is never knowable in advance — but whether the reasons were written down and whether someone can check them.

Where a rejected option has no recorded reasoning, it returns a year later as a new idea, and the organisation has the same discussion a second time.