Month: December 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

• Think big, act small
• Managing and organisations
• Pitch
• Product in service
• How to measure anything
• Real world agility
• The Service Organization
• The product-led organisation
• Solving for value
• Building AI powered products
• Impact-first product teams
• Team topologies
• Persuasive technology
• The social brain
• Generative AI and education

Books I bought but haven’t read yet:

• The empowered manager
• Making the matrix work
• Kill bad meetings
• Speed lead
• Diffusion of innovation

Most viewed posts

1. Case study on Amazon’s approach to innovation and competition in the knowledge economy – 3,430
2. Systems thinking for product managers – 2,485
3. What’s the difference between a roadmap and a delivery plan? – 1,310
4. Microsoft Planner vs. Trello – 1,032
5. Schmenner’s Service Process Matrix – but for charities – 731
6. Four principles for great teamwork: communicate, collaborate, contribute, coordinate – 544
7. What’s the difference between a delivery manager, a project manager and a scrum master – 411
8. What’s the difference between product manager, project manager and delivery manager? – 287
9. From good ideas to social good: How charities approach innovation processes – 286
10. What’s the difference between a Prototype and Pilot? – 258

Doug Belshaw answered Steph Ango’s 40 questions. Here’s mine for 2025.

1. What did you do this year that you’d never done before? Start with a hard one, why don’t cha. I think there were probably lots of little things but nothing big stands out.
2. Did you keep your new year’s resolutions? Kind of. My new year’s resolutions are pretty much always centred around my three areas of focus: contributing to for-good digital transformation, getting an effective education, and living an intentional life. So, all the things I did this year such as starting an MBA (effective education) and maintaining my runway (intentional life) are keeping my new year’s resolutions.
3. Did anyone close to you give birth? No.
4. Did anyone close to you die? No.
5. What cities/states/countries did you visit? Hardly went anywhere, just London.
6. What would you like to have next year that you lacked this year? More exercise. It’s always the first thing I drop when things get busy.
7. What date(s) from this year will remain etched upon your memory, and why? Can’t remember any dates in particular and I’m good with that because memorable dates are usually dramatic or traumatic and there’s been enough of that in the past few years.
8. What was your biggest achievement of the year? Pretty much everything I achieved either involved others or was a step towards something else, so nothing feels like something I have achieved, but I’ll go with developing a clearer positioning of my role at work. I hope I continue to bring calm kind challenge to all the different things I get involved in.
9. What was your biggest failure? Not supporting people as much and as well as I should have.
10. What other hardships did you face? My hardest hardship this year was number 39. I’m fine with the stress of suicide attempts, police, ambulances, sleepless nights, unhelpful NHS teams, etc. The hard part is accepting that the help I can provide isn’t always the help that’s wanted or needed.
11. Did you suffer illness or injury? No, I’m pretty healthy as far as I know.
12. What was the best thing you bought? A little keyring torch. It helped me connect with a little boy when he needed it.
13. Whose behaviour merited celebration? One of the leaders I worked with this year showed inspirational levels of humility and self-reflection. That kind of thing isn’t celebrated nearly enough but seeing it stuck with me as something to aim for.
14. Whose behaviour made you appalled? I should probably say it was people like Trump and Musk but I have such low expectations of them that it’s hard to be appalled by their appalling behaviour, so I’ll say it was some of the NHS mental health team members who literally have the power to affect people’s lives and use that power without much consideration of how their decisions affect people.
15. Where did most of your money go? House. I track my expenditure and group it into categories for easy analysis so I know exactly how much I’ve spent on books, clothes, and on the house.
16. What did you get really, really, really excited about? I don’t think I got really, really, really excited about anything, but I was definitely excited by some of the things I’m doing at work and starting to study an MBA.
17. What song will always remind you of this year? I went to a Dermot Kennedy gig so it’ll probably be this one.
18. Compared to this time last year, are you: happier or sadder? Richer or poorer? Healthier or unhealthier? About the same. I judge how rich I am by my runway (how many months I could go without an income), which is about the same now as it was at the start of the year. I don’t have a means of judging happiness but feel as even-keeled at the end of the year as I did at the beginning. Health is pretty much the same although with better leading indicators (eating, sleeping, exercising).
19. What do you wish you’d done more of? Blogging. I used to blog a lot more and wish I had the time to do more of it. It’s where I explore ideas more deeply than I can in weeknotes and it helps me have a more well-thought-through position on things I talk to others about.
20. What do you wish you’d done less of? Wasting time on things that turned out not to have the effect I thought they would, but without perfect foresight, sometimes you just have to try things.
21. How are you spending the holidays? Just like every other day.
22. Did you fall in love this year? No.
23. Do you hate anyone now that you didn’t hate this time last year? No, same.
24. What was your favourite show? I don’t watch much TV so I’ll go with Survivorman, which is always my go-to escapist fantasy.
25. What was the best book you read? Probably Impact-first product teams. Mostly because of the confirmation bias.
26. What was your greatest musical discovery of the year? Didn’t have any.
27. What was your favourite film? Can’t remember watching any films so don’t have a favourite but was interested to see some of the stuff about the 50th anniversary of Jaws (which is one of my favourite films).
28. What was your favourite meal? Coffee cake and custard in a hospital visiting room.
29. What did you want and get? A hoodie. (I assume this is referring to Christmas presents.)
30. What did you want and not get? There wasn’t anything else I wanted.
31. What did you do on your birthday? Nothing much.
32. What one thing would have made your year immeasurably more satisfying? Spending time in wild places.
33. How would you describe your personal fashion this year? “Gone ‘till November”, which could have been written about my trousers because I pretty much wear shorts most of the year.
34. What kept you sane? Work. It gives me focus, intellectual challenge, and a sense of contributing to a larger purpose.
35. Which celebrity/public figure did you admire the most? None of them.
36. What political issue stirred you the most? Flags on lampposts. It’s a horribly scary, too-close-to-home show of right-wing power. Also, the stupidity of using St. George’s cross as a symbol to exclude people who “aren’t English enough” when St. George was from what is modern day Turkey.
37. Who did you miss? I didn’t really miss anyone, my brain doesn’t work that way.
38. Who was the best new person you met? Probably a delivery manager who’s really good at his job. Delivery management is one of those roles that can be done effectively in so many ways so it’s always good to meet someone who knows their way.
39. What valuable life lesson did you learn this year? You can take a horse to water but you can’t make it drink. Or, you can offer help but you have to accept that people don’t have to accept it.
40. What is a quote that sums up your year? “I expect next year to be a record-breaking year.” -Jensen Huang.

In product development, governance is essential for ensuring quality and problem/market fit of the solution. Governance should provide broad oversight of the wider organisational implications of the solution so that the team building the product can maintain their flow and focus.

In a traditional waterfall or stage-gated development process quality assurance and approval checks happen towards the end of the work. It makes sense if you’re optimising for efficiency as all the quality check governance happens when the development is as close to it’s live and finished state as possible. But it’s based on the assumption that it’s possible to know ahead of the development work all the possible considerations and implications, which approval checks can refer to and confirm met or not.

The agile perspective is that its not possible to know all those implications ahead of doing the development work and so the better approach is to get smaller feedback more regularly and respond to it more quickly. This is better than waiting until near the end because changes are easier to make whilst development work is in progress. This approach optimises for effectiveness where getting it right is more important than doing it quickly.

Getting agile governance right takes three things; showing work in progress, educating stakeholders, and building feedback mechanisms.

Showing work in progress

Working in the open is not a nice-to-have, its an essential part of agile governance.

Show and tells, weeknotes, public roadmaps, and regular discussions with stakeholders, are all part of working in the open. They are about showing progress, but they aren’t status updates, they are quality control. By showing work in progress regularly and prompting stakeholders to ask the right questions, product teams can make explicit any assumptions they have and clarify things they are unclear about.

For some teams, this is where agile governance stops (and fails). They show the work but stakeholders don’t know what to do with what they’ve seen. Teams can easily spot this by the amount and quality of discussion they have with stakeholders.

Educating stakeholders

Understanding the implications of what the product team is doing requires dedicated and widespread organisational knowledge.

A stakeholder is anyone for whom a change matters because it affects their ability to achieve their goals. They need to be able to think critically about what they’ve seen from the product team, to consider the implications on their area of the organisation, and to ask the right questions to clarify the impact. This doesn’t happen by accident. Stakeholders need to learn how to be an effective part of agile governance, and often it falls to product teams to do that.

Educating stakeholders means helping them be clear about which of their goals might be impacted by the product. If the product helps user’s self-serve, what are the implications for call centre capacity and workforce planning? A development team won’t have the knowledge to answers those questions but a stakeholder who manages the call centre might. But only if they come to a show and tell or read weeknotes with that question in mind.

Generally, stakeholders need to be explicitly told that their role is to understand enough about the overlap a product has with their area that they can spot implications that no one else sees. Once they’ve noticed implications they need a way to tell the product team and have confidence the they’ll be discussed and resolved.

Building a feedback mechanism

Product teams need to put processes and tools in place to collect, manage and communicate a response to stakeholder feedback.

All too often, stakeholder feedback is managed in an ad hoc way because it’s seen as a challenge to the product rather than an opportunity to achieve a wider and more coherent solution. But when teams and stakeholders understand that feedback is an important part of agile governance, and being able to do it effectively is the difference between a product launching without unexpected issues and it landing with positive impact.

Big public show and tells often aren’t the right forums for discussing the details of feedback, so instead teams should make it known among stakeholders who to speak to, how to get in touch, what kind of information to provide, how the discussion will happen and how long it’ll take. Those kinds of expectations should be the basics of stakeholder engagement.

Sometimes that discussion leads to development work, sometimes to a change in business process or providing additional information to someone. Sometimes its a big change but more often, and especially if the agile governance process is working well, it’s a small change caught early enough to be made without lots of consequences.

How to know it’s succeeding

When agile governance is succeeding, no one should notice. Perfect governance results in zero issues and zero rework, and we don’t notice what isn’t there. So we can only judge agile governance by its failure. If work goes live and causes issues, not just in the code but for other parts of the organisation, then governance failed. If that happens, run a retro with stakeholders to find out why and what you can do to fix it.

More thoughts from others:

• Tips on doing Show and Tells well
• The show and tell: what it’s for and how to do it right
• Running effective show & tells
• A decent hybrid show and tell set up
• Governance principles for agile service delivery