Category: Weeknotes

This week I did:

Roadmappin’

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.

Productivity

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

Wrote 27 pages of notes.

Spoke to 34 people.

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

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.

Productivity

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.

Definitions

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

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.