Weeknotes 442

Roger on 17/01/2025

I did:

Circles of control, influence and concern

  • Talked about team health.
  • Discussed other ways for us to manage risks and figure out what is actually a risk and what is just the situation we find ourselves in.
  • Did another product manager’s development session about defining and measuring product success. We talked about identifying user outcomes and assessing against standards.
  • Started working on a presentation about the value of delivery management.
  • Had an intro chat with our new product coach.
  • Started thinking about how we might approach setting a platform strategy.

The numbers:

  • Spent 855 minutes in meetings.
  • Completed 29 tasks.
  • Averaged 6 tasks a day (remember when it used to be over 10? Crazy times.)

Learning product

I spent a bit of time adding and removing stuff from productmanagement.zone, and some time thinking about the value proposition. I’m kinda of the opinion that product management is too big, vague and varied to be taught in a course, and also that agency and being able to identify what you need to learn are important for product managers. So, it would be nice to have a collection of learning resources where product managers could say ‘I only need a cursory knowledge of the Cynefin framework so I’m only going to watch a video’ or ‘I need more in-depth knowledge about measuring product success so I’m going to read those five articles and that book’. Of course, if I was a good product manager I’d be validating the need before I build anything, but I find creating and organising collections quite peaceful so maybe I am the user.

I read:

Organizations without any middle management?

This article explores how organisations can function without middle management layers. It distinguishes between structure and hierarchy, arguing that autonomous, self-managing teams empowered to make all the necessary decisions related to their own work don’t need hierarchy but do need good structure. It’s interesting to me, given my thoughts on how Professions attempt to fill the gaps created by cross-functional teams.

Cost of delay

Read a couple of posts about what is the cost of delay and estimating the cost of delay.

Continuous discovery habits

I started rereading Teresa Torres Continuous discovery habits (don’t ask me why, it’s not like I don’t have enough new books to read).

I thought about:

Team adjectives

If a successful product is valuable, viable, usable and feasible, then what is the successful team that creates that product? Maybe they are:

  • Productive & Empowered (thanks to Debbie for those two)
  • Happy, Productive & Aligned (thanks to Ian for those)

And from the literature, they’re definitely:

  • Skilled – They have all the expertise they need to tackle the problem they’re working on.
  • Integrated – No team is an island, they are part of an organisation and need information to flow in and out to be effective.

And maybe they’re also

  • Informed.
  • Committed.
  • Decisive.
  • Curious.
  • Inclusive.
  • Focused.

From authority to responsibility

If you want to shift the focus of the work from outputs to outcomes, you need to shift the focus of how people work from authority to responsibility.

Had a couple conversations this week about how organisations are struggling with the legacy of having ‘done lots of stuff because someone requested it without understanding what problems they were trying to solve or thinking about the effects on the coherence of the whole system’. The examples are always about technology but really it’s about power relationships. This kind of org-debt comes about when those with more power feel like their role is to tell people what to do and those with less power feel like their role is to do as they’re told.

The shift then, is moving that relationship to one of responsibility where those with more power provide the context for the problem they need to tackle and how we’ll know it’s been solved, and those with less power take on the responsibility for tackling the problem or saying no. Authority is given, responsibility is taken. And taking responsibility becomes a moral duty to do the right thing, to question why, to see where things fit in the big picture.

On developing a strong position

I’ve been thinking about how important it is for product managers to develop a strong position from which to argue for their products. Yes, stakeholder management, communication, relationship building, etc., are important, but without a strong position a product manager is likely to get swayed by stakeholder opinions. To develop a strong position, they need good critical thinking skills, solid data analysis, an understanding of product concepts and frameworks (and yes, I’ve previously been somewhat against product managers relying on frameworks), etc., etc.

What’s the difference between user and stakeholder?

Here’s my definition of the difference: users use a product to create value for themselves, stakeholders use a product to create value for the business. And to join them up, stakeholders use a product to create value for a business by making a product available to users for them to get value from it.