Weeknotes 351
This week I did:
Product quality
I did some more work on product quality standards. I have nineteen so far. They map to the four big risks for a product and help to create solid foundations for building good products. One of them is about a product being testable, so we’ve started talking about how we embed more testing into our design and development process. I like the principle of testing early and often, so it’s as upstream as possible.
Types of work in progress
I’ve been tracking what I spend my time on over the past two weeks.
- Admin – 20%
- Team – 14%
- Roadmap – 48%
- BAU, issues, maintenance, support – 8%
- Improvement, org stuff – 10%
It seems broadly right to me. I’d hope others on the team have more focus on roadmap work and so a higher percentage of their time spent (60% seems like a good target to me).
And I read:
Product managers are navigators of uncertainty
“Said simply, product development, and hence product management, is filled with uncertainty.” Although, as the article points out, in many organisations it’s seen as simple because it’s just about building what senior people have already decided solves a problem. And so the core of what a product manager does to deal with uncertainty is to validate. Validate problems-to-solve, validate business models, validate that features solve problems, validate that products change user behaviour in expected ways. And they do this by applying the scientific method in an organisational context. Well, they do if they can. It depends.
Product management incorporates issues like privacy, sustainability, and inclusion
This McKinsey article about how the role of product managers is shifting to include taking more responsibility for the external consequences of their product is good to see. I definitely agree with this direction for product managers.
Outputs, outcomes and impact
I read this interesting paper from intrac. Although I don’t necessarily agree with the definitions of outcome, impact, etc., I do like that it covers more than just the usual outcomes vs outputs narrative. So, to have a complete conversation we have to talk about ‘inputs, activities, outputs, outcomes and impacts’.
I saw a comment once about all the answers being trapped in pdf’s, and it might be right.
I thought about:
What do we mean when we say…
I’ve been thinking about how we define things and what we mean when we say things like, ‘agile’, ‘matrix’, ‘digital-first’ and ‘user-centred’. Defining things means drawing a boundary, it means saying what something is and isn’t. So, I’ve been thinking about the phrasing of statements that helps to draw those boundaries. “You can’t say X unless Y”. So, you can’t say you’re user-centred unless you can say what value you last delivered to users and when it was, and you can’t say you’re digital-first unless digital people and thinking are involved at the start of the value chain.
What does slow progress signal?
I used to think that slow progress was a result of too much work in progress. And it still may be, but I wonder if slow progress is a signal of some other things too, which might tell us that too much work in progress isn’t really the cause. I guess it’s important to consider it at different levels, so for an individual, a team and for the organisation. Too much work in progress for an individual becomes self-regulating but it adds to their stress. At the organisation level, too much work in progress results of slow value delivery to users.