Month: March 2026

I did:

Lining up

I was on leave all this week so only did a bit of lining things up for next week, including:

• SEO analysis and advice for a product we might want to market in the future and so need to design for that now.
• Discovery plan for “come back and finish what you started” emails (AKA abandon cart emails). We’re starting with a single use case but I’m hopeful we can develop it into a reusable service for any internal team.
• Wrote a ‘product thinking’ exercise for a PM I’m coaching.
• Reviewed some work a PM did on a shared backlog for assessing opportunities.
• Tying up lose ends ready for next quarter’s budgeting.

I read/watched:

Autonomy vs alignment

Maarten says alignment is more important than autonomy. I disagree. I think autonomy is far more important than alignment.

Alignment, by which we mean everyone in an organisation trying to achieve the same goal, is a unitarist aim, and unitarism is pretty well recognised as anywhere between bad and false. An organisation is stronger if people are simultaneously trying to achieve different goals because no single thing is so overwhelmingly important that other things don’t stand a chance.

Autonomy is really important for modern organisations to respond to changing circumstances at pace and at scale. There are lost of academics and researchers that have reached this conclusion and autonomous teams have a century of history behind them.

Autonomy, as a management idea, goes back to Mary Parker Follet in the 1920’s where she proposed ‘the law of the situation’, which said those with the most knowledge should lead. This challenged the traditional hierarchical notion of leadership as people in authority telling those who aren’t what to do, and started to put decision-making power in the hands of those doing the work. The 1930’s saw the human relations movement which shifted the understanding of management as being not just about the work but also about the people. In the 1950’s, Trist and Bamforth studied autonomous teams in coal mines and developed the socio-technical systems theory. They stated that the innovative way teams were working provided an increase in productivity and provided the first real template for autonomous teams which still stands today.

Autonomy isn’t easy. In fact, Malone (1997) claimed the balancing of top-down control with bottom-up empowerment is a central issue for organisations in the twenty-first century, and Parker et al (2015) said that “organisations remain adverse to self-organised teams, and it is suspected that not willing to let go of direct control by senior management is the root cause.” But, it is really important. The benefits include “lessening the need for supervision, providing more flexibility and agility, improving employees’ work satisfaction and loyalty, reducing costs and boosting quality” (Sanne, 2021), and Patanakul, Chen and Lynn (2012) showed that autonomous teams outperform traditional project teams in circumstances involving novel technology and radical innovation.

So, if you’re a leader and you have to choose between alignment and autonomy, do the right thing, choose autonomy.

Size matters

Got a bit obsessed with the idea of things rolling-up into bigger things so watched lots of ‘the size of things’ videos to get my head around the underlying logic. It’s one of those things where once you notice it, you can’t stop noticing it. Addresses – house numbers roll up to a street, which rolls up to a town, and so on. Tomatoes – punnets roll up to shelves, which roll up to aisles, sections (fruit and veg), supermarkets. Same pattern, so many applications. I still don’t understand why. But when you recognise that its such an intuitive and pervasive way of organising things, it makes sense that we’d think about product metrics in the same way.

I thought:

Organisational feedback mechanisms

I’m sad to say that because of the poor state of NHS mental health services in my area, I’ve had numerous contacts with the Patient Advice and Liaison Service. They have never given advice and aren’t very good at liaising, but if you have a complaint they are your only option. They will send your complaint to a manager who will, eventually, provide an explanation. Not an apology or acceptance of mistakes or promise to change, just an explanation. Follow the process and carry on as before. But if an organisation doesn’t give it’s complaints department the teeth to demand improvement, then what else could we expect.

How organisations accept feedback from people they have let down says a lot about their commitment for improvement. If the answer is, ‘computer says no’, or ‘policy says no’, or ‘manager says no’, or even ‘national framework says no’, then it’s clear there is no commitment to improve. There is only an even stronger commitment to maintain. Keep the things the same, just the way we like them, because they work for us, and we don’t want to lose our sense of self-importance and power.

Customer complaints are more than just a current quality signal, they are feedback from the environment about emerging needs an organisation should be trying to meet. They show the direction of evolution to be future-relevant.

Types of product strategy

Kind of changing my mind about marginal gains as a product strategy. Maybe in well-established organisations and markets with narrow margins, marginal gains is the right approach. Maybe all those little improvements add up to something big.

The Pareto principle is another concept that’s interesting for product strategy. If the problem space has lots of variability and we think the optimal solution is in standardising the majority of simple use cases and handling the complicated ones by exception, then power law distribution guides that thinking pretty well.

Others might be Hick’s law, which states the time it takes for a person to make a decision as a function of the number of possible choices. Tells you how to make your product strategy about helping users make better choices.

I did:

Hourglass

Hourglass was my metaphor of the week, meaning something along the lines of how we pay attention to the little bit in the middle but the big stuff happens either side of it. Make sense? No? That’s why I’m not a poet. I spent my doing this instead:

• Ran three retros, over four and half hours, for 60 people. Now comes the analysis. I’ve also been live-chatting (it’s like live-streaming but with chat messages) to keep notes on the things I think about when doing a retro in the hope I might turn it into some kind of training.
• Chatted about the difference between ‘right first time’ and ‘right over time’.
• Had a great coaching session with a product manager. He had some interesting questions.
• Got some clarity on the direction of one of our products and I’m really happy with it. Feels like the direction actually takes us towards our goals, which isn’t always the case.
• Thought about using a ‘min spec’ type workshop to mind map all the aspects of a piece of work necessary for it to succeed, and using that to set the scope and plan of the work. I’m wondering if it might help teams see the bigger picture of product development and that it isn’t solely a technical thing.
• Wrote an evaluation plan for a feature, including a/b testing it with users and ROI analysis. It might seem like boring stuff but I think it’s part of how you know you’re doing product work because you’re trying to find out if what you shipped is actually solving a user problem, just shipping it isn’t the measure of success.
• Did some release planning. Checklistastic.
• Met our new tester. Made me realise that I stopped having intro calls with people. I should start that up again.
• Finally found a way to bring two of the products I’m working on together. Hope it works.

I read:

Product Management ‘Set Texts’

Tom Dolan’s Product Management ‘Set Texts’ is an excellent list of books product managers should read. Made me wonder how many of them have, and I wonder what the key lessons are from each book.

Economies of scope

Economies of scope is an important idea for product strategy thinking. It says that efficiencies come from variety, not volume. It’s important to remember because the economics of most digital products are based on the idea of software usage having near zero reproducibility costs (build something once and sell it to lots of people), but diversifying based on what you’ve already built gives you two things to sell.

Service Nirvana

Kate Tarling was on the Mind The Product podcast and talked about the challenge of assuming the status quo is neutral and risk-free, which makes it hard to accept change. It grabbed my attention because I don’t think I’d ever realised that point about org change. The other interesting thing Kate mentioned is that although a few companies do some aspects of service really well, there are no examples of organisations doing services well as a whole. I think that tells us something…

Messy docs

Say Yes to the mess!

Autonomous teams

I’m reading lots of stuff autonomous teams at the moment, but Jan Henrik Gundelsby‘s paper on enabling autonomous teams in large-scale agile through architectural principles stood out.

I thought:

Developing a stance

I was looking for patterns in my conversations with other product people and one that comes up a lot is the idea of developing a stance on things. Whether its backlogs or communication or evaluation, just having the knowledge and skills isn’t enough, product managers need to have a stance. Take backlogs for example, it isn’t enough to know how backlogs work, you also need to have a position on what job they do, what are the limitations, what scenarios do they fail, what challenges come up in using them effectively, etc., etc. All of this helps product managers develop their position on backlogs, which helps them shape their product practice intentionally.

Coherence

Product management is about coherence. It’s about bringing all the parts together in a way that makes sense as whole. Its the logical connection between parts of a whole avoiding contradictions and conflicts.

My little library

Found this old collection of 4580 links to things I read over three years ago. It’s like a history of things I was vaguely interested in enough to read about, like innovation in 2020, web3 and blockchain in 2021, and GenAI in 2023.

I did:

You can’t make an omelette with breaking some eggs

You always lose something when you create a new thing. That’s part of the work to change and improve things. Did this stuff too:

• Talked about what’s next on our roadmap and when it becomes now.
• Went to a workshop to help join up product, policy and operations, which was really helpful in agreeing our responsibilities.
• Saw a really excellent example of the team critically evaluating work and deciding not to do it.
• Chatted about the conundrum of needing to know what you want to achieve to justify starting work and needing to start the work to figure out what you want to achieve.
• Had a great chat with a product manager about career development.
• Said farewell to one of our associate product managers who’s taking a year off to travel. I’ve really enjoyed getting to know him.

Future of education AI

Went to a jam with Oxford University’s UX team. We spent the day going through a user-centred design process for understanding a problem. It was interesting to see how others approached it.

I read:

Platform product management

Read two books on platform product management. The power of product platforms and Effective platform product management. They’re both good but aren’t quite giving me what I’m looking for, mostly because I’m not sure what that is, other than some way of framing the difference between platform product management and the other sorts of product management.

Your Theory of Change Isn’t a Theory

This caught my attention because I’m a big believer in theory of change. I agree that the theory of change documents we create tend to be too linear and fixed. A theory is any hypothesis or set of ideas intended to explain something, especially one based on general principles independent of the thing to be explained. The point of it is to test it against reality and refine it until it provides consistent and reliable explanation. That’s a big mindset shift from how most organisations operate. They still work on the assumption of a predictable world where a theory of change can be specified upfront and doesn’t need testing.

What can we automate?

“What can we automate?” rather than, “What future are we trying to create, and does this tool help or hinder it?” I wonder about this too when using AI in product management, but maybe the either/or nature of the question is wrong. Maybe the future we’re trying to create is just one of improved efficiency and productivity through automation. That’s certainly the economics perspective. There is a future where the scale of change AI brings is similar to email; it doesn’t fundamentally change what we do, it just makes it faster at scale. And there is another possible future where AI’s scale of change is akin to electricity, and so it does change what we do, how we do it, and why we do it. Of course, the future isn’t evenly distributed so different parts of society will experience change differently, and the timeline matters, are we talking about a year or a century.

I thought:

Self-efficacy: Toward a Unifying Theory of Behavioral Change

Self-efficacy is an individual’s belief in their capacity to act in the ways necessary to reach specific goals. The concept was originally proposed by the psychologist Albert Bandura in 1977.

It’s an important concept for product manager’s because as our job to change user behaviours in ways that achieve business results (you know, outcomes)

Bandura’s model says “expectations of personal efficacy are derived from four principal sources of information: performance accomplishments (such as previously being successful in accomplishing something on the product before, AKA “aha” moments), vicarious experience (learning from other products that behave in consistent ways, e.g., the X to close a pop-up is always in the top right corner), verbal persuasion (spoken or written communication such as onboarding videos and micro-copy explanations), and physiological states (how calm the person is because the product is quick and easy to use). The more dependable the experiential sources, the greater are the changes in perceive self-efficacy.”

Achieving a stronger sense of self-efficacy makes it more likely users will change their behaviours and achieve the outcomes we want.

Backlogs

There’s a lot more to backlogs than most people think.

What’s most important:

• The principles – forcing function to reduce options and increase focus, limit work in progress, make work visible, etc.
• The logic – prioritisation criteria, queuing theory, etc.
• The information – about the item, e.g., assignee and status, which allows the item to be managed, and info about the work the item represents, etc.

What’s less important:

• The tool – Jira, ADO, Trello, Post-it notes, whatever works for the team.
• Who manages it – It should be a shared team task anyway.
• Why the work is on it – Obviously that’s important for other reasons, but the backlog doesn’t represent those decisions.

Productisation

“Productisation relates to the process of analysing a need, defining and combining suitable elements, tangible and/or intangible, into a product-like defined set of deliverables that is standardised, repeatable and comprehendible. “ Yeah, that’s product management.

Flow efficiency

Thought about the flow efficiency of the things I’m involved in, which things have higher and lower flow rates, and why.

If I spent all my 37.5 hour week on one thing, it would have a flow efficiency of 100% because I’m at full capacity on it, and a piece of work that has one 30 minute meeting a week has a flow rate of 1.33%. Knowing this helps us understand the difference between working on something for four hours in one week, which has a flow rate of 10.7%, and working on something for one hour a week for four weeks, which has a flow rate of 2.7%. We spend the same amount of time on the work overall, but focusing and getting it done in one go is more efficient.

Observations:

• Flow rate becomes more interesting the longer the time period it’s measured. My coaching work had a flow rate of 10% last week, which is pretty consistent with other weeks. Learning and development had a flow efficiency of 21% this week, but if I look over a year it drops to 0.5%.
• It’s also more interesting as an indicator of time trade-offs. So if I consistently spend the same amount of time on something each week, it will have a consistent flow rate, but when other work causes me the adjust how much time I spend on something
• Flow rate slows when the wait time in between working on something increases. If instead of one hour a week for fours, I do one hour a fortnight, the flow rate drops to 1.3%.
• It’s ok for some types of work to have low flow rate because it’s the kind of work that progress slowly but regularly, things like risk management meetings that will never be “done”.