Category: Weeknotes

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.

Productivity

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.

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.

Productivity

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

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.

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.

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.

Daynotes

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.

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.

Daynotes

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

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:

Principles

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.

Ratchets

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

This week I did:

Handover

The main thing I’ve been doing this week is writing handover notes. It’s been interesting looking back all the different things I’ve worked on over the last couple of years. I have thirty-five different things so far, and more still to add. Working on so many different things is one of the things I’ve loved about working in charities. I’ve been lucky to learn so much so quickly. Of course, the downside is that not all the work gets finished. If I had time I’d plot the work from most to least impactful and reflect on what it was about work that made it effective. But I doubt I’ll have the time.

Daynotes

Tried to give my daynotes more focus but only managed one and a half days. I researched a few different templates, and will keep experimenting as I think it’s a really useful to reflect on a short time span like one day. The challenge is it not becoming just documentation of what I did but something actually useful for reflection.

Product community

One of my objectives this year is to connect with more people, so I joined the Product-led Alliance Slack group and I’ve booked a chat with someone I’ve never met before. Not quite sure what I’m trying to achieve but I’ve gotten so much from speaking to more people within the org that I want to see if it also works outside.

I watched/read:

Unphased: Reimaging Public Sector Digital Delivery

Brave presentation from Ben Whitfield-Heap. He talks about moving away from DABL phases for product development, which is obviously a good idea. But I can’t help thinking that this phased process exists to meet the needs of those outside of the project team, not the project team or the users. Been there, done that. But anyway, yeah continuous everything!

Transformed

The product thought leaders (Jason Yip, Dan Olsen, etc.) have been having their say about what Marty Cagan said on Lenny’s podcast about his new book. I’m not sure I understand why it’s gotten such a reaction given it’s a pretty well-established point-of-view. Maybe it’s just a chance to have something to say.

Value stream mapping

The value stream is the product.

And I thought about:

Project methodology argument

Saw a few different discussions going on about the differences between predictive project methodology (AKA waterfall) and an adaptive methodology (AKA agile). The funny thing about this is how the perspective is as if those are the only two options. It completely ignores all the “projects” that don’t follow any methodology. I’ve tried to think of a term to describe this and the best I’ve come up with so far is ‘constructive’, as in constructing the methodology as the project progresses or making it up as you go along. I want to try to figure out the right criteria for defining each but it’ll be a spectrum rather than a boundary.

Outcomes over outputs is unhelpful

Anything that sets up one thing in opposition to another is generally unhelpful for creating change. Outcomes over outputs is one of those things. It creates anxieties about the outputs; we still need them delivered so who is going to do that if product managers have their head in the clouds thinking about outcomes? Actually, product managers need to be concerned with impact, outcomes, outputs, activities and inputs. And they need to join them up coherently so that the inputs invested are right for achieving the impact. Might write a blog post about this one day.

Tyre fitting

I chatted to the workshop manager at a car garage about how he manages the flow of work. They fit an average of 30 tyres a day but have done as many as 50 in a day. The two biggest causes of delay are the warehouse sending the wrong items and the mechanics finding more things that need to be fixed on a car. Whatever they do to plan and predict work gets disrupted if these things happen. Then, other work scheduled gets delayed and they have to work faster to get back on schedule. Both delays are stressful for the workshop manager, but are very different to the company as the first costs them and the second makes them money.

This week I did:

Meeting of minds

Really enjoyed working with a couple of awesome colleagues on some recruitment. It was amazing to see the coming together of different minds, exploring different perspectives on what we wanted to know about candidates, and what interview questions would give them the opportunity to show themselves at their best. This is why everyone is always more than their job title. It’s both a high bar and no bar at all for the new recruit.

Productivity

33 tasks completed over 5 days, averages 6.6 a day. It’s like the old days of productivity before my new system optimised me.

Achieved 30% of my weekly goals.

I had 45 interactions with 24 people.

Experiencing digital transformation in health care

In a doctor’s surgery earlier this week I spotted a poster about the surgery’s new chatbot. I got my phone out, scanned the QR code and opened the chatbot. I was slightly relieved to see it was an old type chatbot with buttons (I think this type of chatbot is going to see a resurgence soon) rather than the large language model type. The chatbot lets you choose from a few options.

If you want to access your GP heath records, the chatbot tells you to download the NHS App. If you want to book an appointment, the chatbot tells you to download the AskFirst App. If you want to check if your prescription is ready, the chatbot tells you to call your pharmacy. So, if you were expecting the chatbot to be able to do these things for you, which is a reasonable assumption, then you’re probably going to get pretty frustrated. If you knew ahead of the chat that its purpose is purely signposting, then you might find it useful.

A few days later, I saw this poster in a hospital. An innovative approach to using new technology, communicated using old fashioned paper.

And then I read Dr Sarah Knowles’ post about the Chancellor announcing more money for ‘Digital Transformation’, providing another example. Perhaps Sarah’s example is less about the tech and more about how shiny new things get investment but boring old things don’t, but it’s all around a theme of digital transformation’s bad reputation.

So maybe it’s an expectation problem. We expect technology to just work, for things to be connected. But transformation isn’t evenly distributed. Sometimes it works, sometimes it doesn’t. And almost never for everyone, that’s what makes it so difficult. Photocopiers were transformations once.

I read:

Boiling frogs

Nick Scott wrote about how the charity sector doesn’t have a burning platform to force it to adopt more internet-era ways of working, digital business models. He says, “I worry society is moving faster than our sector, putting our current and future strength and impact at risk.” I agree.

Why aren’t non-profits invested in digital transformation?

And Digital Leadership wrote about why non-profits are falling behind with digital transformation. Although I don’t agree with the definition of digital transformation, I think it’s too internal looking and misses transforming entire business models, but “an equation that shows how transforming people and processes maximises the impact of technological change” is an interesting idea.

System-Shifting Design: An emerging practice explored

I still believe that system-shifting product management is required to sit alongside system-shifting design.

Why aren’t non-profits invested in digital transformation?

And Digital Leadership wrote about why non-profits are falling behind with digital transformation. Although I don’t agree with the definition of digital transformation, I think it’s too internal looking and misses transforming entire business models, but “an equation that shows how transforming people and processes maximises the impact of technological change” is an interesting idea.

System-Shifting Design: An emerging practice explored

I still believe that system-shifting product management is required to sit alongside system-shifting design.

AI resources

Resources from the National Centre for AI.

And I thought:

Aren’t user stories great

I don’t use user stories nearly enough. But I think they are/can be great. When used as boundary objects (rather than following a fixed format) they allow for deep understanding within different knowledge domains without having to go into the detailed specifics. That’s super powerful. Everyone looks at the same thing but they each see what matters to them, and they don’t need to know what others see because they trust them, and even if someone misunderstands it doesn’t matter because a user story is the smallest deliverable value so it’s easy to change.

Shu Ha Ri

I think Shu Ha Ri might offer a kind of roadmap for teams. They start with learning technique, then they find new approaches, then they move away from needing a structure to follow. But I think Shu might be the hardest part. Adopting and sticking to established technique long enough to learn from it rather than jumping to Ha isn’t easy.

This week I did:

Write stuff down

With four weeks to go in my current role, I’ve been focusing on finishing off whatever I can and writing handover notes for whatever I can’t. Luckily for me, I’ve religiously documented all the work I’ve done over the last two years so it’s more of a case of pulling all those documents and Miro boards together into a semi-comprehensive narrative. It’s been really interesting to look back at all the things I’ve worked on, which things have succeeded, and where things have failed, and what patterns have emerged.

Productivity

I completed 43 things this week, an average of 8.6 a day.

I completed 50% of this week’s goals, with (as usual) one goal completed fully, another progressed a bit and did very little for the third goal.

I had 51 interactions with 30 people.

After 7 months of tracking, I’ve completed 1498 tasks. One month left of this experiment before version 2, which will dive more into the theory of constraints and how doing tasks is essentially about removing blockers to enable the flow of value (I also need a refresher on the principles of kanban to help with this).

I read:

Is the A.I. ship sailing by the ‘social sector’, just like the digital ship did in the 90s!

I started reading Ed Howarth’s post on AI in the social sector wanting to agree. But I changed my mind. Ed says, “Don’t be led by the product, be led by what you want to achieve.” I think maybe it was this kind of thinking that prevented the social sector from realising the potential of digital in the 90’s and ever since.

Technology push is just as valid a driver of innovation as market pull. But if you only allow yourself to see the world from what you already know – your purpose, and how you think you can achieve it – then you severely limit your ability to explore new possibilities. Over the past couple of decades, the internet and digital has enabled entirely new business models that weren’t possible before and couldn’t be conceived of by people who didn’t understand just how different digital is to what went before. I think the same is probably true of AI. The charities that look at AI as, at best, a way to improve productivity won’t be able to imagine the completely new ways it might enable them to have an impact on the world. They will get left behind.

Ed finishes with the suggestion that social sector organisations experiment with AI. This I agree with, even if for most of them it probably means just starting to use it in unstructured ways rather than actually running experiments. But, for any charity that has a ten year vision which doesn’t recognise the impact of AI, the ship hasn’t just sailed, it’s already over the horizon.

The Product Kata

I was thinking about ways to establish and maintain a practice approach to product management and wondered how to apply an Improvement Kata approach, but of course Melissa Perri has already written about it.

Visualising Experiment Portfolios

Sam Rye shares a number of different ways we could visualise experiment portfolios, with the aim to spur discussion, surface promising angles to pursue, and perhaps identify existing tools which could deliver some / all of the main views. And of course, visual working FTW.

More resources and toolkits

• Reflection Toolkit
• Cross Gov resources

I thought about:

Delivery management

There are four ‘modes of organising’ for a team: coalition, coordination, cooperation and collaboration.

	Working separately	Working together
Different goals	Coordination	Cooperation
Same goals	Coalition	Collaboration

Each of the different modes is applicable in different situations, so none is better than another. But they do work very differently and have wider implications outside the team.

One of those implications I’ve been thinking about is, which modes can delivery management be effective, which does it not work, or which does it have to be adapted for?

We know delivery management can bring lots of benefits to teams working in a collaborative mode, that is, a true team of people working together on the same goal. Can true delivery management only be effective if the team is working together to achieve the different goals? Or, even more challenging, can it help where people are working separately on different goals? And is good delivery management essential to move teams from one mode to another?

Does start small work without think big?

Think big, start small, learn fast. That’s well known, and it makes sense. Thinking big helps you understand where you want to get to. Starting small helps you do something in the right direction. And learn fast helps you figure out whether you are heading in the right direction (and sometimes if the direction is right).

My question is, does starting small work if you haven’t thought big?

Matt Edgar says, “Starting work on anything without everyone having a shared understanding of the big picture is incredibly risky.” He goes on the say that the risk is around only a small number of leaders knowing the big picture, but there’s a tougher risk to tackle where no one knows what the big picture might look like. If no one has done the thinking and communicating about vision, direction, goals, etc., it seems really unlikely that starting small can be effective. Maybe you can start small and learn fast to help you think big and figure out the direction and ideally end state, but that would need to be really explicit for those working on it, and, to some degree, is thinking big. So, at the moment, until proven wrong, I think starting small without having thought big is a recipe for ineffective busy work.

Ten years in charity product management

I’ve been thinking back over my ten years as a product manager in the charity sector. I might try to write about my experience and where I think charity product management should go in the next ten years.

This week I did:

Whole problems

Spent some time pondering user adoption, arguably the hardest part of product management. It’s so easy to focus on the ‘thing’ and not the value the user gets from the ‘thing’. It’s obvious to say, but if you can’t solve one problem for one user in way they value, then you can’t really expect to solve more problems for more people in ways they’ll keep coming back to. And yet we (product managers) often fail to understand the user, their problems, or how to get them using our solution. We jump to the solution in isolation. I created just such a ‘thing’ this week. Ok, there’s a customer waiting for it, so there’s some validation there, but I have only the vaguest idea of what problem they are trying to solve or how they’ll use it and what impact it’ll have. Oh to have the time to tackle whole problems.

In the zone

Added a few more things to product management zone. It’ll either become the world’s biggest resource library for product management (next to Google and LLM’s) or just give me some cataloguing to focus on. I’ll let you guess which.

New art

One of the things on my goals for this year was to start another piece of conceptual art. You probably already know about Floors I’ve Walked On and Stiles.style, but I wanted something more virtual. So, spreadsheet art is it. I create images by colouring the cells of spreadsheets so they act like pixels. Over time, I’ll get better at it and make more complicated images but at the moment I’m more interested in playing with ideas around real/digital. My first piece is called “If static could sort itself out” and imagines what the static we used to see on old TV’s might look like if it arranged itself into a nice pattern.

I read:

The Universal Design File: Designing for People of All Ages and Abilities

Download and read this book about designing products to be usable to the greatest extent possible by people of all ages and abilities/disabilities. As usability is one of the four big product risks, understanding universal design is important for tackling that risk.

The effectiveness of nudging key learning resources to support online engagement in higher education courses

I’ve said before that product managers need to know more about human psychology than technology, and behaviour change techniques are an important part of that body of knowledge.

How to do monitoring and evaluation differently when working with complex systems challenges

This is a fascinating look at how monitoring and evaluation should help organisation working in complex system change to regularly learn and adapt, capture system-level change and track and report on intermediate progress.

Ready for a reset

NPC’s State of the Sector 2024 report explores the views of charity leaders, charity users, and the public on where charities are. One of the interesting insights is, “The proportion of charities who consulted their users rose from 60% in 2020 to 85% in 2023. However, the proportion of charities who say that users have a direct input into their strategy dropped from 71% to 62% over the same period, although this is not a statistically significant change. Charities need to ensure that user involvement does not become tokenistic.”

Knowledge management is more important than your repository

Creating tacit knowledge, things people ‘just know’, is the key to good knowledge management. Knowledge in people’s heads is infinitely more valuable than information in any tool.

I thought about:

Practice solving problems

Small problems that come up every day are an opportunity for teams to practice problem solving. Getting people together, talking to each other to understand the problem and agree the solution. Practicing on small problems helps teams get better at solving bigger problems.

Team metrics that matter

Speed matters for some teams. If you’re on an F1 pit stop crew, the time it takes to change tyres matters to you. That doesn’t mean speed matters to all teams, but it’s probably good for teams to know what matters to them. What’s their north star metric? What should they be optimising for? And if they don’t know, I’d suggest optimising for joy and measuring how much the team enjoy working together is a pretty good metric to start with.

This week I did:

Not very much

I was on leave, and apart from one small, but I feel justified, work thing, I managed to stay away from work. That doesn’t happen often, usually I work when on leave, but it gave me more time for thinking.

I read:

UK charity camp

Francis Bacon’s insightful reflections on the state of digital in the charity sector from Charity Camp shows how charities are struggling to use digital beyond fundraising, must work out how it will fund enduring digital services, and are not open or sharing enough. Sector-wide digital transformation looks like it’s becoming more and more of a challenge. Things are changing faster and the charity sector is falling further behind.

Joy of agility

I started ready Joshua Kerievsky’s Joy of agility. The thing I’m taking away most is that to be able to respond to change quickly takes lots of preparation and even more practice.

Team work is broken

Mural’s team work research says “66% of knowledge workers aren’t very happy with how their team works together.” They don’t have any answers (other than using their product, of course) but it’s a fascinating area organisations should be experimenting in.

Digital Innovation for Student Success: Research & Development Insights 23/24

This presentation about digital innovation for student success from King’s Collage, London talks about revitalising digital strategy by going from dead projects to living products and harnessing AI to enhance student success. It feels like a revealing slice of ‘where we are right now’ in the digital transformation of education.

Social learning systems and communities of practice

I’m a regular reader of Doug’s posts, but this one on social learning systems stood out as super interesting.

Why you need to fail

We should all make more mistake.

And I thought about:

The product problem for different sectors

The product problem facing higher education is clearer than that facing charities.

Charities tackle wicked problems and there isn’t (yet) the competitive impetus for digital transformation. So, not only is digital transformation not a pressing existential issue, it isn’t clear how to tackle the issue.

But in the higher education sector, the product problem is clearer. Every university is racing to figure out how to provide effective digital/online learning, engaging user experiences, etc. Those that get there first and stay ahead will win.

Parts and wholes

Thinking about complicated systems and our tendency to pick out the parts that seem simple and ignore the whole system, my mind wandered to Kanban. David Anderson, writing in 2010, defined five core properties of Kanban:

1. Visualize the workflow
2. Limit Work in Progress (WIP)
3. Manage flow
4. Make process policies explicit
5. Improve collaboratively

Of all those, the one that seems most obvious and intuitive to us is ‘limit work in progress’. It makes sense and is immediately actionable.

So, my question is, does limiting work in progress alone create enough benefit for the system or does it take all five properties working together to actually improve the system?

The organisation paradox

People are wonderful, organisations are awful. How can this be?

Talk to someone face-to-face and they go out of their way to be helpful. But put policies and procedures, incentives and measures, in the way, and suddenly dealing with an organisation becomes difficult.

Organisations are designed by those very same people who are fundamentally good, so how does this paradox come about? Why can’t wonderful people create wonderful organisations?

(I should make clear my bias towards the prime directive and believing that people are fundamental good, and that Dalberg-Acton was right when he said “Power tends to corrupt, and absolute power corrupts absolutely.” We have dictators and sociopathic CEO’s because we’ve created the social systems that enables and empowers those people. The fault lies with the system, but the system is designed by people. This is the organisation paradox.)