Category: Weeknotes

I did:

Hustlin’

This week involved quite a lot about how product managers sell their ideas, influence the right people, do the right kind of analytical thinking to support the ideas. It seems more like a personality trait and individual behaviour thing than a ‘lets have a process’ thing. Also did this stuff:

• Played around with personal OKRs again. I’m a big believer in them for dealing with uncertainty, but I’m not convinced they work in an organisation with lots of interdependences.
• Chatted about incremental and/or iterative product development, and how path dependency is the biggest enemy of agility.
• Did a few interviews for a senior product manager role.
• Talked about my nudge tools product concept.
• Ran a retro to help guide improvements for the next phase of a complex programme of work.
• Spent two days in the office.

Product meetup

Went to Product MK’s meetup and chatted to other product managers about validating ideas, refining value propositions, and using AI to analyse customer feedback.

I read:

Garbage can model

“The garbage can model (GCM) is a model within the area of organizational behavior that describes the decision-making process in so-called organized anarchies (organizations facing extreme levels of ambiguity in their decisional environments). The GCM attempts to explain how organizations make choices without having consistent, shared goals and how the organizations’ members are involved in these decision-making processes. The decision-making process within the organized anarchies is portrayed as a garbage can into which a mix of problems and possible solutions are dumped, with the particular mix determining the decision’s outcomes.”

I think it’s really important to understand how things work, and even though no model ever fully explains the complex and ever changing reality, models like this are genuinely the best way we have to think about the world around us. Thanks to Mike Gallagher for mentioning the idea.

The secrets of better judgement

Good decision making skills are essential for product managers. I go on (a lot, I’m sure people get bored of it) about product managers bring rationality to their work and be able to explain how they reached conclusions, which relies on good judgement.

Why 95% of employees don’t know their company strategy

I thought:

Learning rate

In a competitive environment, rate of learning matters more than what you learn. That’s true for product managers, product teams and organisations. But ‘learning’ often gets a bad rap because it doesn’t explicitly say, ‘and apply that learning’. And because learning is often applied later or in a different context in ways that prevents problems occurring in the first place, it’s almost impossible to see. But ‘not learning’ is easy to see in repeating the same mistakes or in making mistakes that were obvious to everyone else.

Slightly connected thought; the most important part of a leaders job is to be constantly updating their mental model about how the organisation works. The farther away that model is from the realities of how things actually work, the worse decisions a leader will make. The faster their rate of learning (Tip: one of the best ways to get that insight is to talk to lots of different people at all levels of an org).

What’s slowing you down?

Everyone seems to be talking about bottlenecks at the moment. If AI means that writing code is no longer the bottleneck, then the bottleneck becomes figuring out what’s the right thing to build, at least that’s what the narrative seems to be. I’m not sure. Bottlenecks can move downstream as well as upstream so maybe adoption becomes even more of a bottleneck. If everyone is quickly building products people want, then how they are differentiated, marketed, adopted, commercialised, etc., becomes the bottleneck. We know what happens to demand when markets are over-supplied. Remember product people, the goal isn’t to ship, it’s to create successful product.

“Humans are the constraint. Throttle speed to the constraint.” is John Miller’s advice.

Don’t align, resonate

You know what I think about alignment (and the garbage can model helps to explain why). Maybe “resonate” is a better alternative. It means to produce a deep, clear signal that continues for a while and feels meaningful to someone.

I did:

NudgeStack

Had lots of chats with Copilot to help me think about lining up a new internal product offering (and thinking of names for it which is always the fun part).

• Lots of analysis and scenario planning whilst we wait for a decision from senior stakeholders.
• Talked about different product development processes and frameworks and what factors help choose between them (luckily my masters thesis was about that).I think DABL works ok for new products or wholesale replacements, but it doesn’t work so well for mature products where marginal gains matter a great deal.
• Excellent coaching session talking about product thinking.
• Chatted about our product profession and what we’re doing to set expectations for the with product managers.
• Got told a product manager’s job is like being the guy wearing the padded suit that police dogs attack. Could be worse.

I read:

Reshuffle

Started reading Reshuffle: Who wins when AI restacks the knowledge economy.

Built for biological bandwidth

Jurgen Appelo’s idea of biological bandwidth really caught my attention. It’s a phrase that captures the problem AI creates. Our organisations, processes, methods and techniques have been designed for human minds to understand. And maybe, with AI, that’s no longer enough. As organisations become more algorithmic, more decisions will be made and more actions taken more quickly than any of the humans can keep up with.

From spark to launch

This paper looks at how AI shapes organisational innovation capability across new product development. It finds greater AI usage is associated with higher innovation capability, with the strongest gains in concept development.

I thought:

No answers in the building

Steve Blank popularised the phrase and insight that customer insight is essential for product development. I think it’s easy to assume it means user research and data analysis but everyone else carries on as before. But there’s so much more to it than that. It’s the difference between organisations assuming they know best and accepting uncertainty and ambiguity, and building the organisational muscles for dealing with it. It means having a culture of creativity, of stating things as hypotheses, of running experiments, and learning being held as the ultimate goal.

Agglomeration

Got interested in the idea of agglomeration, which is “the action or process of collecting, gathering, or heaping together a diverse mass of items”, and homophily, which is “the tendency for individuals to associate with others who are similar to themselves in terms of attitudes, values, background, beliefs, and social characteristics.” Basically, I’m interested in what forces drive things together. What explains how, in organisations, resources are pooled into departments, how pockets of knowledge and skills come to be in certain places, certain groups of people become aligned and some ideas and assumptions become dominant. I wonder if there’s any kind of universal theory that explains it.

I did:

Purist to pragmatist

This week involved deliberately sliding back and forth along the purist-pragmatist scale, and being as intentional as I could about what that means and doesn’t mean. And accepting that misalignment is a feature, not a bug. I also did:

• Did lots of planning for a roll-out over the next three months.
• Got approval to build an AI feature.
• Ran a session with technology leaders to consider how they manage different types of work, funded in different ways, for different teams and with different reporting requirements.
• Watched the team deal with an issue really well, and thought about how the potential for issues grows exponentially with every change in complex, interconnected tech.
• Worked on paper to explore some ideas, which I haven’t done in ages.
• Started planning a workshop to look at conversion rate optimisation opportunities.
• Ran a product vision exercise (not quite a workshop yet). It asks what needs to be true for the vision to become a reality to identify the conditions required for a product to succeed.

I read/watched:

Reality drift

I read reality drift from Boring Magic. It reminded me of a conversation I had a couple of weeks ago about trust and expectations of AI systems.

We’ve spent decades working with technology that is about providing a single right answer. Your HR system tells you how many days leave you have left, your banking app shows you how much money you have, your washing machine tells you how long the spin cycle will take. If they tell you the wrong answer, we know something is broken and needs to be fixed. That’s the nature of the deterministic technology we’ve all come to know and trust.

Now, with AI, we’re having to learn to deal with technology that doesn’t provide a single right answer, works in nondeterminisitic ways, and where getting something wrong isn’t a failure. With AI, the answers become take some time off, don’t buy those new shoes, and the sun is shining so hang your washing outside. Those answers aren’t the single right answer and they might be wrong or they might be what you’re looking for.

Problems occur when we expect AI technologies to work like other, more traditional, technologies. There are plenty of times where AI is the right tool to use, but my go-to reminder is ‘only use AI if there isn’t a single right answer’.

The purpose of data is knowledge

And the purpose of knowledge is to allow you to predict the outcomes of your business actions. Common Cog’s series on Becoming Data Driven in Business is fantastic. I started at the end with Becoming Data Driven, From First Principles (you’ll get the joke if you read the intro to the series), which talks about spotting the difference between routine variation and when the data is telling you something significant has changed, either because you did something to change it or because you didn’t. It ends with, “Understanding variation leads to the process control worldview, which leads to an org-wide pursuit of knowledge.”

Rory Sutherland’s 2026 Predictions

Rory talks about businesses being in cost-reduction mode, which might not be a very revolutionary prediction given everything that’s going on in the world. He says modern business is an efficiency competition and that AI will be used by business leaders attempting to win that competition. What I think is interesting about this is that it shows how things without a clear definition, e.g., AI, mean whatever we want them to mean given our worldview.

AI interfaces

Interfaces-on-the-fly is one of those interesting ideas that’s been around a little while. Maybe it’s the path to making personal AI devices ubiquitous MacGuffins in our lives. Imagine a blank smart phone screen that becomes a chat window where you ask your AI assistant to compare running shoes and the interface evolves into a comparison site -looking interface to help you choose and then into a shopping experience to buy them, and later a map interface as you track the delivery.

I thought:

Misunderstanding evidence

When we talk about being evidence-led, what do we mean? I think, we shouldn’t mean undisputed proof that something is true. We should consider evidence as how a phenomenon appears in the real word to allow us to test theories against it. It’s more of an academic definition than a criminal investigation definition and it allows for more useful thinking. If we take evidence to mean incontrovertible proof, and for all kind of reasons, we aren’t able to get that evidence, then we’re stuck. There’s no where else to go. But when we treat evidence as not an end in itself but as part of the process of theory-evidence-analysis, then we can use the observable evidence (accepting its incomplete) to test our theories.

The product operating model for non-product companies

One view of the firm says there are three big value-driving functions: customer relationships, new product development, supply chain management. For the university I work at, new product development is for the information goods (courses) that our customers purchase, not the technology products they use to interact with the course material and tutors. Technology products are in the supply chain management function because they are how the organisation distributes it’s goods. In our case, we use a direct distribution strategy which means the only place you can study our courses is with us, using our technology products. That’s why they are essential to our business model, and make for an interesting product operating model.

Marty Cagan recently posted about the difference between internal and commercial products, which may (or may not, I’ll let you decide) fit for this kind of (mostly mythical) modern product organisation where customer relationships, new product development and supply chain management are all wrapped up in the same commercial product and internal products which support the commercial ones. Our products aren’t like that. We don’t have commercial products in the sense that someone pays to use our products (because what we actually sell are information goods, as I explained above), so by Cagan’s definition all our products are internal products, except they aren’t because they are used by our users. Our products are something different.

So when we talk about a product operating model in the context of a university, we have to be quite strict and critical with our thinking to make sure we stay within the supply chain management function, which sounds like it should be about lorries and logistics but for a distance learning organisation that distributes its products via the internet, is actually about data and technology. Our product operating model isn’t like that of a product-led commercial company, but neither is it like that of a non-technology company with a traditional IT function. Our product operating model is something else.

I did:

Balancing

Four day week so being super efficient, I got this stuff done:

• Talked about getting more balance in our decisions by ensuring we have multiple perspectives.
• Wrote a retro analysis and report.
• Went to a really good review and planning session lead by one of our brilliant delivery managers. It’s so good to see a data-driven approach in action which over time will make delivery predictions far more accurate.
• Passed beta-to-live stage-gate.
• Planned the rollout of our new product. Adoption is always the hardest part of product work.
• Chatted about the difference between metrics that measure product performance and those that measure usage, because you should be able to judge the success of a product regardless of how many users it has.
• Thought about how to better support product managers with some workshop-y training sessions.

I read/watched:

What are the chances AI will replace universities?

Good to know.

Towards the evaluation of UX

Interesting collection of papers about user experience.

How to write for AI search

SearchEngineLand’s playbook for machine-readable content got me thinking about

Abandon cart emails

Read some research on abandon cart emails to help me think about how best to use them with some of our products.

• The Effectiveness of Triggered Email Marketing in Addressing Browse Abandonments
• The determinants of consumers’ online shopping cart abandonment
• Examining online shopping cart abandonment through the lens of consumer confusion
• The psychology behind cart abandonment: why do customers leave without buying?

I thought:

Taxonomies, topologies and ontologies

Thinking about how we think about how to organise things, taxonomies, topologies and ontologies provide three different (and easily confused) ways.

Easy as a strategy

Thought about the assumption that making an interface easier to use must lead to higher conversion. I’m not saying products should have interfaces that are hard to use, far from it, but how do easy-to-use interfaces create a competitive advantage? I don’t see it. I don’t see a cause-and-effect relationship between a user’s experience once they are using a product and getting more people to start using a product, there’s a lot more to it than that.

Time flies

Five years ago I was talking about asynchronous working for product teams and thinking about how we understand problems.

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”.

I did:

Consequences

You know that game where players take turns contributing sentences to a story without knowing what each other wrote and is then read out, usually with hilarious results? Sometimes product management feels like that.

• Did some consequence mapping to try to explain the implications of the decisions we’ve made in a product.
• Used the Decision Stack for some product vision work, using the question, “What would have to be true about.. accessibility, security, user behaviour, etc, to achieve the vision.
• Presented my talk “Product strategy is easy and everyone should do it” at our product community of practice.
• Went to a day-long session on creating a career framework. It’s an interesting problem and gave me lots to think about.
• Monthly Business Review as part of our new reporting framework.
• Talked about introducing an AI analysis tool for optimising campaigns. If we can send communications at times that work better for people we can make sure they get the right information when they need it.

I read:

Cultivating communities of practice

Interesting book by Wenger, McDermott and Snyder. My takeaway is that communities of practice rely on people who care about a common domain of knowledge and share practices that they are developing to be effective in their domain, but the most important thing is a communities aliveness.

Work is weird

The ‘what AI is doing/will do to work’ debate is really interesting to me because, as Charley Johnson says, work is such a weird thing, which makes it hard to analyse because we end up talking at cross-purposes about the definition instead of the thing itself. At this stage, I still think AI is more likely to have the scale of impact that email had rather than the scale of impact that electricity had on work.

Managers doing leadership: The extra-ordinarization of the mundane

Alvesson and Sveningsson did a study that shows how important listening and dialogue is for leadership. I still maintain there is no better leading indicator for organisational change than the number of conversations leaders have with people below their pay-grade and outside their reporting line.

I thought:

Why there’s no such thing as a product map

Even though there is such a thing as a service map, there is no such thing as a product map.

A map is an abstract representation of an environment that displays signs, symbols, and spatial relationships. To make sense, everything on the map needs to be the same kind of thing. A map of a city has roads and buildings because they are both physical objects in the territory the map represents. That map doesn’t have the colour of the socks worn by people in the buildings or how long the road has existed because these are completely different types of things, which means they wouldn’t make sense on a map of a city.

Mapping works for a service because there is a commonality of signs, symbols and relationships. You can’t get to that commonality for a product, and so you can’t abstract it in the same way. There is no way to represent governance as the same type of thing as budget or user interface. All of the different things that make up a product mean there is no way to map a product.

Changing my mind about frameworks

I used to be anti-frameworks. Now I realise I was actually anti- generic, context-free frameworks. Recently I’ve noticed my thought pattern of quickly building throwaway frameworks to do a very specific job (it’s true what they say, if you want to learn something, try teaching it). It proved useful for an analysis exercise for my MBA. I was the only one in the class who got answer right, not because I know more, but because I could come up with a framework that structured the analysis and made the answer obvious.

I did:

Short-term vs long-term

The impossible dilemma reared its ugly head a few times this week. Choosing (and its always a choice) between short-term and long-term value. Didn’t find any answers so I did this stuff instead:

• Got back into Google analytics and Looker Studio. It’s been a while.
• Wrote my talk on product strategy for our community of practice.
• Presented at a show and tell (well, I say presented but really all I did was talk a bit).
• Chatted about user research and repositories for research insights.
• Ranted about solutionism (again).
• Lots of stakeholder management.
• Thought more about a framework for product responsibilities, and dare I say it, rethinking the idea of the CEO of the product (yeah, I know the source is problematic).
• Got a bit overly-protective of one of the product managers.

Yay! 500 weeknotes

500 weeks ago I was struggling to get stakeholders attention and so starting sending them a weekly email about what the team was doing. It later became my reflections on each week on my blog and I just never stopped. I think having a reflective practice (like writing weeknotes but many other ways are also available) is really helpful for anyone who works in a fast-changing area like digital and product.

I read:

The Future of (Public Sector) Product Management in a Vibe Coded World

Very cool.

Beyond technical debt unravelling organisational debt concept

I got really interested in the idea of organisational debt and this paper does a good job of explaining it. It also suggests agile principles are good for reducing organisational debt.

The Best Interface Is Invisible: Rethinking UX and Design for Agentic Ai

“Agentic Ai systems now challenge the deepest assumptions embedded in interface-centric thinking, and not because interfaces disappear entirely, but because interaction itself changes character. People are no longer necessarily operating a tool step-by-step. Increasingly, we are expressing intent, delegating outcomes, and collaborating with semi-autonomous systems capable of interpretation and action.”

There is no product

Really interesting post about what GenAI does to the economics of products.

Distributed leadership

Distributed leadership theory helps us understand how leadership works in empowered autonomous teams. It still considers leadership as a status, but gives that status to everyone on the team, meaning everyone is involved in leadership activities such as dividing and allocating tasks. One of the limitations of distributed leadership is that people are given leadership status regardless of whether they have the skills to perform the leadership activities well. That’s why a coaching approach from managers outside the team is so important for making empowered autonomous teams effective.

Supply and demand

Saeed Khan says vibe-coding is not product management. Can’t believe it even has to be said, but there you go. What’s far more interesting is how Saeed defines product management as being about supply and demand. A product manager’s job is to understand demand and then provide something that meets the demand. I broadly agree, even if the traditional economics that underpin it are increasingly questionable. The trifecta of business functions of ‘new product development’, ‘supply chain’ and ‘customer relationships’ provide a useful framing for product operating models. The POM that is usually talked about involves product managers operating in all three areas. But that’s not appropriate for every type of organisation. In some, product management doesn’t operate in ‘new product development’, it operates in ‘supply chain’, with the Internet as the means of supplying information goods.

Transforming health and delivering the NHS 10-year plan

Richard Pope’s talk about the NHS 10-year plan, including:

1. Digital ways of working, not just digital technology.
2. Apply platform thinking to clinical functions and understand local needs.
3. Convert the public from consumers to co-producers.
4. Proactively shape the software environment the NHS operates in.

And a big YES! to the NHS thinking and operating like a big tech company.

I thought:

Competing forces

An organisation is a system like any other with competing forces to maintain stability and to change. These competing forces affect each other, reconcile for a short time, get out of balance again. This is constantly happening. The teleological idea of a perfect end state where everything will be alright, all the conflict resolved, everyone aligned, a well-oiled machine that just gets on with it is a myth. It seems like the myth of the end-state causes lots of problems, even though everyone knows we’ll never get there.

Strategies to avoid

There must be loads, but so far on my list of strategies to avoid is Mcdonaldization and Marginal gains. Mcdonaldization is standardisation to the point where there is no differentiation. Marginal gains is about optimising for efficiency which run out. Both are bad strategies.

Responsibility vs responsibilising

Responsibility is taken, it’s intentional, the scope and consequences are known. Responsibilising is giving responsibility with or without someone knowing, with or without the scope and consequences being known. There’s a big difference.

I did:

Compounding interest

Building on what’s gone before, establishing basecamps for the next climb, compounding interest over time… I don’t know what I’m saying about the past but good products do these things for the future. And I did this stuff too:

• Ran a workshop on how to create a product vision (see below for why vision matters). Key points were it’s an ongoing process of asking what would have to be true to make the vision a reality and checking you’re making things more true.
• Discussed a new way of working for a team that should help them collaborate and learn from each other better. It’s a bit more ‘the team in the unit of delivery’.
• Talked about user testing with prototypes and figuring out your research questions first. Prototypes aren’t for proving yourself right, they’re for validating assumptions.
• Collected evidence for our beta-to-live assessment in a few weeks. We’ve got twenty criteria to meet but I’m really keen on us holding ourselves to account.
• Started batting ideas around for a talk I might do at our product community of practice.
• Chatted about a little peer-to-peer mentoring idea I’ve got.
• Started a list of ‘things to think about’ for product managers taking over a product which covers things like budget, resourcing, stakeholders, etc., as product management is always so much more than shipping software.
• Got volunteered to run another retro.

I read:

Time utilization

“For most office jobs, tasks arrives at random time and the size of each task varies.” Apart from being cool just because of the maths, it’s particularly interesting to me because I think our product strategy is based on the concept of time utilisation. My hypothesis is that our competitive advantage comes from helping students manage their time better and reduce the time spent on admin tasks so they have more time to study, which leads to greater academic success.

Fast is a Moat

It’s an interesting question. Does speed create a defensible competitive advantage? Maybe some of what Hardik says isn’t about speed, it’s about momentum, but still… how does speed create an advantage? The old Schumpeterian assumption used to be that speed meant you could get to market ahead of competitors and achieve a first-mover advantage, and be the only one to get the customers. But that idea hasn’t really panned out and there are lots of example of late movers actually getting the advantage because getting to market first isn’t the only thing that leads to success. And maybe that’s the answer. Speed alone doesn’t create a defensible competitive advantage, but along with lots of other things, maybe it helps.

Are you delivering impact as a product team?

How AI Destroys Institutions

Yeah but no. AI doesn’t destroy institutions, humans using AI destroy institutions.

Post-digital

After a chat about trends in digital, multichannel, customer experience, etc., I remembered this from five years ago about , so I read a bit more about post-digital and what it means for universities going through digitisation.

• Meet the new schtick by Russell Davies
• What is Post Digital? by Adam Tinworth
• What is Post Digital? by Florian Cramer
• Postdigital science and education by Petar Jandrić, Jeremy Knox, Tina Besley, Thomas Ryberg, Juha Suoranta &Sarah Hayes

I thought:

Why do product managers make such a big deal about vision and strategy?

Product vision and strategy, along with other conceptual tools like Outcomes and OKRs, help us navigate uncertainty and ambiguity. If things were certain and in our control we wouldn’t need those tools, we’d just make a plan and follow it. But because the world is an unpredictable place, markets are constantly changing, and what affects user behaviour is uncertain, we need tools that reflect this reality.

Metaphors

I’ve mentioned before how metaphors like steering the ship don’t fit our modern pluralistic understanding of organisations so I’ve been wondering what metaphors might fit. Here’s my first try… Organisations are like plants. Small start-ups are flowers, they can point in one direction at a time, towards the sun (the sun is the market) to collect it’s resources, and they change direction as the sun moves. Large organisations take a different approach. They are more like trees with lots of leaves pointing in all different directions. As the sun moves, different leaves collect it’s resources, but the tree doesn’t move. Metaphorically, it suggests leader’s job is to grow the right leaves on their branch so the org can get sunlight from lots of directions at the same time.

What’s needed for an org to move from reactive to proactive?

Nia asked this question in her weeknotes. My answer is, for orgs to be less reactive they would need their world/ecosystem to change less often and more slowly. So maybe orgs need to get better at reacting, rather than trying doing less of it. I get the implication of ‘being reactive’ suggesting not enough forethought, planning, strategy, etc., and I agree those things are important when used in the right way. Long-term investment shouldn’t be in making a plan everyone can stick to for the next ten years, it should be in building the capabilities to adapt quickly.

Workaholism

I’ve been study business ethics as part of my MBA, and one of the topics is workaholism, so I did a survey and scored top marks for being a workaholic. Yeah, no surprise there, but it made me wonder what drives that in me (and yes, I fully recognise it as a long-standing personality trait not an organisational environment thing). One of the anxieties I definitely feel is ‘things going in the wrong direction and building up path dependency before I can change them’. I’m not worried about things going wrong, that seems like a natural thing and easy enough to fix and learn from. But things going in (what I think is) the wrong direction seems like a particularly product-y concern.