Month: October 2025

I did:

Dialectics

Most of my work this week seemed to be about talking to people or getting them talking to each other. And although, of course conversation is good, how we converse matters too. That’s where dialectics comes in, it helps us arrive at the truth through reasoned argument.

• Delivered a retro and planning session. As always with retros, the session is the easy bit, making changes after it is the hard bit.
• Prepared for another retro I’m running in a couple of weeks.
• Went to a planning session to help teams figure out dependencies they have with each other.
• Chatted to our director of strategy and marketing about behavioural science in product design.
• Wrote some discussion docs to get people talking about how to assessment opportunities and how to bring more coherence to teams working in adjacent spaces.
• Started setting up an insights library to provide a single source of information to help teams be more evidence-led. One of logic tests buzzing around in my head is that product decisions should be highly reliable, valid and reproducible. That means, if someone else looks at the same data as the product team, they should reach the same conclusion.
• Thought about the post-study product space around alumni networks and careers. It’s an interesting space to figure out value because the commercial relationship with the user is (mostly) over.
• Chatted about weeknotes, which I have to include in my weeknotes for the meta-ness of it all.
• You know you work with amazing people when they send you poems.

A year of task tracking

It’s been a year since I started using my new task tracking system. That I’m still using shows me how successful it is. It’s a personal kanban approach with Today in the middle, all the past tasks to the right and all the future tasks to the left. Each item is tagged with the project, whether its a task or meeting, how many minutes the meeting lasted. And other things like whether it contributes to my objectives. It’s all in Notion, which means I have graphs showing all that data.

Tasks completed: 1524.

Minutes spent in meetings: 32,685.

I’ve haven’t figure out how yet, but I’d like to be able to calculate the flow efficiency of each piece of work. I have the data for how many tasks each project has, how many meetings and how long they last, and what date the work started, so it should be possible.

I read:

The fewer managers a company has, the stronger its culture

This post talks about organisational culture as infrastructure and operating system and what happens to it when organisations flatten their hierarchy by removing managers. In short, removing hierarchy removes hierarchical culture, which needs to be replaced by some other kind of culture.

The rise of Agentic Shopping

Interesting post from Marc Abraham on AI doing your shopping for you. The use case Marc talks about involves the agent monitoring the price of an item and purchasing it from the retailer with the lowest price. It’ll only be a matter of time before our AI assistants are making more complicated purchasing decisions, so every company that sells on their website is going to have to get ready.

NHS app to become default patient communication channel

I get the logical mistake. If you want digital transformation, you expect it to be on the internet. But why would any organisation operating in the 21st century think that single channel is the way to go, and more importantly, why would you choose a channel that relies on the written word when so much of the existing communication is spoken? It will demand a lot of changing user behaviour and expectations to get people to think of using an app first, and even more behaviour and expectations change to get NHS staff to write clearly. If you use the NHS app and see the notes your GP adds, you’ll know what I mean. Moving to a written communication channel means moving to a written communication culture, and that is a big move.

Talk to each other, work together, be helpful, check things are going ok

My most read post this week is my four principles for great team work. Some universities and training providers link to a few of my posts so I can always see when they are running a course in my website analytics.

I thought:

Flywheel or marginal gains

I have some additional thoughts about what might make escalators and mazes succeed or fail. Escalators suffer from the marginal gains problem. That is, while in the early days small improvements can have outsized results, it takes increasing investment to get further gains. Soon enough, optimisation stops working. Mazes have a different problem. To keep people in the maze they rely on self-reinforcing feedback loops that give users reason to stay. Without some kind of flywheel of reward, where a user takes an action and feels some emotional consequence which makes them act again, users will leave the maze.

Powers of data

Evidentiary- prove something happened.

Explanatory- show how it happened.

Predictive- suggest something will happen.

Blank slate vs building-on

Pondered a bit on the tendency to start from a blank slate when tackling a new piece of work versus looking for ways to build on what already exists. I guess creating the systems that serve as ratchet mechanisms to allow for building-on can seem like more work than starting from the beginning each time, but it’s the only way to create bigger and better things.

I did:

Continuous change

• Had more chats with people from the team I’m joining. Still more to meet but everyone is so generous with their time and knowledge. It’s helping me to understand a really complex product.
• Learned about how one of our policies is reviewed and changed to meet changing user needs.
• Was asked how much of my time is allocated to a piece of work. It started me thinking about how things like that might be decided. I’m lucky to be able to make my own decisions about how I spend my time.
• Chatted about spotting potential problems and getting ahead of them before they become real problems. It’s not easy, especially if others don’t see the potential.
• One of the product managers showed me a vibe-coded product that had a really clever feedback loop built-in. I so impressed with the thinking behind it. I work with some really clever people.
• Read about how our new organisational strategy is shaping up. It’s really good to see how much it focuses on our societal impact.

I read:

Competitive by design

Public Digital’s collection of writings about user-centred design, modern technology practices and a test-and-learn approach.

Iterate, if you can

James Plunkett wrote, “Although design and user research have led the way in making public services work better for users, these disciplines sometimes add to this sense of work being linear. Work often starts with a long upfront design/research phase, without any ‘build’ or real world testing.” That’s definitely a problem.

Here’s another. Often, the skills needed to get a service/product live are not the skills needed to iterate towards success. So, here are some of the things teams need to be able to iterate:

• An understanding of how to run experiments. It’s a specialist skill set.
• Experimentation tools to set up and run experiments quickly and easily.
• Product instrumentation and data analysis capabilities and skills to understand the results.
• A team resourcing model that supports the uncertainty around experiments taking unknown lengths of time to get results, and unclear changes that might need to be made.

Winning at new products

Bought Robert Cooper’s 2011 book on product development. I can’t believe I’ve never read it as Cooper’s Stage Gate model was one of the product development processes I analysed for my masters dissertation. I’m interested to find out what it says about teams using stage gates to make decisions to stop work.

I thought:

Alliance and adaption

I’ve been thinking about pluralism… a lot. It explains so much about how our work happens and what it takes to succeed.

I’m a member of two product groups, two teams, a profession and a department. I work with various stakeholder groups and lots of other teams. Each of those groups can “claim to possess, and attempt to exercise, a measure of legitimate authority over their members.” (Muñiz-Fraticelli, 2014). Or to put it another way, they all think they are right, and none of them can tell any other that they are wrong.

This has it’s advantages of course. “Constructing a pluralistic intellectual environment and nurturing a culture of critical dialogue and skeptical inquiry will help draw out a more robust exchange of ideas.” (Whittington, 2019). But on the downside, it means things go more slowly.

Unitarist product management tries to align these group’s goals. When it can’t, it regards this as conflict and expects that conflict to get resolved. But a pluralistic culture doesn’t want to resolve conflict. It sees conflict as a natural and necessary part of more important things such as critical dialogue and discussion.

A pluralistic product manager accepts that every individual, every team and every informal gathering has their own goals. Progress towards one’s own goals is made through constant reflexive negotiation with all those other groups.

I’m not sure autonomy and alignment works in pluralistic cultures. Maybe alliances and adaptions is a better fit. It describes how teams seek success by affecting other’s goals and adapting their goals for others.

High alliance	Lots of changing other team’s goals but not so much changing own goals in response to others. Win/lose.	Adjust own goals to meet other’s needs, build alliances with others and influence them to adjust their goals. High-performing teams who understand their pluralistic cultures operate here. They create win/win situations.
Low alliance	Fixed goals, not much adjusting with other teams. Unitarist teams operate here and so struggle in pluralistic cultures. It’s lose/lose.	Lots of adjusting own goals to meet other’s needs, not much influencing others to adjust their goals. Lose/win.
	Low adaption	High adaption

Coherence over coordination

Yes, I know I’ve previously gone on about ‘with not over’, but this is the exception that proves the rule. Product managers should be more focused on creating coherence (of purpose, of context, of business model) than on coordinating work. All things being equal, if you only have an hour, spend it on coherence.

I did:

Multi-directional

• Lots of chats with excellent people from the new team I’m working with.
• Read lots of documentation.
• Went to a workshop with a cool design system consultant. Lots to think about for how to spread a design system. Also, helped me realise that our design system is about more than just making websites look good, it’s an essential part of regulatory compliance.
• Started working on a new product strategy.
• Talked about ideas people have been working on that face considerable constraints and blockers. It’s a explore/exploit problem – how much time should we spend exploring and investing new opportunities.
• Discussed approaches to reviewing and prioritising opportunities, which fits the decision stack nicely, and
• Worked on a complex attribution model to explain which user touchpoints on which channels contribute to conversion.

The numbers

Tasks completed: 55.

Minutes spent in meetings: 1135.

Bubbles

I went to bubble planet, an immersive virtual reality experience. It’s pretty amazing how easy it is to convince our bodies they are moving. I know VR will probably never go beyond this kind of entertainment, but I’d definitely be up for virtual reality work environments where I create my own space for dashboards, people, documents, etc.

I read/watched:

What great product leaders do differently

Leading with control, goals and measures maximises what people do with their hands. Leading with context, problems-to-solve and collaboration maximises what people do with their minds.

What is choice architecture?

The product strategy I’m working on is about helping people make the right choices for them so I’ve been learning about choice architecture, cognitive bias, behavioural economics and libertarian paternalism.

I thought about:

Problem/solution matrix

In complex products and services, it can be hard to connect the features we deliver to user problems and see where we’re solving and what gaps exist. I like the problem/solution matrix to help understand this. It looks like this:

	User problem 1	User problem 2	User problem 3
Solution 1	✅
Solution 2		✅	✅
Solution 3		✅

Solutions are often features we build into the interface, but they can be policy changes, existing system rules, in fact all the parts that make up the product. By simply ticking which part of the product tackles which user problem, we can see which features are targeting which problems and we see the gaps where a problem isn’t being solved.

It can get really complex if you go into very specific problems, but that’s not a bad thing for complex products and services because hiding the complexity often leads to shipping features that don’t solve the problem. Show the complexity!

It’s also a useful guide for setting expectations about how ‘solved’ a problem is likely to be, and for continuous improvement later if a solution doesn’t sufficiently solve a problem. If the problem looks big and gnarly and we only have one feature targeting that problem, we’re probably not going to solve it.

Explaining outcomes

Had a few chats about outcomes this week so thought I’d try to get my thinking straight.

It would be great if everyone agreed with Josh Seiden that outcomes are a change in user behaviour that gets business results, but not everyone does and time spent arguing over definitions is usually wasted. So, it’s ok to accept a word-cloud of synonyms like result, conclusion, consequence, after-effect, etc.

Outcomes match against problems and come after solutions are successful. So it goes: problem → solution → outcome. Outcomes match to problems, because an outcome can only be achieved by solving the problem. The easy test of a team that says it’s outcome-focused is to ask which problems match which outcomes. If they don’t know, they aren’t outcome-focused. Solutions don’t always lead to outcomes, that’s why we say things like ‘outcomes over outputs’ to make the point that just because we’ve shipped something it doesn’t mean people are using it and it’s actually solving their problem.

The three big outcomes are ‘easier, faster, cheaper’. It’s what every user wants and what every product and service promises. So, if your outcomes are just that (or synonyms of those words like simple, easy-to-use, quick) then you’re saying your product is just like everyone else’s. Easier, cheaper, faster are givens. They should just be what every product and service achieves anyway. Good outcomes go deeper, they differentiate the product, which is why the have to match to real user problems.

Outcomes are outside of our control. We can make the best solutions possible and still not achieve an outcome. That’s why we measure and iterate, but it’s never certain.

Pluralistic product management

The reading I’m doing for my MBA is already helping me understand and explain better why communication and stakeholder management is so important in product work, and why the kind of product management you see on YouTube isn’t fit for every kind of organisation.

The kind of product management you see on YouTube fits in organisations that have a unitarian culture. This comes with the assumption that everyone in the organisation agrees about and works toward the same goal. Things that take people away from that singular focus are seen as bad.

There are a whole bunch of other types of organisation that have pluralistic cultures. These organisations have multiple goals, which are often in conflict with each, push against and negotiate with each other. That is accepted in pluralistic cultures, it’s not considered a bad thing, it’s a normal part of how the organisation works. What that means for product managers working in these kinds of organisations is that the noble effort of trying to get everyone aligned behind the same goal isn’t going to work. It might make good narrative but we have to accept the reality that different people, groups and teams have different goals, and that’s ok. We can understand it, navigate it, and still succeed. It’s a feature, not a bug.