Weeknotes 527
I did:
Half-time
The bank holiday, a day on campus and a day at Product for the People made it like a two-and-a-half day week.
- Met our new product manager.
- Took part in a retro.
- Set out some direction for scaling a new product we’ve been working on. It’s looking like it’s got a bright future ahead of it.
- Chatted about product managers learning and what I can do to help.
- Presented at our product community meetup.
- Started writing up some thoughts on platform product practice development.
- Set up more of my AI PM OS. Access to reporting data is a problem, but my scheduled prompts are running well. The important thing now is getting writing to where it needs to be for AI to use it.
Product for the people
It was amazing.
A bunch of product and product-adjacent people in a room talking about product and eating donuts. What more could you want.
Debbie, Jukesie and Steve get all my appreciation for organising it.
I read:
Start and finish more initiatives
Ben talks about applying limits at the right level to make work completable.
He made me think about how we treat blockers. The usual assumption is that if a developer becomes blocked, they stop working on that thing until someone else does the work to unblock them. Makes sense because you want to make the most of the developers specialist skill of writing code. Or does it? Maybe it makes more sense for the developer to expand their skills and knowledge in ways that might prevent future blockers. That might be knowing which team to speak to, knowing how other systems work, understanding how stakeholders view risks, learning a new skill that allows them to tackle a problem in a different way.
Treating blockers as a different type of work that is handled off to someone else is falling into the trap of the old industrial mindset. It’s not how modern product teams should work. Unblocking the work is the work.
DHCW Vaccine Service roadmap
Beautiful roadmap from Digital Health and Care Wales.
An old friend of mine used to say, “The more you look, the more you see.” He meant that, for things like public roadmaps, what gets shown tells you a lot about what’s going on behind it to be able show it. In the case of DHCW’s roadmap, it’s not just that they are doing fantastic work, it’s that they are doing the hard work to make the fantastic work open.
I thought:
Opportunity analysis
I thought a lot about opportunity analysis. I really believe that finding worthwhile problems is an important part of product management but so often skipped over. Some of my thoughts on opportunity analysis are:
- Separate opportunity from implementation from benefit realisation. An opportunity can look good on paper but be poorly implemented and so fail to get the benefits, but the value potential was still there.
- Analysis is a comparison of opportunities, not a promise to deliver.
- Define different types of value.
- Calculate the same types of value in a consistent way.
- It’s not a backlog, it’s not committed work. It’s to decide if an idea is worth going on the backlog.
- Finding the right methodology is hard. Comparing very different things in the same way to reach a balanced perspective is impossible. The only way I found is to categorise similar things and then compare them to each other.
Effective first, efficient later
Achieving outcomes is expensive. If I had to guess, I’d say at least three and half times as expensive as delivering outputs. Maybe, in time, achieving outcomes can become cheaper but in the meantime, “effective first, efficient later” should be the mantra of being more outcomes-focused. Get better at dealing with the uncertainty inherent in outcomes, understand the time and skills required for iterative improvement towards being less wrong, build better measurement capabilities to know if your moving towards achieving outcomes. Once you can do that stuff well, then optimise it.
Dumbo’s feather
Or, belief affects behaviour. What we believe to be true, about ourselves and our world, affects what actions we take. So, if we want to change behaviour we have to consider beliefs.