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