Weeknotes 424
This week I did:
Obstreperous
This week has been a lesson in influencing in emergent environments. Like the butterfly flapping it’s wings and causing a hurricane, you never know what your conversations are going to lead to. Be the butterfly.
- Kicked off four new pieces of work and handed over delivery. The team made a lot of progress in a week.
- Chatted about how the way we the define product management swings between the tech delivery focused product owner idea of a product manager and the business risk focused product manager idea, which can be confusing but also useful if you know how to leverage both roles.
- Talked about team health metrics and when they are and aren’t useful. Working with some great analysts on other things has changed my thinking on what’s usefully and reliably measurable.
- Pondered how to tackle one of those messy socio-technical problems that is an unclear mix of people, process, and technology.
- Started thinking about my personal objectives. You know how I feel about personal objectives, but sometimes you just gotta do what you gotta do.
- Realised I haven’t done a very good job of explaining what I do or how I do it as a product manager. I think a few people expect me work like a scrum product owner and spend my time on the backlog of features, when actually I’m more interested in uncovering and tackling the problems that will prevent us from scaling. So, I started playing with a few diagrams to try to help me explain.
I read:
Weeknoters
Benji Stanton – kinda on the theme of why being a generalist is a good thing.
Frankie Roberto – on the product metrics and dashboard questions.
Giles Turnbull – interesting to think about the role of translation in communication.
John Fitzgerald – good to see AI is still in the digital mix for charities.
Matt Ballantine – love the point about user needs of inanimate objects.
Oliver Hannan – I remember those pressures to get work lined up for developers. Agile, right?
Owen J – makes an interesting point about how the few can be at the leading edge of new knowledge whilst the majority still have old knowledge.
I thought about:
Ontology
I was wandering through the woods thinking about ontology and epistemology, as you do, and had a couple of realisations. First, I think user research uses a constructivist ontology, so rather than trying to reveal an objective reality, it seeks to show how people create and interpret their own reality. But I’ve never heard user researchers talk about this (except this guy) or cover an ontological position in a research report. Second, product attribution models usually take a positivist ontological stance, assuming there is a single objective truth to be revealed and show how this feature lead to that increase in metrics. But, given that product work is about affecting user behaviour, and an outcome is a change in user behaviour, wouldn’t a constructivist ontology make more sense?
FUVV
The question was posed of how our day-to-day work fits into tackling the four big risks of feasibility, usability, viability and value. It’s an interesting question. How should I go about answering it? Probably need a framework or at least a rational approach, right, after all I am a product manager. I could use an inductive reasoning approach and categorise all my daily tasks by the four big risks (luckily for me I’ve tracked all my tasks since day one) and see what percentage of activities I do for each risk. Or I could apply deductive reasoning to break down the four big risks into the kinds of things that fit and then put my daily tasks into those smaller buckets. As usual, figuring out the why and the how is most interesting than actually doing the thing. Maybe that’s the product-y insight.
Quit or continue
Thought a bit about how ‘quit or continue’ thresholds might be useful for OKR’s. On their own, Key Results only tell us what’s happening, not what to do about it. If x measure is increasing from y to z, should we continue to work on that objective or is that increase enough for us to stop, or has the increase been too slow? Maybe the Key Result needs to be something like, If x measure increases from y to z in 4 weeks continue, otherwise quit.