Weeknotes 428
This week I did:
Drawing boxes
A lot of stuff this week seemed to be about drawing mental boxes to put things in or out of. Kind of a conceptual tidy up, which among other things included…
- Wrote an audit report for how we’ve been using OKRs. That was fun.
- Our product director presented a shorter version of his talk about decision stacks. It’s an interesting concept for helping product managers frame their remit, but like so many frameworks it says nothing about the environment necessary to make it a success.
- Ran a workshop with some of the product managers to discuss what we do but shouldn’t and what we don’t do but should. My aim is that together we figure out what we’ll need to change about the environment we’re operating in and start same safe-to-fail experiments that help others understand what product managers do and why it’s important.
- Chatted about the vision for campaigns on our communications automation platform. It helped me think more deeply about that aspect of the product and how it might affect user outcomes. One of the challenges we’re trying to figure out is how users have a coherent experience of communications when every user journey is unique, and I think the vision for campaigns helps with this.
- Started conversations about how we achieve data maturity as our product scales. Without the data we can’t do anything and I’m not comfortable waiting to see what goes wrong, I’d rather we start improving things now.
- Mapped out two version of the same ‘thing’, one as a product (long-lived, cross-functional team, empowered to meet user needs and responsible for outcomes) and other as (hierarchical, functional team, centred around technology, briefed to meet stakeholder needs and responsible for outputs). It helped me think more about how to define what a product is.
North Star Workshop
I joined John Cutler’s North Star Workshop, which was full of thought-provoking advice as you’d expect. He talked about thinking of north star metrics as a constellation of connected metrics where “Great thing… is a function of… what the different teams input” and how the north star metric is a leading indicator of sustainable success (because revenue is always a lagging indicator). North star metrics very much fits the positivist ontology, which I’m still not entirely sure I agree with. I think the ‘product’ bit of ‘product metrics’ is fundamentally constructivist as it’s about user’s, their behaviour and how they construct their reality around the product. One day I hope to have the time to properly explore this.
Continuous learning
Signed up for all of Teresa Torres’ email courses. Now I just need to find time to read them and see what I might want to apply.
And I read/watched:
Beyond Team Topologies towards Continuous Stewardship
Sketches of future digital services in government
This is very cool. This is what blogging was made for. And Steve mentions our own Kate Ivey-Williams, which is nice too.
The Service Organisation
Started reading Kate Tarling’s The Service Organisation. I haven’t got very far yet but it sparked a thought about the units of analysis that are available for this kind of organisation transformation work (individuals, teams, organisations, products, services).
And I thought about:
pics or it didn’t happen
Documentation is great, but it’s only useful if people keep going back to it. And we know that most knowledge is tacit and can’t be documented explicitly anyway. Talking about the same things again and again keeps them alive.
Risk analysis
Thought about a different way to analyse risk. Rather than the traditional seriousness and likelihood, I wondered if we could use ‘time-to-fix’ as the risk measure. So, for a financial risk, how long will it take us to replace the money we spent if it turns out to be a waste? And for reputational risk, how long will it take to gain user’s trust if we get something wrong? Knowing how likely a risk is might be useful, but it doesn’t really help us decide if the risk is worth taking. Making the consequences of risks tangible might help us make better decisions about which risks we accept.
Homonyms, huh?
I remember being in a show and tell once where the question, “what is service design?” was asked. As the conversation progressed, an IT colleague said that IT had been using the concept of service for a long time. The conversation ground to a halt because it was clear that although they were using the same word, they were using very different meanings. This is the problem with words like service, product, etc.; they have multiple meanings, none of which are wrong, but which no one can agree on. That doesn’t mean we should stop discussing them, but we have to accept and make clear to everyone that to have useful conversations, we have to accept that there isn’t a single definition to be reached. And as always, we should start with understanding what we’re trying to achieve anyway. If a definition of ‘product’ is the solution, what’s the problem…?