Month: January 2026

I did:

Setting the pace

Someone said to me that work progresses at the pace of the slowest part of the process, which is totally theory of constraints and absolutely right. I tried not to be the slowest part of these things:

• Worked with a junior product manager who presented at an operational team meeting and got loads of really useful feedback. Validating it and acting on it is next week’s job.
• Talked through the logic of an evaluation model I’m working on.
• One of our team had cause for celebration and I’m really proud of them.
• Chatted about user research and evaluative interviewing.
• Went to a prospects marketing presentation.
• Reviewed some discovery work on product KPI’s and really keen to see what prototype dashboards come out of it.
• Took part in a research interview about scaling AI in organisations. My main take is to treat it like email but for content generation. Sure, everyone uses email but the real value is in having a team that knows how to use email to communicate with users and drive valuable action.
• Said goodbye to a couple of colleagues.

The numbers

Tasks completed: 64

Minutes spent in meetings: 1290

Real-time interaction with: 47 people 146 times.

I read:

In praise of guessing

I love this. I’ve fallen into the same trap of thinking it’s wrong to guess.

The perfect rollup

As usual, John is surfacing and verbalising the things the rest of us know but can’t quite articulate convincingly.

I thought:

Misunderstanding DABL

I think it’s easy to mistake the Discovery, Alpha, Beta, Live product development process as a ‘big upfront design and then implement’ approach. Actually, it’s more of a ‘trying things, filtering, throwing out’ approach. What sometimes happens (but shouldn’t) is that Discovery and Alpha is seen as filling up the backlog of things to be built in the future, rather than the more critical job of finding out what not to build. If Discovery finds twenty problems, Alpha should prototype five and Beta should solve one.

Mixed methods

The difference between using a plan and using a roadmap to explain and predict the future is in what you believe about the world around you. If you believe you live in a predictable world, then you use a plan. If you believe the world is uncertain and ambiguous, you should use a roadmap. Problems arise when we mix the methods without understanding the worldviews. If we call it a roadmap, have columns called ‘Now’, ‘Next’ and ‘Later’, give those columns timeframes, such as quarters, plot work to fit in a timeframe with a defined end-date, describe work as delayed if it passes that date, then we are confusing our beliefs about the nature of reality.

My position is that product work is about changing user behaviour, which makes product management ontologically relativist and epistemologically constructionist. Whereas realists believe there’s one single, stable, measurable, knowable reality, us relativist product managers believe reality is constructed within the human mind, that one true reality does not exists, and instead, reality is relative according to how individuals experience it at any given time and place. We’re interested in how individuals experience their reality, what we can do to change that experience, and how we might not if we have. We believe meaning is created for our users through their interactions with the world, and we want to understand how people make sense of things when they interact with our products.

It’s not that one position is better or more right than another, it’s perfectly possible to take realist/objectivist position on product management, but my point is that if we aren’t clear with ourselves and our stakeholders then we risk mixing positions, creating roadmaps with dates, and confusing everyone about whether we’re predicting things in a stable world or adapting to things in an uncertain one.

Why AI will change product management

I’ve been pondering the narrative that AI won’t fundamentally change what product managers do, it’ll just mean they can prototype quicker. I see how that works in the short-term but in the long-term AI will bring a massive change to product management because it will bring a massive change to management theory and practice. One way will be in how management is conducted. Knights and Willmott’s forms of control tell us that managers can use direct control, bureaucratic control, control by performance and control by culture to get people to comply and conform. AI will enable a fifth form; control by algorithm. This will change business management and so change what product managers do. It is inevitable.

I did:

Cohesive collectives

Some of the groups I’m part of are well-formed and others are less so, and I noticed that more intentionally this week. I think groups work better when they have something to coalese around so I need to think more about what those things are beyond organisational structures. Anyway, I also did this other stuff…

• Had an interesting session with our new team members and others that work on the same product in different ways. It wasn’t nearly long enough because there’s so much to know, but it was the first time I thought of all nine of us as a single collective.
• One of our product managers wrote some amazing outcome-focused objectives and key results. I need to up my game.
• Talked about product management and product managers developing a USP.
• Had a business review meeting, which I really enjoyed, and think it’s going to be the driver for product managers joining up their thinking so we can present more cohesively and being more about outcome-focused.
• Took part in a show and tell. I really want to make our show and tells less progress update and more agile governance, but I’ve already got lots to do.
• Met our new director of product strategy and talked about product’s relationship with other things in the university.
• Talked about the nature of product development and how you can’t be delayed if you don’t have a deadline.
• Started researching how to make course credit machine-readable (because of digital transformation).
• Started designing a methodology for metrics and reporting for complex change across the university, so no pressure.

I read/listened to:

Guides slow learning

Actually, guides that feel complete can slow learning. That’s the point Harry Bailey makes, which is an interesting challenge outside agency project management. How much information is too much? How much space for figuring things out is just enough? My go-to thinking for this is, where is this thing in the ‘experiment-optimise-standardise’ process? If you’re doing something completely new, then don’t follow a guide, experiment and share what you learn for others to optimise. If you’re doing something that has been done lots of times before, then follow the guide, use standardised patterns because it’s more efficient.

Invisible work

Invisible work is an interesting idea. Rian van der Merwe talks about the shadow backlog as a symptom of a roadmap that doesn’t reflect reality.

It got me thinking, what does it mean to make work visible? It’s a principle I believe in but have never really questioned. Why should work be visible, which work, and visible to who?

Often it’s the meta-work that is invisible and seen as non-productive (see glue and grease below), but the more complex an organisation becomes the higher the ratio of meta-work to work (if you don’t believe me just count how many people in your organisation do productive work and how many managers there are).

Taking that idea of all work being visible to the extreme, imagine an organisation where every activity has to be agreed and planned in advance. It would be a coordination nightmare. No one could do anything without permission. No creativity. No spontaneity. We don’t want that, so celebrate the meta-work, the invisible work, the glue and the grease work.

How to lead without authority

Sean Flaherty talking about behavioural science on the product experience podcast. Although I don’t agree with everything he says, it’s nice to hear more people talking about behavioural science in product management. We really need to figure out how to apply behaviour change techniques more consciously to our products.

I thought:

I blame Total Quality Management

The concept of ‘internal customers’ is one of the worst ideas in business. I’m all for customer-focus, although it has it’s issues, but when it treats colleagues as customers it creates a dysfunctional relationship with an unhealthy power dynamic.

Deadlines

A few different conversations got me thinking about deadlines and theory x theory y management. Deadlines, as we usually thinking about them, are an extrinsic motivators from theory x. Understanding the context and impact of certain dates is an intrinsic motivator from theory y. But the thing is, in most cases for most teams, neither of those make any difference because the factors that affect whether they deliver on time are outside the team.

Glue people and grease people

I was thinking about glue people and what that means when serendipity sent me Duncan Stephen’s blog post in which he says that glue people are “superconnectors”. Glue people connect other people, they are all about relationships. They join-up ideas and stick things together. They are important and necessary people to have in organisations.

And then there are grease people. They move things along. They are bothered about progress and momentum, about getting stuff done. They are important and necessary people to have in organisations too.

You need both (and all the other types of people).

I did:

Explainability

This week seemed to be a lot about what we can explain and how and why it matters. And I did this too:

• Adapted my product topology to be more acceptable to our current understanding of products (sometimes I’m just too visionary :D) and added the capabilities each product needs. Still more to do but it’s a useful exercise to see which journeys collect data, which send emails, etc.
• Worked on product metrics a bit. It’s one of those topics that just goes deeper and deeper the more you look into it.
• Talked about how Trigger’s broom explains what a product is. You can change the parts (tech, UI, etc.) but the whole remains.
• Set up an evaluation model for one of the products I’m working on. It’ll help us understand the finances and see what effect changes have.
• Talked about the puzzle of why university’s professional services departments aren’t ahead of the curve in modern business practices when they have first-hand access to academics and researchers that are creating the curve.
• Started a product decision review, which is where I look back at decisions we previously made and ask if they we’d make different decisions knowing what we know now. The answer is almost always, ‘yes’. It’s a great learning exercise. Maybe one day I’ll turn it into a little workshop.
• Someone asked me what the most important product management skill is. The answer is easy; critical thinking. Without that product managers can’t really do product work.

The numbers

Minutes spent in meetings: 995.

Number of tasks completed: 61.

Passed 2,000 items (tasks and meetings) in my tracking tool, which gives me a pretty good data set to analyse my productivity.

I read:

What should product managers learn?

Another brilliant post by Seyifunmi that really got me thinking. My answer is to create a method for learning in verticals that you can apply to any topic. So, for example, if you want to learn about stakeholder communication you can start at the top with tactics about communication channels (yeah, I still make the mistake of emailing people even though I know only 40% of them will read it), then you get into principles of good communication like working in the open, and maybe you branch off a little into psychology but then you go deeper into communication theories, and right at the bottom you learn about dialectics. Think of it a bit like ‘5 whys’, each time digging deeper into you get to the real learning.

Has Your Product Management Role Quietly Turned Into Project Management?

“…to be a successful Product Manager, you must be an excellent project manager. The ability to coordinate, track, and execute is a foundational superpower.” That explains it then. I’m a rubbish project manager. You wouldn’t want me project managing anything more important than putting the bins out on the right day. But to offer an alternative perspective…

Project management is a highly-skilled profession in it’s own, and product managers shouldn’t be trying to be second-rate project managers. If you’re a project manager, you have my admiration. I’ve worked with some amazing project managers who blew my mind with their ability to coordinate things. If you’re a product manager, and if you’re lucky enough to work in a context where this is possible, focus on coherence, not coordination. Your users will thank you when the product makes sense and helps them solve problems. They won’t thank you because you met a deadline.

Project management excels where there is more certainty, and product management where there is uncertainty. So, when Seyifunmi says, “…product management is about what and why. Project management is about how and when.”, she is expressing this distinction. There is a certainty to ‘when’ that comes from human beings having systemised time into a calendar. There is lots of uncertainty about ‘why’ an organisation is doing what it’s doing in which markets for which audiences. These questions often remain unanswered, and that’s fine because it isn’t a product manager’s job to answer them. A product manager’s job is to create some coherence amongst all this chaos.

A Radically Good Product Framework

I love a good framework as much as the next person but in my experience product teams don’t have a problem asking the right questions, they have lots of problems getting to answers that make sense, that remain unchanged for long enough to guide progress and that continue to make sense retrospectively. Show me a framework for doing that.

Inside-out and the outside-in orientations

“The inside-out and the outside-in perspectives point to different sources of competitive advantage for firms (Roquebert et al., 1996). Even though both perspectives consider both internal and external elements, they vary in terms of the relative emphasis they place on these elements (Paladino, 2009). While the inside-out orientation primarily considers organizational resources, rather than competitors and customers (implicitly), the outside-in orientation appears to reverse the order by first examining customers and competitors and only then the degree to which the firm responds to them, so organizational resources are implicitly addressed (Paladino, 2007).”

How do I lead change when people agree in public but resist in private?

Really interesting post on change. As product managers, our job is to change user’s behaviour in ways that achieves their outcomes and business results. For most product manager, the really important word there is ‘user’. They are only responsible for changing users behaviours, not colleagues behaviours. But the more senior a product manager becomes, the more they have to be able to change colleague’s and leader’s behaviours to create the space for doing the work to change users behaviour. In most organisations, that’s most of the product work.

I thought:

Evaluation drives efficiency

If something has to be able to be evaluated then it has to become standardised so that the outputs are comparable. It’s the old, “What gets measured, gets managed” nonsense, where ‘getting managed’ means being controlled, standardised, analysed. I’ve talked before about where standardisation is appropriate, but it really is key to good evaluation. When the same word means different things to different people, understanding has not been standardised. When a number can be interpreted to mean different things, insight has not been standardised.

The interaction theory of the firm

Thought about how to explain organisations as being about people interacting with other people. Whether its employees interacting with employees, employees with customers, or customers with customers, the reason organisations exist is to keep people associated with the org (HR for employee retention, marketing for customer retention), aligned with its purpose, and interacting with each other. If the theory holds, the better an organisation is at making those interactions happen, the more successful it will be. Employee communication, collaboration, alignment, customer service, branding, all exist to improve the nature of the interactions.

I did:

Because

The word “because” is used before giving a short reason or explanation, especially when you think the reason or explanation is obvious. We don’t use “because” enough. Maybe because we think the reason is obvious, but we should remember it isn’t always. Us product managers need to know our because. And we need to use it more to get people to the right focus, not just on what we did but why we did it. That is my reflection this week, and I did this stuff too:

• Retro analysis and recommendations.
• Talked about the work behind the work behind the work (because you can always be more meta).
• Listed (because not everything needs mapping) the big things we want to change within a service.
• Talked about business impact being athe focus for product managers.
• Thought about a new product I’d love to work on that connects alumni together to provide mentoring, networking and career connections.
• Lots of interviews (a third of my scheduled working hours, in fact) with some interesting and unexpected results.

I read:

The power of intentional incompleteness

Rachel shared this fantastic post with me about the power of intentional completeness. It talks about one of the bias we have for wanting to complete incomplete things. It’s a useful bias when designing products because we can use it to help people finish things. I really need to get on with writing about behaviour change for product managers. Given our job is literally about changing user behaviour, psychology and behaviour change methods are so lacking in our body of knowledge.

Ballantine’s Hedge

Wonderful thinking from Matt Ballantine on how to consider organisational change and six principles to remember. 4, new hedges planted in uncleared ground struggle, and 6, the soil determines what grows, are the ones that stuck with me.

Bring Clarity to Complex Services (Without Service Mapping)

I haven’t quite figured out why but there’s something that bugs me about always expressing services as linear, sequential steps, so finding other ways to represent and understand them is exactly what we all need. I really like simple dashboard -type views so I’m definitely going to build on what I’ve done so far with these examples.

Re-wiring risk & control

Led by the amazing Ann Gambles, this discussion about risk and control talks about the motivations for having green dashboards that don’t reflect reality.

I thought:

Why focus and alignment is the wrong approach

A lot of the day-to-day management and thought-leadership around how to be an effective organisation/team/product manager follows a narrative that says if we can just get everyone aligned on the same goal, get everyone to focus on the most important thing, then performance will magically emerge as a result. It’s an attractive and simple narrative but it’s wrong, and it’s wrong in two ways. Firstly, that singular focus is the right state to aim for, and secondly, the assumption that singular focus results in higher performance.

Why circles of influence is nonsense

Because you’re not meant to do things on your own. You’re meant to team up, join forces, work with others until together you have all the influence you need.

The power of content people

It seems like a consistent pattern in organisations that produce and manage lots of content, that content people are widely distributed across other teams and subordinate to functions like design. I think it’s a quirk of historical organisational design that means all forms of content aren’t considered specialist enough to be together in the hierarchical structure. I wonder if changing that would make any difference to anything.

Measuring silos

If conversation is the unit of culture change and you can measure it by counting how many conversations leaders have with people outside their reporting line and below their pay grade, then what is the unit of analysis for breaking down silos and how would you measure that? Maybe the first part of breaking silos is making work visible, so the metric is it the number of people outside the team that are aware of the work (because we’re outcome-focused, the measure is always about people’s behaviour and not output measures like number of emails sent). Needs more thinking, but it’s probably worth it.

More ways RACI can be improved

And by improved, I mean scrapped completely.

From…

Accountable	One person
Consulted	A few people who don’t really want to be involved
Informed	A few more people who’d rather keep their distance

To…

Objective 1	Whole bunch of people who need to work together to achieve it
Objective 2	Whole bunch of people who need to work together to achieve it
Objective 3	Whole bunch of people who need to work together to achieve it

I did:

The Zeigarnik effect

The Zeigarnik effect is our tendency to remember unfinished or interrupted tasks better than completed ones. So, given it was a one day work week (why did no one think of this before!), I focused on new things rather than finishing things from last year. Go figure.

• Fed back on the product development section for our new delivery playbook.
• Did some research into the leaky bucket problem and a sense of belonging to help with a new product strategy. They are surprisingly connected concepts.
• Added a strategic hypothesis and future projections to a new business review dashboard.

2025 review

Wrote about things I’ve thought about and written in 2025, just like previous years.

Resource library

Started moving my product resources library to Notion. It’s not really the right tool but I use it for lots of other things so at least it’s easier for me to add new stuff to. Maybe one day I’ll actually do something with it. Maybe I’ll build a product that helps product managers learn about

I read:

Top 10 AI PM mistakes of 2025

What ~2k hours training and engaging ~1k PMs revealed about AI hype, bad product thinking, getting vibe-fired, and 2025’s biggest AIPM mistakes.

Head Up, Feet Moving. Complexity isn’t a spectator sport

Study complexity science. Learn the concepts, read the papers. But at some point, if you want to work effectively in complex systems, you have to engage with the system as it actually plays out.

Arrive. Pommel. Leave.

Really nice essay about being a specialist and focusing on your strengths. Of course, it’s not the only strategy to career progression, and you should always consider your context.

Imperfect, impermanent, and incomplete

Another nice essay from Steve Kamb, this time about, “finding beauty in the understanding that everything is imperfect, impermanent, and incomplete. To embrace Wabi Sabi requires the ability to reflect on the fact that change is the only constant, nothing lasts forever, and perfection is unattainable.”

I thought:

Reflections on line management

• It’s not like it used to be. Although we still use the term ‘line manager’, we don’t manage production lines anymore. Cross-functional teams and matrix organisational structures mean managers and managees are often not working on the same things. This means line-management can’t be directly about the work, and line-managers can’t get direct feedback about a managee’s performance. So line-management has to be approached differently.
• As a line-manager, my goal is to give the people I support the skills and experience to get a better job and leave the organisation, and create the kind of environment that makes them want to stay. That way, whatever they decide is a win for me.
• Mostly, line-management involves switching between coaching, mentoring, advising, instructing, training.
• Career development opportunities are often the hardest part of line-management because most organisations are set on having people doing their current job, not get a new job. My approach goes like this:
  • Ask the managee to find a job ad for a role they might like in five years time. This grounds the discussion in real life skills and experience and measurable distance to cover.
  • Find opp.ortunities that help the managee develop their skills and experience to, one day, match the job description.

Business objectives

Just as there are really only three user outcomes (easier, cheaper, faster), there are only five business objectives (and Dave McClure nailed them years ago):

• Attract new users (acquisition / growth)
• Get users using (activation / conversion)
• Keep users using (retention)
• Get users to pay (revenue)
• Get users to tell others (referral)

Roadmaps

One of my realisations from last year was that no single roadmap works for the entire product development process from idea to decommission. Format aside, and whether roadmaps should show dates because we all know the answer to that, the problem is there is no single unit of analysis that can represent all the different work that takes place across the product lifecycle. This is an interesting problem that must have a solution, which probably looks like a definition of how roadmaps should change across the product lifecycle.

MVP does not mean

You can’t call something an MVP just because it’s:

• Unfinished
• Untested
• Unproven
• Unsupported
• Unmeasured
• Unclear
• Unfocused
• Underwhelming