Weeknotes 432
I did:
Consequences
Did you ever play that game where everyone writes words on a piece of paper, folds it and passes it to the next person to write their words, and when everyone is done the story is read out. That could be a pretty accurate description of how work happens, but there’s more to it than that. How good the story is depends on the people writing it, on how well they know each other, what signals they follow to stay aligned whilst doing their bit. The more complicated the story, the more alignment is needed, but it’s worth it for story we get in the end. This week I…
- Added to our Theory of change so it aligns with three pieces of work that all add up to the change we’re trying to create.
- Did some scenario planning to look at how different options pan out and make sure we get to all aspects of the end state we’re trying to reach.
- Talked about a product toolkit of things like a roadmap, OKRs, etc., that product managers are well-versed in using, know how to introduce to a team, and use effectively. The challenge, of course, is that the team exists within an ecosystem of other people and teams that may or may not be willing to accept the product manager bringing in these things.
- Started planning some solution design work to tackle some some evolving problems. Then stopped myself when I realised we don’t understand the problems well enough yet (or what problems we’ll have in the future). Rookie error. So, next week I’ll bringing together what we currently know about the problems.
- Wrote up some thoughts on what others should know about what product managers do and how to work well with them.
- Saw some wonderful examples of people reaching out for help and tackling problems together.
OKRs are really simple but…
Got around to writing up the intro to OKRs presentation I did back in October.
How does service design and product management fit together
Went to the good product leaders group session about how service design and product management fit together.
An interesting theme came out about how we think about the size of things, how the bigger the thing the more important it is, and how roles that work on bigger things are seen as more important than those that work on smaller more detailed things. This old hierarchical thinking doesn’t fit with roles like product and service design which don’t work at a single size level and have to be able to zoom in and out, and connect the big vision-y stuff with the small change stuff.
I’ve written before about how I think product managers and service designers can work together, but in a world where a service and a product are mostly the same thing, it doesn’t make sense for these roles to have mutually exclusive responsibilities, but instead to have complimentary perspectives. So, if I had to somehow try to explain a difference, I might say both roles create alignment for the team and coherence for the product/service, but product managers do it by zooming in and and out vertically, to connect strategy, goals, etc., and service designers do it by zooming in and out horizontally, to connect experience, process, etc.
I read/listened to:
10 things nobody tells you about OKRs
This looks like an interesting series:
What’s particularly useful about what Neil says is how it serves as a diagnostic for an organisation’s ability to work effectively. He says, “OKRs should be quick to write”. If you’re spending ages writing them it highlights a lack of alignment on organisational strategy and priorities. Fix that and OKRs will be quick to write. And OKRs demand data to be able report on key results, so not being able to report highlights the need for better data analytics. Fix that and OKRs will show if the objective is being achieved. I think this is where OKRs can be a tool for change, but only if there are used in this way by people with that intention. If they are implemented as just another goal-tracking method, then they are just more admin overhead, they won’t change anything.
My Product Management Toolkit
Read some of Marc Abraham’s My Product Management Toolkit book. It’s a quick and easy read with some interesting points.
Interventions
This study talks about how policymakers tend to treat enduring, systemically generated problems with limited interventions that are insufficient or inappropriate for the intended improvement. Of course, it’s only one study about something very specific so we should be wary of generalising the conclusion, but when have I ever been wary? It’s a pattern that shows up within organisations and in products as a result of most problems being wicked, novel and vague, and solutions usually being small, specific and constrained by time, knowledge and budget. We just don’t have the tools and techniques for making effective system-level changes.
My go-to example is the effect Uber had on drink-driving in the U.S. Researchers found ride-sharing reduces alcohol-related traffic fatalities by 6.1% and total traffic fatalities by 4%. Uber didn’t set out to achieve that. No product manager came up with an OKR to achieve that. But it still happened. That’s a product having a system-level intervention, and it was unintended. So, I think that’s the only way to work. Build products that have the potential for unintended consequences, and let those consequences emerge as people use them in real life.
Randomness
I listened to this podcast with Matt Ballantine, which completely ticked my boxes for thinking about working in non-deterministic ways.
I thought about:
What are your Whypotheses?
A simple hypothesis is like, ‘if this, then that’. It expresses a cause and effect that says if ‘this’ thing happens, then we can expect ‘that’ other things to happen. And the ‘this’ thing is usually something in our control. But hypothesis don’t explain why we chose the ‘this’.
So, a whypothesis asks, “Why this, if this, then that?” It tries to express intent beyond the simple effect we’re trying to have, to check that the ‘this’ isn’t seen as purely a means to an end, because of the unintended consequences isolated thinking can lead to.
Where do logic models fit
Where does the logic model for a product fit in the decision stack? I think it probably goes either between vision and strategy, if we want to order things by longevity, or maybe it’s better between opportunities and principles, if we think it’s more important to show that it’s foundational and supporting of how all the things above will work.
Whether you show the logic model using north star metrics or impact mapping (a favourite of mine) or theory of change (been exploring this more recently), the point is to help understand which aspects of the product that are within our ability to change, will lead to what outcomes (change in user behaviour) and impact.
Is it a product?
A product is a product if an organisation chooses to treat it as a product, and the best way to decide is to look at the problems it’s tackling. If the problems are well-defined, stable, and have predictable solutions, you don’t need product thinking or the skills a product team brings in tackle uncertain problems, and so don’t treat it as a product. If the problems are new, unknown and the potential solutions are uncertain, then a product team with the skills to apply product thinking are a good way to tackle those problems, and so the organisation should treat those problems as a product.