Weeknotes 408

This week I did:

Only three days?

I had two days off this week, and one of the days I was at work was spent at an event, so there was a lot to make progress on in a short period of time.

  • Went to a Salesforce Education event. Two thoughts; lots of universities are using the same tech but each in completely unique ways, and how the big tech strategy of creating lock-in is being used in that space.
  • Apologised for shutting down and talking over a colleague. I don’t know what I was thinking, but I don’t expect that kind of behaviour from anyone else so I don’t accept it from myself. I’ll do better.
  • Wrote up the retro I ran last week. I like writing up retros more than I like running them. The process of synthesising the points people discussed into themes, building a mental model around using what the team is good at to overcome the challenges, and creating actions for people to own just fits how my brain works.
  • Ran a session to come up with some prioritisation criteria and apply them to decide what we should work on next. Amazing what you can achieve in a 25 minute meeting when everyone is focused.
  • Had a fascinating chat about measurement and reporting. It was only afterwards that I started to realise that we were coming at the conversation from different points-of-view, and it was thanks to a point Teresa Torres made on a podcast. She said something along the lines of continuous discovery and business research not needing the same degree of reliability and validity as academic research.
  • Did some prep work for a service designer to join the team. I’m really looking forward to this and have high hopes for us bringing more user perspective and creating
  • Pivoted my approach to creating our roadmap. I’ve given up on my analytical approach of connecting opportunities to objectives and obstacles to provide rationale and am creating a quicker version. I’ll still be able to talk through the rationale, but we need something sooner so progress is more important than perfection.

Am I an unProduct person?

Jukesie’s post about being an unProduct person got me thinking. There’s lots of interesting stuff so I wrote a post questioning whether I’m an unProduct person.

Shuhari for product managers

I wrote a few, mostly incomprehensible notes (it was late at night), on shuhari for product managers. Having thought about it a bit more, I’m wondering if shuhari complements capability frameworks. Capability frameworks are about the skills product managers need, they are defined, have clear(ish) boxes around them. Shuhari is about the practice; it’s fluid, undefined and intangible. Together, they are a bit more holistic. (And, not to get too inception-y, but weeknotes are part of a reflective practice.)


Went to Silverstone to watch a friend racing. Can’t quite figure out why people do it. When I used to run mountainboarding events, the competition was just an excuse to bring the community together. But in motorsports there doesn’t seem to be any community. People turn up, do their thing, and go home. So why turn up at all?

I read:

The flow system

I started reading The Flow System. I’m of the opinion that the next step in the knowledge base of product management isn’t more frameworks and models, it’s in ways to make the existing frameworks and models fit together. I hope this book helps with that.

How to Be Kinder Sooner

This is a nice post by Kody Fintak and Tara Scott. It doesn’t really go anywhere other than the obvious, but I’m glad to see kindness showing up in software development circles.

The Behaviour Change Technique Ontology

This is amazing work on developing a Behaviour Change Technique Ontology. Behaviour change is so overlooked in product management but it’s so important for outcome-focused work where we define an outcome as a change in user behaviour. It always baffles me that the question of whether product managers should be technical or not comes up again and again, but no one seems to ask if product managers should understand psychology.

And I thought:

Why simplify

Simple things have greater explanatory power than complicated things. So, if we want people to understand more, we have to make things simple. But that definitely doesn’t mean taking things away, hiding or ignoring complexity, or reducing things. That doesn’t make them simpler, it just makes them less.

Philosophically, a simple thing has elegance – only has the parts it needs, and parsimony – all the parts are of the same type. So, when I try to make things simple, e.g. a roadmap (head, meet wall), I have to make sure it ticks those boxes and I don’t try to add stuff that breaks the elegance and parsimony.

Make things, develop people, make things happen

Thought more about Monozukuri, Hitozukuri and Kotozukuri as part of a theme around simplicity. Along with my three-word definitions, and breaking more rules as my practice goes through shuhari, I wondered if rather than specific frameworks and thinking tools, we should start work and teams with the three simplest things of a way to make things, a way to develop people, and a way to make things happen. And do it using plain English, which is another bee I’ve got in my bonnet at the moment.

Will it make the boat go faster?

In my ongoing attempts to help our team focus on the things that matter, I’ve been trying to come up with our own, “will it make the boat go faster” question. The closest I’ve come so far is, “Will it help students succeed?”. I need to test it our with people as at the moment, I know it won’t resonate as we aren’t user focused enough yet. But we’ll change that.

Thought leaders and inaccessibility

LinkedIn’s algorithm seems to amplify posts with images. So, if you’re someone trying to build an audience around your thought-leadership, you might be tempted to create images with text to widen the reach of what you’re putting out. But this isn’t very accessible. I don’t even consider myself disabled, but I use LinkedIn on my phone and have to do a lot of pinch zooming to read the text. It must be a lot harder for others. If you’re a leader that doesn’t care about accessibility, I don’t much care about your thoughts.

Weeknotes 407

This week I did:


Some of the things I did at work:

  • Wrote up a quick primer on simple product strategies with three elements; a worthwhile problem to solve, a hypothesis about how to solve it, and a way know if the problem has been solved. I might turn it into a blog post one day.
  • Ran a team retro. I used the sailboat method to help the team clarify where they want to get to (the desert island), what’s dragging them back (the anchors) and what pushes them forward (the wind). I felt really proud of how the team owned the solutions they came up with to use what they’re good at (the wind) to overcome the things that make it hard for them (the anchors).
  • Spent some time trying to figure out the optimum meeting schedule so that everyone has enough understanding of the work and enough time to do the work. The scheduling I mapped would have a person spending 40% of their time in meetings, which is probably too much, even when the meetings are the work.
  • Met our marketing director and chatted about ambition and vision. I really appreciated the clarity around the team’s mission, and its scale and pace.
  • Chatted about how hard it is to find a fixed point to anchor a roadmap to and give the team some certainty when so much is in flux.
  • Presented our OKR’s. And got some feedback about ours being different to everyone else’s which I’m choosing to take as a positive.
  • Had an interesting discussion about whether understanding the language used in agile and user-centred design is a sign of digital maturity. My opinion is that there is nothing that can’t be explained in plain English that is better explained by jargon. Jargon isn’t a signal of maturity, it’s exclusionary, and we don’t have to leave anyone behind. I might be in the minority, but Einstein agrees. He said, “If you can’t explain it simply, you don’t understand it well enough.”

I sometimes don’t quite believe I get paid to do all this cool stuff, tackle complex problems and make things better for people.


Completed 50 tasks.

Wrote 31 pages of notes.

Spoke to 37 people 83 times.

One of my annual goals is to speak to more people, and it’s going well. More by accident than design, but I don’t mind that. Looking forward to more chats with interesting people outside of work over the next few weeks.

The timeline of digital work

I’ve been adding influential management thinkers and their books to the timeline. It’s a bit annoying that I can’t find full dates for when the books were published so I have to set the dates as 1 Jan whatever the year. Obvious I guess for this kind of thing, but the hardest part is deciding what things to add from the past couple of years as we don’t know what affect they’ll have on modern work.

I read/listened/watched

Understanding continuous discovery

I’ve been listening to a few podcasts with Teresa Torres about continuous discovery, including this one from Aug 2021. More discovery to help product managers understanding worthwhile problems and get out of the project/delivery space is definitely on my mind for stuff we need to be doing so I want to start figuring out how it might work in our context sooner rather than later.

The microfoundations of lean leadership

This beautiful paper investigates the microfoundations of lean leadership using the Japanese philosophical concepts of Monozukuri (making things), Hitozukuri (developing people), and Kotozukuri (making things happen). It provides empirical evidence that lean should be seen as a human learning system and reinforces the Toyota perspective of ‘we make people before we make cars’. More of this type of leadership please.

Plan less, more often

Planning, i.e. determining what to do, is useful – but this should be done with a strict focus on what is the simplest, useful thing that we could do next; or, what is the absolute minimum we should do next?”

How to show the ROI of your product work

And I thought:

Impact mapping

Thought a lot about impact mapping and measuring this week. Just happened to be wandering around Watford at midnight so could let my mind wander like in the good ol’ days. My thoughts went from systems thinking, fox and rabbits, measuring impact via indirect signals (e.g., an increase in the rabbit population might show a decrease in the fox population), to littering and how Keep Britain Tidy had to affect numerous systems (legal to make it against the law to drop litter, local authorities to get litter bins installed, social pressures and public perception to make it unacceptable to drop litter, etc.), to how system-shifting product managers might show impact as a contribution to big changes in society. Maybe one day this will all make sense.

Intelligent waiting

One of the hardest management lessons I had to learn (again and again) was not jumping in to provide answers. Before acting, pause to think about what you want to achieve, how you might best achieve it, what could go wrong, what’s the bigger picture, then act, or in many cases, don’t. It gets easier (and by that I mean more comfortable) with practice and by reminding myself that I’ve only learned the lessons I’ve learned because others didn’t jump in and give me the answers.

The purist and the pragmatist

Had a few conversations this week about tools and methods (OKRs, problem/solution tree, impact mapping) that have a purist perspective about how they should best be used, and a pragmatist perspective on how well they can actually be adopted. There’s a value equation there where getting a method adopted in a pragmatic way gives enough value without too much investment, and the extra investment to get to the purist state probably isn’t worth it. Product manager-y thing to say, I know, but it’s important to stay focused on what problem the method or tool is solving for you.

Weeknotes 406

Weeknotes 406

This week I did:


It felt like another high-energy week of understanding how things connect and creating new connections.

I’ve been preparing for a retro next week where I’m using the sailboat. It’s prompted me to think about my own sun, wind, rocks, anchors and the island I’m trying to get to.

Talked about:

  • Architectural Decision Records and how knowing why decisions were made is as important as knowing what decision was made.
  • Asynchronous working.
  • How work flows from goals to roadmap to delivery plan to backlog, getting more specific with each step, and then how it flows to users.
  • Finding the right cadence for feedback loops for helping people unblock their work. Shorter loops are better but it means having lots of them to deal with at the same time.
  • The opportunity cost of not focusing on the most impactful work because admin and other people’s deadlines get in the way.


Completed 46 tasks, averaging 11.5 a day (four day week).

Wrote 22 pages of notes.

Spoke to 32 people.

I read:

How to communicate the value of your work to the right people

This wonderful, thoughtful article by Nia Campbell on how communicate your work shares reflections like asking people from across your organisation, who have valuable insights about stakeholders, to suggest ways of making communications work well.

Lectures on Lean-Agile Product Management

Jez Humble’s Lectures on Lean-Agile Product Management are a great video course for product managers. And I am in no way jealous that he has a .pm domain when mine was taken off me, not in the slightest.

Courage I aspire to

Ann’s weeknotes are so open and honest, they are an inspiration.

Designing culture

The eat sleep work repeat podcast has an interesting episode on using a product design approach to design culture. I mean, it’s wrong, but it’s interesting to think about why it’s wrong. Maybe it’s about agency and choices to engage. The user of a product has no choice, they have to use the product as it was designed. A team member can choose what parts of team culture they want to engage with, and they can create their own culture, and multiple cultures can co-exist, and they affect each other, and unintentional change emerges. You can’t design culture.

The Post-Individual

I found this fascinating. I’ve thought for a long time that our concept of the individual is one of the biggest factors for explaining the state of our society. Another, even deeper one, I’ve been pondering is what affect us being the only human species. What difference would there being multiple human species have made to the development of our society? Would we have screwed up the planet if weren’t so certain of our unique superiority… or so alone…

And I thought about:

Pretty sure Maya Angelou said this

“I’ve learned that people will forget what you said in meetings, people will forget what you did in meetings, but people will never forget how you made them feel in meetings.”

What we turn to for certainty

Books, documentation, resource repositories, storing everything in one place, roadmaps, backlogs, writing weeknotes… false certainty, I tell you!

It’s a dogs life

Snuffling is good for dog’s mental health. Watch them. They get completely absorbed by what they’re doing. This is good life lesson – do more of what absorbs you.

Weeknotes 405

This week I did:


I’ve been roadmappin’ (you have to say that as if you’re singing this song, it’s the law). I’m using the four O’s of objectives (what we’re trying to achieve), obstacles (the things that get in our way, from technical constraints to policy changes), opportunities (things we could do that achieve the objectives by tackling or avoiding the obstacles, and which go into delivery planning), and outcomes (where we measure changes in user behaviour to help us understand if we picked the right opportunities). Once I’ve got it set up and making sense I’ll share it with others and check the logic behind how it works before we fill it in.

Other things that happened this week:

  • I learned that we have over 2 million unique user journeys.
  • We did a Team Onion exercise which is going to help us clarify our mental model of who’s involved and how without having everyone listed in a RACI.
  • Learned a bit about the AI work we’re doing.
  • I’ve been invited to run a retro for a team. I feel quite touched that they asked me. I hope I do a good job for them.


I completed 58 tasks, an average of 11.6 a day.

Wrote 27 pages of notes.

Spoke to 34 people.

Graph showing the number of people I spoke to and how many times I spoke to them.

Product leaders chat

You know that saying that if you’re the smartest in the room, you’re in the wrong room? Well, this week I found myself the least smartest, least experienced person in a room when I joined Herd’s product leaders chat. We talked about programmes and products (actually they talked, I listened). It left me with a lot of think about. What is programme thinking? How does it compare to product thinking? But mostly, why is it that so much product talk is really about organisational design and dynamics?

All my books

I’ve been meaning to catalogue all my books for a while now, but this week I finally started. I’m up to 58 so far with quite a few more to add.

I read:

Investigating the Central Claim of Agility — Does Frequent Delivery Create More Value?

This article concludes that the combination learning and working on right-sizing items is 13–14 times better at producing value than a system with Large Items.

How to Right-Size Your Stories for Better Predictability

Interesting post about predicting when work will be delivered by right-sizing the work.

Magpie metrics

The WB-40 podcast talks to Richard Clarke about the role that happiness has in high-performing teams.

I call it magpie metrics. One sorrow, two for joy. Where are you on the scale?

A scale with one magpie at one end for sorrow and two magpies for joy.

A leader’s job

This quote was shared with me.

A leader’s job is to manage energy… first in themselves and then in the rest of their organisation.

Professor Emeritus Jim Clawson

And I thought:

Good meetings

Most of the stuff you read about making meetings better says clear agendas are the answer. That’s not what I think. The best meetings I’ve been to have three things in common; good flow, good facilitation and good follow-up. A sense of flow helps people get absorbed in meeting. A good facilitator doesn’t stick to pre-fixed agenda, they help everyone get what they need from the meeting. And good follow-up scales the impact of the meeting by spreading knowledge and ensuring action.

S-shaped people

T-shaped people are great but really we need S-shaped people. T-shaped people have a broad range of shallow skills along with a deep specialist skill. That’s fine, but we need people who aren’t defined and constrained by their fixed skill sets. We need people who are curious, who explore new things, develop new skills. We need people who meander through knowledge, who snake their way into interesting ideas and connect them with other things.

Product managers are scientists not detectives

Someone said product managers are like detectives. They shouldn’t be. Detectives find out things someone else already knows. Scientists discover things no one knows yet. Product managers are scientists.

Weeknotes 404

This week I did:

Embracing uncertainty

If there’s a theme to these weeknotes then it’s probably something about embracing uncertainty and vagueness. Had a few chats about how we can’t wait for certainty but have to take steps into ambiguity and find our way as we go. I don’t think things will ever be as stable as they are today, so rather than making stability a prerequisite for progress

Among other things, I…

  • Began working on a roadmap (using my four O’s) to help us explore opportunities in different ways.
  • Attended another great team retro where we used problem trees to dig into some of the things we identified in our previous retro.
  • Dug into some architecture review work to try to understand how things work.
  • Lots of one-to-ones to get to know more people.
  • Couple of supportive leadership chats.


I completed 53 tasks, averaging 10.6 a day.

I had 23 hours of meetings.

I wrote 27 pages of notes.

I talked to 28 people.

Since starting tracking (three weeks ago) 38% of my tasks have been delivery related, 24% were about leading the team, and 15% were admin tasks.

I read:

How to think about Bets, Success Metrics, and Roadmapping

Read John Cutler’s book. To continue with a theme, John says in the introduction, “Words like “problem”, “solution”, “opportunity”, “project”, “epic”, “MVP”, “MLP”, and “story” fail to capture the nuance and complexity of product work.”

Making User Stories Work for You

This article comes from the perspective of user stories as placeholders for conversation, as a means to defer the detailed analysis of the work until right before it’s needed, which is the point in time when you know the most. So, a user story written upfront by one person and passed to another is really just requirements, however it’s formatted. The best user stories are written together and grow over time, answering questions as they come up.

Question Bank

Maze Design’s product research question bank.

Tacit knowledge

I’ve often said that information is only useful when it becomes knowledge, that people have to internalise informational artefacts (like user journeys and roadmaps). The SECI model of knowledge dimensions is the theory that explains what I mean.

And I thought:

Timeboxing versus flow

I’ve been questioning the use and benefits of sprints, especially if they don’t have fast feedback loops built in. For some types of work in some teams, more a focus on flow and being able to get absorbed in a particular problem seems better. Get the process out of the way of progress.


It’s tempting to try to define things in an attempt to make them simpler and clearer. Instead we should recognise the vagaries of human understanding. Maybe this temptation is a bit about our search for certainty, and we hope that definitions will give us that. I think a certain amount of vagueness is useful, it allows for different interpretations from different perspectives to all be equally right.

Managing domain redirects over time

Wouldn’t it be great if owning a domain during a certain period of time gave you control over redirects from links created during that time. Then, even if you stopped owning the domain, you can choose to either redirect links somewhere else or hand them over to the new owner.

Three word definition: delivery management

Came up for my first draft for a three word definition for delivery management: “Enabling team harmony”.

Weeknotes 403

This week I did:

Connecting things

It’s the second week in my new role and lots of things are starting to connect. This is mostly because of how generous people have been with their time and how open they’ve been, especially our team’s fantastic delivery manager. If, as I believe, a product is organisational resources packaged in a coherent and scalable way so user’s can get value from them, then a product manager’s job is to connect things in a way that creates coherence. This includes user experience, technology and data, and it includes people’s knowledge, organisational processes, etc., etc. One of the connecting things I caught myself thinking about was how the work we do on the product can provide development opportunities for people, which is probably a bit weird as I’m not their line manager. And I started developing a product strategy to help others understand how things connect.


Completed 52 tasks.

Wrote 41 pages of notes.

Spoke to 31 people. Including 12 intro chats with people I hadn’t met yet. The highlight of which was two high energy chats with service designers. That’s the way to end a week!

I read/watched:

Team Topologies

Started reading Team Topologies. I really don’t want to get into org-design stuff but it might be useful for figuring out some team stuff over the next few weeks.

More Marty

I’m still trying to understand Marty’s position on product management and the product operating model, so I watched some videos. I think, his premise is that for a small number of a certain type of organisation, the way he talks about doing product management creates a competitive advantage by decreasing ‘time to value’, and that advantage requires the product operating model of empowered teams doing continuous discovery, etc. So, the backlash of product managers against that definition of the product operating model misses the point. Achieving competitive advantage is what is important, and if you can do it without the modern product practices, then fine, but you’re more likely to achieve it if you use them. Perhaps the reason the product management community is so focused on the practices rather than the outcome is because we’re too focused on internal process.

Innovation isn’t disruptive

Ever since reading Schumpeter and realising that his opinions on innovation ideas like first-mover advantage were mostly a result of him trying to deal with the Great Depression, I’ve been very sceptical of that whole lineage of innovation thinking. So, it’s pretty satisfying to find out that Christensen’s ideas about disruptive innovation were mostly made up and not at all scientific. Jill Lapore reads her brilliant essay about disruptive innovation from 2014 on The Last Archive podcast.

And I thought about:

Write user stories together

I’ve written before about how user stories are boundary objects, and so the best user stories create understanding across different knowledge domains. So it follows that the best way to create user stories than span different domains of knowledge is for people with different knowledge to create them together. And the best way to do that is for those people to talk and write together.

My four O’s of simple strategy

  1. Objectives – What do we want to achieve?
  2. Obstacles – What gets in the way of us achieving it?
  3. Opportunities – What could we do to remove the obstacles?
  4. Outcomes – How will we know when we’ve achieved what we want to?

The long-term side effects of AI

I often wonder what the long-term side effects of AI might be on society. It could be things like a new paradigm for the field of statistics. And maybe, if we’re lucky, organisations investing in AI will realise they need to stop treating the humans like machines and invest in them as people.

Weeknotes 402

This week I did:

On a mission

It’s been a little while since I’ve been excited about my work. There’s good work to be done here supporting the teams and building products that help the Open University achieve it’s mission. I’ve got lots to learn, lots to figure out, and hopefully lot of fun to had.

Product Wiki

One of the things I do when I’m working on a product is create a wiki for it. Usually it’s just a single document when I put info, links notes about changes, etc. I’ve started one for the product I’m going to be working on and it’s already up to 9 pages. Not only is it useful to have everything in one place, but when someone asks “what do we mean by ‘product’?”, I say “everything in the wiki”. A product is the sum of vision and strategy, market research, user experience, security and data protection, testing, change and release management, training, roadmap, risks, governance, team values, etc., etc. Bundle up all that knowledge and expertise, put it out in the world for people to benefit from, and you’ve got a product.


Completed 36 tasks, an average of 7.2 a day.

Met 47 people.

Wrote 32 pages of notes.

Removed work apps from my phone. Not sure how I feel about this, I still have the habit of checking messages in my head but now I can’t do it.

Three reflections on ten years in charity product management

I wrote about my ten years as a charity product manager and three of the challenges for good product management in charities. Because I do occasionally finish blog posts.

I read:

Guiding principles

Excellent example of making principles actionable rather than vague sayings that no one knows what to do with. A behaviour change expert I worked with once said, always start with principles to guide you.

Tips for Creating a Good Strategy

I listened to Scott Colfer’s tips for creating a good strategy. And, because it seems to be doing the rounds again, read Martin Eriksson’s Your strategy (probably) sucks. I’m still of the opinion that, just like planning, strategizing is more useful than strategy.

And I thought about:

Industry vs discipline

I read a post on LinkedIn about how product leaders bring a way of thinking about problems that . I take the point it’s making about hiring, and how perhaps some organisations make the mistake of excluding people without industry experience, but I don’t think it holds true that being a good product leader is more valuable than industry experience.

The question, of course, is how does experience correlate with achieving outcomes? We can assume that a product leader who knows how to do things in the right way and has considerable industry experience which means they know what are the right things to do, has a successful combination of factors (assuming you aren’t specifically looking to disrupt an industry). But having one (in this case knowing the right way to do things) shouldn’t be an inherently better factor of success. I wonder if it’s a fallacy in thinking to assume that knowing the right way, being practiced in using frameworks, techniques and methods, is better (see below about shuhari).

Two-by-two matrix showing the outcomes of discipline and industry experience.

Learn by doing, very occasionally

I have a bit of a problem with capability frameworks. Product managers learn by doing, and yet so many things that product managers are expected to know are the kinds of things they might do only very occasionally. How does a product manager taking a single product through its lifecycle over a number of years get the reps in for things like market analysis, business cases, defining an MVP, develop a product strategy, etc.?

Common knowledge as a solution to the coordination problem

When everyone knows the same thing, everyone can make aligned decisions. When different people know different things, they make different decisions.

This is why communication is so important in modern (non- command and control) organisations. Without this tacit means of coordination, misalignment is inevitable.

More shuhari

Thought about shuhari some more (it’s been in my head for a few weeks). Criticising those at the shu stage is sure sign of being at the ha stage, just as focusing on techniques is a sure sign of being at the shu stage.

Weeknotes 401

This week I did:

I’ve started so I’ll probably never finish

I started writing a few blog posts that I’ll probably never finish.

The first is about a flexible, principle-based approach to being more agile using my three word definition of agile being about ‘uncovering better ways’ – so uncovering better ways to lead, uncovering better ways to work as a team, etc.

The second is about which narrative about AI you choose and how it will change over time. I guess it’s kind of like a Lindy effect thing where the longer AI is around the harder it is to push the narrative it’s just a bubble or that it’s an existential threat to humanity. Which means that over time, the narrative will trend towards the middle of AI being new tech, just like all the old new tech. Photocopiers changed the world too, ya know.

I read/listened to:

The Double-Edged Sword Of Diversity In Teams

The Liberators Podcast is back with a really interesting study on how diversity in teams affects team productivity. Some of the insights include diversity makes teams more productive when they do work that doesn’t depend on each other but less productive if they have to work together, because having diverse people in a team leads to more conflict. And leveraging the different perspectives diverse people bring to a team doesn’t happen by accident, it require intentional effort. There’s also an interesting part about psychology safety that says, if you want diverse teams (because it’s the morally right thing to do) then you need to create the psychological safety for that team to work effectively. Psychological safety and diversity go hand-in-hand.

The coaching habit

Started reading The coaching habit to help me get better at asking questions. I heard somewhere (forget where) someone say something about only learning when they’re listening, because when they’re talking they are saying things they already know. So, as I expect the next few weeks to demand a lot of listening, I want to try to make sure I’m hearing the right things.

AI Adoption: Sparking Digital Transformation in Nonprofits and Charities

I read this article because I wondered if it might have something insightful about AI being the catalyst for digital transformation. Sadly not. It says, “AI may represent a seismic shift for nonprofits that choose to embrace it, bringing not just another new tech tool, but a radical reimagining of how they operate, engage with their communities, and fulfill their missions”. Yes, it might. But then the article goes on to say, “AI holds immense potential for nonprofits to improve organizational efficiency and effectiveness. From automating administrative tasks to personalizing donor experiences, AI can revolutionize how charities operate.” I’m not sure automating admin tasks is quite the revolution the charity sector needs.

And I thought about:

Safe Bets

The Civic AI Observatory newsletter talks about the three AI projects from the UK Cabinet Office’s new Incubator for Artificial Intelligence. As the newsletter says, the use cases for AI seem like safe bets. They are all essentially, ‘search-and-summarise’ with a ‘human in the loop’ use cases to surface information buried in documents that no one would ever have the time to organise. They are turning unstructured data into structured data (I wonder if they organise the structured data or always just go back to the unstructured data for each query).

Anyway, as much as I believe in the ‘technology push’ approach to innovation, I’d really like to see the adoption plans and metrics for the three projects. I’m particularly interested in how much instruction people need before being able to get the most out of the tools – is it entirely intuitive or do people need to know how to write good prompts? What mental models to people bring to these kinds of AI tools – do they think of it as like Google search or more like live chat with a person?

Personally, my current thinking about AI adoption is that it’ll become ubiquitous behind the scenes for things like cyber security threat detection and extremely large data set analysis, but chat won’t be the next big interface that means everyone knows they are using AI everyday. So, it’s interesting to me that the incubator team have decided to go with three user-facing products that bring adoption challenges. But I’m sure they have great product people thinking about these things and how to turn the ‘tech push’ into ‘market pull’.

You can’t service design an organisation

Saw another LinkedIn post about using Service Design to design how organisations work. I realise I’m in the minority thinking that’s a bad idea, but that’s ok, I’m used to it. If we understand organisations as complex adaptive systems, then the idea that a successful organisation can be designed up front makes no sense. Creating an effective organisation demands a very different approach, one that’s much more about setting up ecosystems and experimenting the way forward.

Canary in the coalmine

Been thinking about this analogy quite a lot, partly because it’s used in articles about autistic people at work. I’m still not convinced it’s an entirely healthy analogy when the canary refers to a person because their job is to die in order to protect others. But, I do like the idea of looking for small signals which show bigger issues. Maybe the canaries don’t have to be people. Maybe they can be things like behaviour patterns in a team that change over time or a competitor launching a new product.

Weeknotes 400

This week I did:

Getting set up

I spent a bit of time getting my second brain spreadsheet set up for my new role at the Open University.

Three reflections on ten years in charity product management

I wrote about what I hope for product management in charities in the not too distant future. I believe technology has the potential to create change at scale for all kinds of wicked problems affecting the world, and I hope charities embrace the opportunities it provides. And I hope product managers are instrumental in helping charities understand this opportunity and make the most of it.

Chatted to Matt

I was Matt’s 154th coffee chat. We chatted about products, technology and online learning. Matt shared a perspective on feature adoption that I’ve never heard before. He said the reason products, especially enterprise products, have so many features that most people don’t use is because it only takes one or two users of that feature for it to become a must-have when comparing other products. The more times that occurs across lots of different people in the organisation, the harder it is to switch, so lots of mostly unused features have a lock-in effect.

I also got a mention in Matt’s weeknotes.


Did pretty well with keeping up with writing notes about my day, but they are just stuff I did at the moment rather than being usefully reflective, which is the aim. I’m also wondering whether including things I did and thought about in one post for the day is more useful than than posting each thing individually (given that posts have dates anyway).

I read:

Behavioural design

Interview with behavioural designer Rahel Kiss on designing interventions to achieve a target behaviour, which could be reducing waste contamination, increasing vaccine uptake or reducing online fraud.

Deceptive choice architecture and behavioral audits: A principles‐based approach

This article argues for a principles-based approach to creating a regulatory environment which reduces the economic harm caused by deceptive designs, while safeguarding the benefits of well-meaning behavioral insights, and proposes behavioral audits as a tool to support this approach. I like principles-based approaches.

The Art of Experimentation for Product Managers

Experimentation is a crucial component of product management, allowing product managers to test different ideas and approaches to identify the most effective solutions and gain valuable insights into their target audience. In this article, we will explore the art of experimentation for product managers, why it is important, how to do it effectively, and provide real logical examples to illustrate each method.

I thought about:

Applications by quill and parchment only please

Nick Scott posted on LinkedIn about Unicef advertising a job for a Senior Innovation Manager where the ad said that anyone using AI to help them write their application would be excluded from shortlisting. What a strange position to take for an innovation role. It tells potential candidates that the organisation can’t even innovate on their recruitment process to adapt to new technologies. They could have encouraged candidates to use AI and talk through what they learned in the interview. It’s just one example of how behind the charity sector is when it comes to digital transformation and making the most of emerging technology.

Discovering worthwhile problems

I have a thing about getting to the simplest definition of complicated things. My three word definition of product management is ‘discovering worthwhile problems’. I think that speaks to what product managers should be uniquely focused on and the value they bring. ‘Discovering’, because these things aren’t known yet and need to be found. ‘Worthwhile’, because there needs to be a focus on value. ‘Problems’, because product managers should be more concerned with the problem space more than solutions.

What we get wrong about retros

Retrospectives are only a bit about reflecting and continuous improvement, but they are much more about connecting and sense-making. I’m a big believer in reflective practice. Thinking about what has happened to help us decide what to do in the future is essential in digital work. But retros have a more important role than creating these learning loops, they should help the team make sense of their work by connecting the cause and effect of what went well and what didn’t. Understanding the present is more important than making changes in the future.

Weeknotes 399

This week I did:

A little knowledge goes a long way

I attended a fantastic playback of some user research. The insights it revealed were pretty powerful. If there are any arguments against speaking to users, or things like ‘were the right questions asked’, ‘was it with the right people’, etc., they all go away when you realise that you didn’t really know anything before you spoke to some users, so at least now you know something.


I did much better writing daynotes this week. Daynotes are much more raw than weeknotes. There’s less reflection and more collection. Less refinement and more brain dump.

Psychological safety stickers

Psychological safety stickers

Ten years in charity product management

I wrote a bit more on my reflections on my ten years as a product manager in charities. Some of the themes include ‘no one knows what product managers do’ (good and bad), ‘product management is too inwardly focused’ (probably bad), and ‘no one (not even product managers) know how to build products to tackle wicked problems’ (good, because that’s the future). Hopefully I can actually finish it soon.

I read:

What Makes People Act on Climate Change

Copying others, basically. Behavioural science says that conforming to social norms is the biggest driver of change. I’ve said a few times that product managers need to know more about behaviour change techniques than they do about technology. Understanding social norms around using products helps product managers create products that tap into norms.

Process-expert continuum

I think Matt Ballantine’s process-expert continuum, which describes the spectrum of approaches consultants take, could be applied to lots of other things. Being a manager of someone springs to mind. It also spans from ambiguity and supporting the person to figure their way through problems to providing specific answers and completing known tasks. In this case, the manager slides back and forth along the continuum depends on the needs of the person they are managing.

What’s holding us back? Why not-for-profits are struggling to be fit for purpose in the digital age

How 12 charity digital thinkers and leaders, surfaced the big problems stifling non-profits ability to thrive in the internet era. But didn’t include the biggest reason why charities are so far behind in digital transformation; there just isn’t a big enough threat to their existence for which digital is the solution. Back in the pandemic, digital was the solution. For many charities, it was the only solution for how to carry on delivering services. But now, there’s nothing that makes digital the solution, so there’s no reason to transform.

I thought about:


Principle are so easy to write and never put into practice. That’s not surprising when most principles seem to be written to look good rather than drive good behaviours. I believe in principles, but have also struggled to explain how they are actually useful. But the mathematics of chaos provided the answer. It shows that in nature, simple rules can produce complex behaviour. Rather than principles being aspirational but a bit meaningless, like “Design for inclusion”, principles should be treated as simple rules that can create complex behaviour. One of my favourites is “Talk to each other”. As a rule, it suggests defaulting to communication, to working collaboratively, to asking for help. It tells you what to do without telling you what to do.


“A ratchet is any mechanism that allows progressive movement in one direction and prevents slippage backwards.” That is the secret to designed organisational change; progress that can’t slip backwards. So many attempts to change fail because they they don’t build in ratchet mechanisms. There are many such mechanisms, some obvious, some more subtle. Staff retention is one, because when someone leaves a new person joins and wants to change things to do them their way, and that takes time and creates change. There are lots of ratchets in organisations, and if we want change to stick we have to use them well.