Month: July 2024

This week I did:

Balance

Most product decisions are trade-offs, they’re about trying to get the balance right, and almost always failing. That was definitely a theme for this week. But lots of other stuff happened too:

• So many good chats about working collaboratively. Everyone wants it. No one knows what makes it so hard.
• Did some work on our objectives for the year and how our work relates to them. I think it’s finally starting to click, although still a bit too vague without a logic model and dashboard to show which metrics we’re affecting.
• Had an interesting conversation about continuous improvement and making it part of everyone’s role. It feels like a part of what it means to be an empowered team, you don’t just do the work, you make the way you do the work better.
• Added my roadmap to my dashboard so I can see how much work I have in progress and how much I’m thinking about the future. The answers are, too much and not enough.
• Started planning for a new team member joining us. It’ll be the fourth I’ve onboarded and I’m keen to do a better job than before.
• Reflected on a mistake I made a couple of months ago where I went against my better judgement and did things the way they were expected. And wondering how I fix it.
• Might set myself the goal of trying to go for a whole week without causing trouble. Nah, who am I kidding?

The numbers

Over four days I:

• Completed 33 tasks (although I’m sure I missed recording some).
• Wrote 10 pages of notes.
• Talked to 30 people 73 times.

Predictable vs. Emergent

I tried to get my thoughts in order about how modern tools and techniques just don’t work (or at least don’t work well) in organisation with a deterministic worldview. I’m not sure I’m explaining it very well, but worldviews are difficult things to grasp.

I read:

The small ‘a’

Started reading The agile manager by Rob England and Dr. Cherry Vu. Looks really good.

Cognitive Load Theory: Does it apply in software delivery?

Fantastic thoughtful post from Sorrell Harriet about cognitive load theory for software teams. She says, “the universal wisdom underlying Sweller’s CLT and Team Topologies which tells us that, to enable individuals and teams to do their best work, we must strive to remove unnecessary barriers to learning. This means giving our attention to the mechanisms by which people learn and the conditions in which they are operating.” The lesson here is, rather than arguing about whether a theory is correct or applicable, get to essence of what your were using the theory for in the first place.

Digital geography

I loved reading this. Mostly because my art is kind of about how physical and digital worlds interact, but also it reminded me of conversation I had a few years ago about abstraction and embodiment, and how we use familiar things to understand new things.

I thought about:

What it means to be a manager

There was a time when being a manager meant being a line-manager. Managing the (production) line meant telling people what to do and making sure they did it. The more people you line-managed, the more important you were. And there’s a lot of that left over, but nowadays being a manager means (or at least, I think should mean) something quite different.

It’s completely possible to be a manager without line-managing people. Managing work requires very different skills from doing work. It requires a very different mindset too, one that considers wider, deeper, longer-term impact.

So, to me, progression up the career ladder as a manager should be about increasing impact along those three dimensions.

Give blood

Booked an appointment to give blood, then had a phone call asking me to book an appointment. The app hasn’t improved since I wrote this. If I could product manage anything, it would be Give Blood.

This week I did:

We’re gonna need a bigger boat

This week was an unusual one with three days away from normal work. Still, it felt as busy as usual:

• Realised that as a team responsible for an outcome (not just for a piece of tech), we have a big dependency that is outside our control. Question is, what to do about it.
• Went to a workshop about goals, metrics and measures, which helped me understand how product metrics align to institutional metrics. We talked about the concept of a ‘hierarchy of metrics’ so I need to figure out if product metrics fit or if a network model might work better.
• Went to a brilliant collaborative session with the team starting to figure out how to tackle an interesting problem. I left buzzing. This is how to work as a team.
• Ran an async retro, analysed the results and wrote up the report. I think analyse is the most important part of retros.
• Talked about ‘the path and the plan’. To avoid jumping into work that may or may not give you the result you want, figure out the path the work is going to follow and what the plan is for staying on the path.
• Watched a ‘My first 100 days’ session one of our new directors did, which made me think about what I’d say. Maybe my message would be; we’re all in the same boat, if you someone falls overboard pull them back in, and we’re gonna need a bigger boat.
• Went to a playback session on some work we have coming up.
• Chatted about OKR’s and recognising the emergent nature of modern product development.
• Found other problems, and probably got more excited about it than I should have. I love this complex adaptive system and looking for ways to intervene in it.

UKEduCamp

Went to my first UKEduCamp. It was brilliant! I got overwhelmed and didn’t feel able to talk much but, I’m so thankful that people volunteer their time to make things like this happen. Nice stickers too.

Simple strategies

Version 0.2 of my thoughts on creating simple product strategies. Two additions; thinking about strategies rather than strategy, so lots of small strategies rather than one big one, and making the capability to deliver the strategy part of it (thanks, Ian). This is an interesting one as my usual thinking is that delivery should be separate from the strategy so you can pull different levers, ramp up and ramp down, without changing the strategy. But embedding capability in the strategy creates a feasibility test which is very helpful.

I read:

What is Chaorder?

A colleague mentioned the term, ‘chaordic’, which I think I’ve heard before but hadn’t paid much attention to. Chaorder is the delicate balance between chaos and order, which seems like a better way to think about change. Rather than thinking about whether things are changing or fixed, like lots of change methodologies do, it suggests asking whether the balance between chaos and order is just right, and responding to maintain the balance.

Explode on impact

Toby Lowe makes the case for moving from funding for “demonstrable” impact (because this — paradoxically makes real impact harder to achieve) to funding for collaborative learning and adaptation. This may or may not be a good idea, but he’s the expert, not me. What I am interested in is his points about the effectiveness of logic models. I think there’s a big difference between demonstrating impact through some kind of logic model, and making big decisions about future solely from the one perspective provided by the logic model. The problem is in how the decisions are made, not in how impact is recorded and reported. The answer then, as Toby says, is to not use impact for accountability/governance/performance management purposes. What to use then?

Plain English

Anyone who writes anything should read Iain Broome’s brilliant Plain English Club.

And I thought about:

Ways to prioritise

Thought about what a shuhari-esque practice might look like. Maybe for prioritisation it looks like this; product managers prioritise, senior product managers collaborate with the team to prioritise, lead managers coach the team to prioritise without them.

Defining products

Someone mentioned defining what a product is at UKEduCamp. My usual response is that if it was doable it would have been done by now, and that usually it’s unhelpful as the point of a definition is to stop conversation. But, if I had to, I mean really had to, define a product, I’d probably do it like this. I like the maths definition of product as ‘the result of multiplying things together’. It tells us that a product is all the things an organisation brings together, things like knowledge and expertise, processes, technology, marketing activities, etc., and packages up in a way that reaches an answer to a user’s sum. Maybe that’s stretching the maths thing a bit, but the point is that a product isn’t just a piece of tech, it’s what you get when you mix things together in a organised way.

Pyramid

For ages I’ve thought that a lot of product management thought leadership isn’t really about product at all, it’s about organisational dynamics, which I found disappointing. But I’m starting to think there’s a pyramid with user outcomes at the top, and if you want to achieve that you need the next layer down, which is great products. But to get that you need the next layer down, which is a great team. And you only get a great team if you have a great organisation. And so maybe product managers get pulled into doing organisation level work because without it they can’t do the product level work.