Category: Weeknotes

I did:

Talk, talk, talk

“Most of the successful people I’ve known are the ones who do more listening than talking.” -Bernard Baruch.

• Planned out team capacity and budget for the next year. It’s like the behind-the-scenes of our roadmap.
• Talked about product KPI’s.
• Facilitated a retro.
• Talked about recruitment challenges.
• Shared my initial thoughts on product strategy and big bets for early feedback.
• Had lots of wonderful chats with other product managers. It’s always energising.

I read:

How to think about bets

What is a Bet? In gambling, it describes the act of risking something of value (usually money) on an uncertain outcome with the hope of winning something of greater value. In our context, a bet represents a logical container of investment (time, attention, focus, energy, and funds) that we are willing to risk for achieving a desired impact.

The past and future leader

“Less time spent on administration and more time on data insight with AI governance means leaders and managers could oversee larger and more diverse teams… One possible and more negative future is where leaders manage AI while AI micromanages individuals who then have less autonomy and agency.”

It made me think about whether the history of leadership can tell us anything about the future of leadership.

“Drath et al, propose an ontology in which the essential entities are three leadership outcomes: (1) direction: widespread agreement in a collective on overall goals, aims, and mission; (2) alignment: the organization and coordination of knowledge and work in a collective; and (3) commitment: the willingness of members of a collective to subsume their own interests and benefit within the collective interest and benefit… Adopting such an ontology would mean that talk of leadership would no longer necessarily involve talk of leaders and followers and their shared goals, but would necessarily involve talk of direction, alignment, and commitment. Likewise, to practice leadership would no longer necessarily involve leaders, followers, and their shared goals but would necessarily involve the production of direction, alignment, and commitment (which may or may not involve leaders and followers).”

If we merge these two perspectives it’s clear the future of leadership doesn’t look much like the past.

The Five Dysfunctions of a Team – A Complex Systems Critique

Simple linear reductions of complex contexts aren’t helpful.

People’s minds

Products are always about how people think and feel and behave.

How to think strategically when AI is changing search, discovery, and distribution

Interesting thinking about product discovery as AI takes over search.

I thought:

#NoAlignment

The problem with the idea of alignment is that it assumes there is something fixed to align to. It doesn’t recognise everything is always changing and moving.

I have the same problem with roadmaps. They show one perspective at one point in time, when really everything is changing all the time.

Personally, I like the ambiguity but our tools for thought aren’t designed for ambiguity.

I did:

Think big, start small

Thinking big, starting small was definitely a theme for me this week. In some case, how we struggle to think big enough and in others how we don’t start small enough. Where it does work, it can lead to amazing things, so it’s still a principle I stand by.

• Took part in a problem space analysis session to bring together our thinking on organisational context and emerging strategy, policy and regulatory changes, and user research and known user needs. It’s a lot to think about and figure how each thing might affect our business model.
• Did an opportunity space mapping workshop in Excel. I’ve been experimenting with doing workshops without using Miro. The retro I did last week was in Loop and that worked pretty well.
• Went to a hackathon for AI.
• Used ‘working backwards’ to talk through a future business case I’m working on with another product manager.
• Chatted about the product skill of breaking big things down into small. It really is a skill.
• Planned a ‘who does what’ workshop. I’ve done this before to help product managers and delivery managers figure out how to work better together. I think it’s better done between people to bring out their strengths rather than using a standardised RACI (’cos, ya know, individuals and interactions over processes and tools).
• Went to our community of practice, which I usually miss because of other meetings. One of our senior product development managers led an excellent discussion on product metrics.

I read:

Management by objectives

Read lots about MBO and how it may be a useful for making an organization efficient, but it is no longer suitable for modern management because of the changing business world.

“Although MBO and empowerment represent a major step forward in management, they get results only insofar as employees are committed… The challenge today is not so much empowerment, but ownership: the sense of belonging, and the sense of purpose… In theory, MBO is intended to enhance communication and understanding up and down the hierarchy and across departments or units. The reality is rather opposite. The inflexibility of personal and departmental goals ends up creating a lack of cooperation between people and departments. This is because the goals are not geared toward the common good, but rather individual gain.”

The author of this 1972 paper thought that MBO would be consider an old fashion idea by the 1980’s. How wrong they were.

I believe OKRs done right are the antidote to this way of managing. Rather than assessing individuals by outputs, we should judge teams by outcomes.

43 minutes per staff member per day

Ben Holliday write about the problem of using AI in healthcare to improve on administrative processes that might be better fixed in other ways. My rule for using things like Copilot is to only use it if there isn’t a single right answer. And, I assume, lots of healthcare processes are about getting to the right answer, whether its how many boxes of surgical gloves to buy or which department has to cut their budget.

Service patterns

I’ve been thinking a bit about service patterns and then I read James’ weeknotes, which took me to service patterns UK, which took me to Ben Holliday’s website, which took me took to the gov design blog, which took me learn to drive a car. But all the while, the little product manager voice in my head said, “That’s just features.”

Sociotechnical principle of the day

Trond Hjorteland’s thread on sociotechnical principles is a really interesting read.

I thought:

How to identify strategic levers

Strategic levers are an important part of a product strategy. They describe the things within your control that you are going to use to affect things outside your control, usually user behaviour in a way that makes the product and organisation successful.

There has to be a cause and effect relationship between a lever and user behaviour. That relationship should make intuitive sense and the effect should show in the data. That’s why we treat levers as hypotheses, because until we’ve proved the effect of using the lever it’s little more than an informed guess.

The best way to figure out the levers your product should use is to start with the worthwhile problems you’ve identified. Ask yourself, what could solve this problem? Sometimes it helps to think of the levers as carrots or sticks, as things that encourage the kind of user behaviour you or discourage the kind of user behaviour you don’t want.

Then you need to think about how these levers work together and complement each other, and don’t counteract each other.

Metaphors

I’ve been thinking about the metaphors we use to talk about our products. At the moment, I like thinking about products as vehicles that take users on their (not our) journey.

Sometimes our users want a car so they can decide where they want to go. Other times, we want them to have a taxi with more knowledge about how to navigate to where they need to get to. And sometimes we want them to get on a bus so they can travel with other users. These three forms of travel; self-guided, org-guided, and community-guided, give us metaphors for talking about different types of products.

You know what else I realised? Business jargon is the same kind of abstraction as metaphors.

Mcdonaldization is not a product strategy

If your product strategy is about being the same as every other product, being unnoticeable and unremarkable, then you don’t have a product strategy.

Ritzer (1992), who came up with the term Mcdonaldization, was referring to organisations whose strategies are focused on being predictable, calculable, efficient and controllable.

A good product strategy knows when to use this kind of standardisation, but more importantly, how to differentiate. (This goes alongside my thoughts on marginal gains not being a good product strategy either).

The elephant and the knowledge workers

Us humans have a tendency to claim absolute truth based on our limited, subjective experience and inadvertently ignore other people’s limited, subjective experiences which may be equally true.

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.

I did:

Starting

Started lots of new things this week.

• Started a new business case for some future work.
• Started meeting people from a new team I’m joining soon.
• Thought of some ideas for an upcoming AI hackathon.
• Watched a presentation on some brilliant service design for how to improve outcomes for students furthest from advantage.
• Started planning a workshop about opportunity space mapping.
• Wrote a list of 4000 profanities for blocking from our platform. The things I get up to.
• Chatted about playbooks and how they should be the “collective wisdom of multiple voices”, not an instruction manual for the one and only way to do things.
• Set my annual objectives. I’m not usually keen on personal objectives when everything we do is in collaboration with others, but I’m interested in setting a baseline and seeing how much I can achieve in twelve months.

I read:

Autonomy and alignment

I’ve been trying to understand autonomy and alignment better so I watched and read:

• Finding a balance between organizational alignment, team autonomy and control in large-scale agile organizations. Daemen, Bart N.P.
• Team autonomy in large scale agile. Moe, Dahl, Stray, Karlsen & Schjødt-Osmo.
• Spotify Engineering Culture – Part 1. Henrik Kniberg.
• Spotify Engineering Culture – Part 2. Henrik Kniberg.

And learned:

• Autonomous agile teams increase employee motivation and job satisfaction significantly as well as boost creativity and productivity.
• The biggest barriers to autonomy are teams understanding overall direction (goals are often set by management without involving the teams, that they are often equal to deliverables and deadlines so team members don’t know what the goals are) and managing external dependencies (which requires extra, often distracting work).
• Formal (e.g., standardised reporting) and informal (e.g., shared values) control mechanisms are necessary for organisational alignment.
• Enabling constraints (e.g., work in progress limits) help teams have autonomy.
• Feeling a heightened sense of responsibility is an important cultural element for achieving the balance between autonomy and alignment.

My conclusion is there is a big difference between autonomy and alignment and autonomy in alignment. If you ensure alignment first through enforced control mechanisms and only give teams autonomy within those controls, then you aren’t balancing autonomy and alignment.

Releasing the work at the right rate

A roadmap for successful AI adoption in Higher Education

I respectfully disagree. Not only does the article not mention any of the challenges facing higher education institutions, it talks about starting with well defined problems, but then only problems that can be solved by AI.

I think it’s important to remember that AI and its economic benefit is still just a big bet, it isn’t proven yet. I’m leaning towards it having a revolutionary impact on society but that taking decades to pan out, so in the short-term here’s my roadmap for success with AI (in higher education or any sector):

• Understand your users. If AI bursts, you’ve got a better understanding of who uses your products and services.
• Fix your data. If AI doesn’t pan out, you’ve got your data in good shape.
• Improve your content. If AI fails, you’ve got great content.
• Train your people. If AI doesn’t replace everyone, you’ve got really capable people.
• Improve your operational processes. If AI doesn’t automate everything, you’ve got a more efficient organisation.
• Encourage a culture of innovation. If AI doesn’t live up to its promise, you’re able to respond to the next big change.
• Coach your teams. If AI doesn’t become the ultimate assistant, you’ve got great teams that can tackle complex problems.
• Educate your leaders. If AI doesn’t create new business models, your leaders will.
• Update your technology. If AI isn’t the next big tech trend, you’ll have reliable, secure systems.
• Run experiments. Even if all your experiments with AI fails, you’ll know how to learn from evidence.

Sort all those things out and AI is easy. Don’t sort them out and nothing you do with AI will succeed.

Thinking about managing

Started reading about the history of management for the first module of my MBA. Interesting insight: cross-functional teams in coal mines were studied back in 1951 for the efficiency gains they had over functional teams with hand-offs.

I thought:

What we get wrong about prioritisation

In his talk about team trust, Tom Dolan mentioned the challenge of prioritisation is (and I’m paraphrasing) that we’re not comparing apples with apples, we’re comparing apples with oranges with a pear tree with an orchard with the concept of horticulture. There is no way to make a rational comparison. So the answer is to not compare. The answer is asking the right questions to decide whether to go forward with the opportunity. Every opportunity should be assessed on it’s own merits.

Future of work

Adam Smith gave us the phrase ‘division of labour’ in 1776 and the factory owners of the industrial revolution turned it into the standard concept for organising work around specialists who perform one part of all the work required to create something of value. Since then pretty much every job has been based on that idea, whether it’s manufacturing, service or knowledge work, each person only knows how to do their little bit.

AI might be the thing that finally changes centuries of industrial thinking about how to organise work. Rather than people with limited specialist knowledge moving the work onto the next person once they’ve done their bit, we’ll have people who are domain generalists doing the human stuff like relationships and navigating messy social systems working with AI that has the specialist knowledge in the domain.

Health care is an obvious example of a domain that could see this change. A patient wouldn’t see a nurse for triage, a radiologist for an x-ray and a doctor for treatment. In this new world, they’d see one person who would use AI to do the triage, x-ray and treatment.

Privilege distance

If power distance matters within organisations, then privilege distance matters between organisations and users.

I did:

Zoooom

Sometimes I work on things that will come to fruition years into the future, but the things I worked on this week things seemed much closer, only weeks or months away. Zooming into the detail and out to to big picture, connecting stuff happening now to far-off futures, thinking strategy, tactics and logistics, and holding all these different perspectives is a product skill I aspire to.

• Chatted about bias-for-action and when exploring options rather than deciding now is the right thing to do, and my agile decision-making experiment for leaders.
• Led a leadership standup session. It was interesting to try out the ritual at a larger scale of work. Maybe things like standups working in fractals is a sign of a good ritual pattern.
• Thought about how we choose the right methodology for certain types of problems, e.g., service design for services, six sigma for processes.
• Saw some fantastic delivery management clearing space for technical folks to really focus and achieve loads.
• Chatted about using a personal triage scale of 0 – not worth my time, 1 – I’ll do this myself, 2 – My immediate team needs to be involved, 3 – This needs more coordination across the wider team, and 4 – This needs lots of coordination across and outside the team.
• Went back to the scenario planning I did a few months and updated based on what we know now. Its a really useful tool for staying on track towards some uncertain goals.
• Wrote some business rules in Gherkin. It’s been a while since I’ve used it but it’s nice to brush off old skills sometimes.
• Lots of interviews.

The numbers

My busiest week for a long time.

Number of tasks completed: 62.

Minutes spent in meetings: 1,110.

Escalators and mazes

One of the ways I sometimes use my weeknotes is to get a new idea down and see if I think about it enough to expand on it in a blog post. Escalators and mazes is one of those ideas. These metaphors describe the two broad types of digital products. Escalators take users from one place to another and mazes keep users within the maze. Because “product” doesn’t have a single definition and is often easy to talk about at cross-purposes, I think it’s useful to have lots of different ways of thinking about product, including using metaphors.

I read/watched:

Demystifying product management

Joined Herd Consulting’s fantastic webinar on product leadership skills, radical focus, listening, nudging decisions, correcting for bias, messy realities, experimenting, learning in motion, and aiming at opportunities.

Trusted team toolkit

Got to watch Tom Dolan do a practice run through of his talk for Agile Cambridge. He had some really interesting ideas and practical tips on how teams can focus on building trust.

Kevin Hall triple

Bought kill bad meetings, speed lead and making the matrix work, all by Kevin Hall. I haven’t read them all yet, but I flicked through them and they look interesting.

Stop Saying “Product-Led.” It’s Setting You Up for Failure

Kinda obvious for anyone who’s done and product transformation in a complex organisation but important to say nonetheless. There’s an interesting pattern where complex organisations that do lots of things can’t adopt any a single approach like being product-led for the same reason they can’t get to being strategically focused, there are just too many people, teams and departments to ever reach consensus and coordination.

Scrum Guide Expansion Pack

I read the Scrum Guide Expansion Pack. That’s half an hour of my life I’ll never get back.

I thought about:

Probabilistic product development

Last week, I read Sarah’s post about how the product development process is not designed for building with AI. So I thought a bit about what a probabilistic product development process might look like.

It would be rhizomatic.

It couldn’t use the ‘think big, start small, learn fast’ pattern of modern product development because there would be no way to define any kind of end state or outcomes up front.

It would use language like possible and probable to describe what might happen.

It would accept that user outcomes are unpredictable and uncertain, along with knowing that the product interface and interactions are unpredictable.

Balancing over overing

Not outcomes over outputs. Better to think of it as balancing outcomes and outputs. We talk a lot about trade-offs in product management, as if we can ever choose one thing over another. Instead, it’s almost always a messy mix of different and sometimes conflicting things.

The strategy is relevance

“Relevance is the quality of being closely connected with or appropriate to the matter at hand, indicating the degree to which something is useful, pertinent, or applicable to a specific situation or goal” -thanks Perplexity.

Relevant to who, about what, by how much? Those are strategy questions for organisations in shifting market environments.

A macro example of staying relevant through the last four waves of new tech and how it changed a product might look like this: Banking current accounts (which is the product) used to be paper – paper money, paper cheques, paper records. Then computers came along but were only useful in branches for digitised records. Then the Internet came along so for current accounts to stay relevant their needed online banking so users could access their accounts at any time. The third tech wave was Mobile, which made it so products could be used anywhere, required banking apps to ensure the current account stayed relevant. AI will make it so products are used without the user needing to take action. Throughout those waves of tech innovation, the product stayed relevant by becoming easier (to use anytime anywhere), cheaper (less investment of money and time) and faster (time-to-value).

I might write up some thoughts on how to assess a product strategy based on its relevance. Maybe some kind of scoring system against the three high-level jobs-to-be-done of easier, cheaper, faster.

I did:

Magic number

Three day week for me, which really messed with my sense of time. I thought Wednesday was Friday and next week was the week after. Anyway, this happened…

• Chatted about Domain Driven Design and Opportunity Space Mapping, which seem to work really well together. They give us a way to organise, understand and assess messy, overlapping parts of the organisation.
• Talked about ways product managers can expand their responsibilities and find learning opportunities; across a domain, complementary products and adjacent roles. Product is a generalist role and there are lots ways to get useful skills.
• Started thinking about how to write a business case for some new work. I’ll probably use my usual FOPP metrics (financial, outcomes, performance, and progress) along with our north star metric.
• Joined up three problems to one solution. I like it when that happens. It feels like we’re delivering more value than tackling each problem separately.
• Thought through the things I intend to work on for the rest of the year. I’m reviewing my annual objectives soon so I want to have formed a position on whether I should be measured on outputs, outcomes, behaviours, growth, etc.

I read/listened to:

Product in service

Read Scott Colfer’s new book about what product management looks like in large, often non-commercial, organisations. There’s a lot to agree with. I’m a longstanding believer in the product management role being highly contextual and that applying product thinking is more important than “doing product management.”

Structure and social skills

Interesting podcast challenging Tuckman’s model for forming teams and concluding that it doesn’t really work. Instead, to be successful, teams need the right structure and the social skills to work together.

From Feature Factory to Finance Fluency: How I Learned to Speak CFO

“Executives aren’t against our ideas; they just can’t hear them when we speak in features instead of finance.” I completely agree product managers should be thinking and taking about business objectives such as income and cost, but I can’t help thinking that the other side of the problem is the attitude and approach of leadership towards product managers. When leaders believe their job is to do all the thinking (including understand the financials) and just give product managers features to build, then it’s not surprising that’s the language product managers speak back to them.

Software as signs

“The software your organisation produces is a product of and a reflection of how your organisation operates, as well as its beliefs and values.” I guess that makes software a lagging indicator of culture (just as conversation is leading indicator of culture). I wonder how you’d go about assessing an organisation’s software and what conclusions you’d reach about their culture.

Delivering successful AI after it breaks your existing operational model

I love Sarah’s perspective. She suggests our current product delivery model is outdated as it’s designed for deterministic software not nondeterminisitic, probabilistic systems like GenAI. I’m not sure more controls is the answer but it poses an interesting question to ponder… what would a nondeterminisitic product development process look like?

I thought:

Layers

An architect told me about how they have the idea of Layers. Made me wonder if we can think of products in a similar way, with an interface layer, an action layer, an outcome layer, etc. And that made me think about James Reason’s idea of Swiss cheese layers where failure is because the holes in layers line up.

Do as AI say not as AI do

There are some interesting hypocrisies in organisation’s position on AI. They want to use it to their advantage but don’t want others to use it in ways that disadvantage them.

A few months ago, Shopify CEO Tobi Lütke stated that staff had to prove a job couldn’t be done by AI before it can be filled by a person. This week, Spotify published their position on AI music on their platform and launched tools to stop it because people are using AI in ways that undermine their business model.

And in hiring, organisations don’t want candidates to use AI to apply for jobs, but they’re happy to use AI to screen CV’s and they want their staff to use AI in their day-to-day work.

I did:

• Picked up my new laptop.
• Talked about workload management and how we think about what is worth doing.
• Wrote up my thinking on using test and control groups to improve the robustness of financial contribution reporting. I love this kind of critical thinking.
• Chatted about Domain Driven Design, architecture, mapping tech stacks and change implications. Although I’m a firm believer that product management isn’t about the technology, it’s also not much without the technology.
• Got involved in ‘a rock and a hard place’ problem. No viable solutions have presented themselves yet.

Success state roadmap

There is no single roadmap template that covers every part of the product development lifecycle. How weird is that? Now/Next/Later roadmaps are for discovery, and Gannt-type charts are usually used for delivery, and there’s no format for aligning around success.

So I wrote about success state roadmaps and how they show us whether our strategy is leading to a successful product. And I also got a mention in one of Paul Brown’s articles.

I saw:

Look up

I saw the International Space Station and the President of the United States. I’ll let you decide which one was more impressive.

I read/watched:

AI and Product Management: Becoming More Evidence-Guided

“AI’s biggest promise is not in accelerating the way we work today, but in helping us switch to evidence-guided, discovery-driven work.” This is a step forward in the AI as a tool for product managers thinking as it suggests AI can make it easier to do some of the things that are currently hard to do.

The future of product management

Notes on Notes from Ray Wang’s talk at INDUSTRY 2025:

• Companies that build AI-first business models will outperform the market 10 to 1
• The job as a product manager involves collecting data and monetizing that data.
• Realization that there is not enough data to get to a level for stakeholders to trust… and the need to pool data by industry value chains and build partnerships for data.

Digital-era healthcare

I read James Plunkett’s piece on digital-era healthcare and James Higgott’s responses, particularly his point about hierarchical power structures and the ‘do as I say’ culture at the NHS. I’d take what James Higgott says a level deeper and say the big problem with the NHS is that the wrong people have the power.

If digital is about anything, it’s about disrupting power structures. That’s what being user-centred is about. It’s how many of the early Internet products and companies succeeded. So, if the NHS wants to become a digital-era organisation it needs to drastically disrupt its own power structures.

Doctors know they have all the power. They know they are protected from complaint by the patient advice and liaison service. As a carer, I’ve seen it first hand many times. NHS staff making decisions that aren’t in the best interests of their patient and knowing there is nothing patients can do about it.

For the NHS to really change, it needs to fundamentally change the relationship between NHS staff and patients. It needs to put patient power first.

Intentionality FTW

Watched John Cutler describing the journey of how Dotwork figured out mapping product operating systems. Interesting as always. It’s really hard to know how much company operating systems, product operating models, etc., make a difference to the success of the products and organisations. One thing’s for sure, there’s no perfect answer. But I always go back to the question, “What are we optimising for?”

I thought:

Conveyor belts and mazes

Fundamentally conceptually, most products are conveyor belts. Their primary purpose is to take users from one state to another. It’s like I’ve said before, products don’t achieve outcomes, products change user’s behaviours and it’s that change that achieves an outcome (it’s why outcomes are unpredictable). And moving users along the conveyor belt is how those products change behaviour.

The problem with conveyor belt products is they are follow an industrial-age, mechanistic worldview that doesn’t fit our understanding of the world as a complex system.

So far, the only alternative to conveyor belts is mazes. These are products that are designed to keep you in the same state for as long as possible. Their definition of outcome is that user behaviour is changed in more predictable ways and then maintained for as long as possible.

The problem with maze products is they rely on algorithms, and we haven’t yet learned (or don’t want to because capitalism) how to make algorithms that don’t create negative spirals of doom (yeah, I’m talking about social media).

When I see thought-leaders complaining about LinkedIn’s algorithm not showing their super insightful posts to enough people, I think they are confusing a maze product with a conveyor belt product. They expect LinkedIn to help them get somewhere when really LinkedIn just wants to keep them posting.

Fixed and variable value

If you’ve ever done any business cost analysis you’ll know that variable costs change with the amount a business you do and fixed costs stay the same not matter how much business you do. I wonder if the same thinking applies to value. So, legal compliance, security, etc., are fixed value. An organisation needs them whether they have a thousand or a million users. The value (however you might define it) stays the same. Product, on the other hand, is variable value. The more users behaving in ways that drive business results, the more value is created.

Cost calculator for automation

I’ve been wondering how to quantify the question of whether its worth automating a process?

Maybe the calculation looks something like this: (Upfront cost of setting up automation + ongoing cost, e.g., licenses, monitoring, etc.) <> (Time cost of doing it manually x number of times action undertaken – value of what could be done instead) = Yes or no.

The evolution of the digital product

At first, ‘digital product’ meant a product that used technology (software). Then, the Internet came about and a ‘digital product’ became one that used technology and data to create and exchange value. Now, a ‘digital product’ uses technology, data, and artificial intelligence. This gives us a way to think about AI as using data in value-generating ways that weren’t previously possible. Soon enough, technology, data and AI will be the usual for digital products and whatever is next will be at the frontier.

I did:

Out of office

I’m pretty much always out of office because it’s the twenty-first century and I work for an organisation that’s smart enough to value remote and hybrid working, but this week I was also on leave. That means time for thinking about:

• What’s the difference between an internal product team and a platform team?
• What should be in an opportunity space mapping workshop? Or to put it another way, where does opportunity work end – is it with it mapped, on a roadmap for exploration, plus techniques for exploring, annnnd decision-making and reporting?
• How could impact mapping be made easier to work with so the logic of inputs to activities to outputs to outcomes to impact makes sense more quickly?

I read:

Responding to change

Interesting thoughts from Ian on teams being more intentional about the type of change they are using. Tacking is about knowing where you want to get to and course correcting along the way. Exploring is used to figure out your terrain and where you want to go. And following a plan for what and when to change on your way to a predetermined destination is the third approach.

Domain Driven Design

I read a few different things on domain driven design in preparation for some architectural discussions next week. Can’t say I’ve got my head around it yet but I can see how it will be helpful, mostly around how to organize large domains into a network of Bounded Contexts.

Techno-solutionism in education

Why does education keep falling for techno-solutionism, despite the fact that technology does not seem to drastically improve education? If you want my opinion, it’s the money. Big consultancies push technological solutions because they can be seen to have delivered something for their money, big tech companies push technological solutions because that’s how they make their money, leaders technological solutions because it gives them something tangible to ask for money for and stay relevant.

unFIXing Your Organization With LeSS

I can see how there could maybe be a case for organising in this way if there is a large number of teams all working on the same codebase and product. But in organisations that are smart enough to organise teams and products to be independent, the entire premise falls over.

I thought:

Think big, start small, learn fast

Six words to live by. A generally applicable approach to most situations of uncertainty where you have/want an ambitious goal and need to figure out the way forward by trying things. I don’t know if Chunka Mui came up with it or just got associated with/popularised it, but I’m grateful as it has been a guiding constant for many years.

Impact mapping metrics

I like impact mapping. It’s one of my favourite planning techniques but I don’t use it anywhere near enough. I was thinking about how you could add metrics to each of the five levels to understand how they relate to each other. Here’s a really rough example:

1. Impact: Increase revenue by £3 million in one year.
2. Outcomes: 50% of new users reach their aha moment in less than 2 hours = £1 million | Cohort of 1 to 5 days uses login more than 3 times = £0.5 million | Cohort of 6 to 15 days generate 1 report = £1.5 million.
3. Outputs: Smoother onboarding process | Notification emails | Report templates and view-only access.
4. Activities: Experiment and redesign changes for the onboarding process | Email trigger logic and new email content | Design templates, develop view-only sharing URLs, implement instrumentation.
5. Inputs: £1 million team including designer, developers, product manager, tool licenses, etc.

If this was a diagram you’d see how each of the things on each level connect to other levels, but more importantly, you can see the team’s hypothesis for how they’re going to achieve impact in the outcomes, which helps them to focus on which outputs to deliver, which helps them decide which activities to do when. And, you can easily calculate the ROI of the team, and make adjustments such as investing more or less in the team, increasing or reducing time, etc.

University products

More rambling, connecting thoughts on defining products in universities (although it probably works in other types of orgs). It goes like this… products are the things the university provides, not the things provided to the university by IT or digital services teams (Couzens)… and we figure out what our products are by applying the business thinking of bundling and unbundling (Barksdale)… because universities are a big interconnected bundle of lots of things (it’s part of what makes them so difficult to disrupt from an innovation point of view (Christensen))… so if we were to unbundle it (we’re not, it’s just a conceptual exercise), we’d break off each business capability so that we can invest in it individually to create core competencies (Prahalad and Hamel) and we’d call them products… each would provide significant value to students, would enable the university to differentiate itself, and would have longevity that it means it can change and improve in ways that make it difficult to copy. Those products would include: Prepare to study (onboarding), Help & support, Library, Careers, Community, and many many more.