2025 review

Roger on 31/12/2025

This year’s numbers

Completed 1,649 tasks.

Spent 37,245 minutes in meetings.

Wrote 43,102 words in 52 weeknotes.

Had 22,830 visitors to my website.

Highlights of the year

Started an MBA.

Was invited to do a talk to a product leaders group, even though I had to cancel it was really nice to be asked.

Facilitated retros with many of our leadership team.

Did more line-manging and coaching of other product managers.

Most interesting ideas I explored

Product strategy

Everyone wants to do product strategy but no one knows what it means (me included).

Strategy is fundamentally about how to use what’s within your control to affect what’s outside your control. If you’re trying to affect something within your control, you don’t need a strategy, you only need an implementation plan. Strategy is only necessary if you’re facing ambiguity and uncertainty. The more uncertainty you’re dealing with, the better your strategy needs to be. Wicked problems need lots of strategy.

I haven’t yet found a better framing for product strategy than the three parts of ‘a worthwhile problem to solve’, ‘hypotheses about how the solve it’ and ‘a way to know if the problem is solved’. It works well because it treats solutions as hypotheses and has a feedback loop to know if the problem is solved, and because it allows for different depths depending on the uncertainty being faced. If all you want to do is change some user behaviour so the product becomes stickier, then your product strategy can be pretty light touch. But if you want to tackle educational inequality, then your product strategy needs considerable depth to understand the problem (including causes and effects), lots of consideration about which are the right hypotheses

The problem with most strategies is that they are too inward looking, they are based on what an organisation wants to achieve rather than what’s going on in the market and with users. There’s lots of established thinking that product managers should use, such as supply and demand, queuing theory, distribution strategies, etc., etc., to underpin and inform their hypotheses about how to solve the problem, and help them loom outside their organisation.

Product tools

It bothers me slightly that there aren’t any good product management tools. There are plenty of delivery tools that manage workflows, but I’ve never seen one that instils good product practices such as user research analysis to identify problems, connecting problems to hypotheses for solutions, and measuring user behaviour to understand if the solution worked. If I wanted to be an entrepreneur, this is what I’d be working on.

Feedback loops

Feedback loops are an essential part of modern complex systems (which is what a product is) and so an essential part of working in those systems. They are one of those things that once you see them, or more often see the absence of them, you can’t unsee them.

One of the most important things I learned is that feedback has to be an order of magnitude faster than the system or situation being controlled in order to regulate it effectively. That means, if you’re shipping updates to a product fortnightly, you need to be collecting, analysing and responding to user behaviour feedback on those releases hourly. If the feedback loops are slower than what’s going on in the system, then the system can run off in an uncontrolled and unregulated direction that is difficult to come back from.

Feedback loops also helped me rethink how agility works in waterfall projects, where it’s less important that all the same kinds of activities are done in the same phase than it is that those activities have effective feedback loops to check they are getting things right.

Flow efficiency

Got a little obsessed with Flow Efficiency, the ratio of the total time spent in value-added work activities divided by the total time taken. It’s a really important concept and measure that touches prioritisation, capacity and value delivery. For example, if you wanted to understand the flow efficiency of how issues are dealt with you’d record the number of working hours from when the issue is detected to when it’s resolved, and divide it by the number of hours spent actively on it and you’d see how little of the total time is spent on the value-adding work. Of course, not all work is important enough to warrant improving it’s flow efficiency, but if we have no means of understanding the work that is important we’ll never be able to focus on it.

Digital transformation and the fourth industrial revolution

This is the big, ever-present, topic that affects and explains a lot of what’s going on in the world. No one knows how it’s going to play out but we can spot the trends by looking back at the previous industrial revolutions. Capitalism, globalisation, climate crisis, global economy, and political power shifts; all of these help us understand why the world feels so uncertain and like everything is changing all at once.

What a time to be alive.

At the organisational level, there are a couple of interesting trends, one about how organisations are understood and the other about the way work happens.

Converting organisational structures and business logic into a machine-readable format is one of the most important themes of digital transformation. Codifying what humans do, so that in the future machines can do it instead is the capitalist agenda. If you don’t believe me, ask yourself what Microsoft’s end game might be by having an org-chart in Teams, transcribing meetings, and giving all that data to Copilot. It creates a machine understanding of an organisation, of who speaks to who and about what. Which takes us to the second theme; how work gets done.

The ideas of liquid modernity that underpin digital transformation suggest that work is becoming increasingly continuous and that there is no end state to reach. The idea that the transformation will be done one day is an outdated notion. We aren’t shifting from one way of working to another, we’re shifting from a fairly static way of working to one that is never going to stop changing. How to respond to constant change is the practical question for every organisation.

I think part of the answer we’ll see is models from the on-demand economy being used to organise work within organisations. These models, which you might be familiar with for last mile delivery like Uber and Evri, rely on algorithms to distribute work (which you can only do effectively within an organisation if you understand who talks to who about what) and will learn to handle different types of work (at the moment we really only use them where every task can be completed in basically the same way, e.g. deliveries). Algorithms can change far more quickly than people so they really are the only viable option for a future on constant change.

Positioning product managers

I haven’t written about this much but it’s been on my mind a lot this year. From the extremes of “AI is going to replace product managers” to speaking to product people struggling to know what their role involves and should evolve to, how product managers position themselves and their profession is a constant question.

Product management is a very contextual role. That means its different in every organisation, for each product, and depending on the different skills of the person. This is a good thing. It’s a source of confusion also, but its better than trying to create cookie cutter product managers that only do certain things regardless of whether that’s what the product, team or organisation needs.

My suggestion is that product managers look at the intersection of what skills they uniquely bring, what the organisation needs, and what is industry good practice.

This helps us answer questions like, how technical should product managers be. If they work in an organisation with other technology experts then they don’t need to be at all technical, but if the team doesn’t have data analysts then the product manager probably needs to know how to run SQL queries. A very technical product manager working in a team of very technical people is likely to be too focused on the technology and miss what the organisation really needs from a product manager. A better positioning for a product manager in that situation would be to understand how technology affects users, the market and society in general. What affect does ubiquitous technologies like smart phones have on user behaviour? What supplier lock-in is the organisation at risk of? How are technology trends shaping competitor products? This is the kind of knowledge no one else is likely to have and it helps shape the future of the product. It gives product managers a unique positioning rather than being poor versions of other roles.

Stuff I wrote

Three ways for product managers to think about AI – AI in the market, AI as a tool, AI in products.

Product strategy workshop – A broad outline of a workshop for product teams to get started with developing a product strategy and using OKRs to get feedback on whether it’s working.

How I think about epics, features and user stories – They can be thought of as different types of things that are interconnected rather than as the same type of thing in hierarchical relationships with each other.

Towards a product topology for universities – Products are the things the university provides, not the things provided to the university by IT teams.

What I want from a product management tool – We don’t need another workflow management tool. We need a tool that assesses opportunities, aligns stakeholders, makes bets and analyses user behaviour to report on outcomes.

Analysing how a team spends its time – How do we know if we’re spending the right amount of time on the right things? In modern knowledge work, meetings often are the work, and so having a method for analysing how a team spends it’s time is important for optimising meetings.

Success state roadmaps – Attempting to express what we’ll see if we’re on the right track to success. The more specific each success state, the easier it is to know if the team is on track at each measurement point in time.

Escalators and mazes – We can use the metaphors of ‘escalators’ and ‘mazes’ to think about the two different types of products. Escalators take users from one place to another. Mazes keep users within the maze. Knowing the difference helps us design products with greater clarity and coherence, measure the right things and align the product with it’s business model.

Getting agile governance right – Three things are needed; showing work in progress, educating stakeholders, and building feedback mechanisms.

Books I read

Books I bought but haven’t read yet: