This week I did:
I’m using my product standards, the things required to mitigate the four big risks, on a new product as a test case. If it works, we’ll get a better quality product with fewer unknowns. My caution for myself is not turning it into big upfront design, but to give just enough criteria to meet to ensure the product is worth developing. It also helps figure out which things need to be validated. For example, one of the criteria is about evidence of user needs. This new product has lots of academic research to demonstrate the need, so we don’t have to do any user research to validate it. But we don’t know if we can market it, so that definitely needs validating.
I completed 83 tasks this week, an average of 16.6 a day (compared to 15.2 last week). I’m trending up. I wonder where my limit is.
I have four objectives. This week, 24 tasks contributed towards my objective of developing the team, 39 towards managing products, 4 were organisational things, and only 2 contributed to supporting others to be more digital.
I still haven’t figured out the middle part for my system, the bit that connects the task level to the objective level beyond percentage of tasks, but hopefully I’ll have some time soon to work on it.
I had 79 interactions with 27 people this week.
And I read:
Reduce WIP and Right Size the Work
So, teams being effective and efficient comes down to managers making good decisions quickly. The answer’s always in the last place you look, isn’t it.
ISO published a standard for plain language. It has four principles:
- 1: Readers get what they need (relevant)
- 2: Readers can easily find what they need (findable)
- 3: Readers can easily understand what they find (understandable)
- 4: Readers can easily use the information (usable)
I’m going to include it in my product quality standards, I just need to think or a way of making it assessable.
Three collaboration antipatterns
Interesting article about organisational situations that make things difficult to collaborate. I think, what it lacks is a description of the type of organisation it applies to, as it definitely isn’t universally applicable. ‘One person split across multiple teams’, for example, is only an antipattern if others are in stable teams. If everyone is one person split across multiple teams (dynamic teaming) then the pattern becomes quite different.
And thought about:
Charity product management’s moneyball moment
In the film Moneyball, Peter Brand, explaining how statistics provide a different view of what it takes to win baseball games, says, “People who run ball clubs, they think in terms of buying players. Your goal shouldn’t be to buy players, your goal should be to buy wins. And in order to buy wins, you need to buy runs… Baseball thinking is medieval. They are asking all the wrong questions.”
I’m looking for charity product management’s moneyball moment. It’s the point in our future when we stop looking to white male Silicon valley venture capitalists and extractive big tech as the model to copy. It’s where we develop a new understanding of how products can intervene in systems. Our heroes will be feminist ecologists and systems thinkers, people like Donella Meadows, Rachel Carson, Donna Haraway and Mary Parker Follett. Our products won’t user-centred, they’ll be system-shifting.
Dropping the ball
I took my eye off a project this month, and only as the work was being delivered did I realise that there were things missing that would make it impossible to achieve the outcome. I can catch up next week but I’m disappointed in myself that I had assumed things were clearer than they were. So, two lessons; one continue with helping people develop their delivery skills so they are able to do the work and manage the work, and schedule more checkpoints at the start.