Weeknotes 481
I did:
Multi-directional
- Lots of chats with excellent people from the new team I’m working with.
- Read lots of documentation.
- Went to a workshop with a cool design system consultant. Lots to think about for how to spread a design system. Also, helped me realise that our design system is about more than just making websites look good, it’s an essential part of regulatory compliance.
- Started working on a new product strategy.
- Talked about ideas people have been working on that face considerable constraints and blockers. It’s a explore/exploit problem – how much time should we spend exploring and investing new opportunities.
- Discussed approaches to reviewing and prioritising opportunities, which fits the decision stack nicely, and
- Worked on a complex attribution model to explain which user touchpoints on which channels contribute to conversion.
The numbers
Tasks completed: 55.
Minutes spent in meetings: 1135.
Bubbles
I went to bubble planet, an immersive virtual reality experience. It’s pretty amazing how easy it is to convince our bodies they are moving. I know VR will probably never go beyond this kind of entertainment, but I’d definitely be up for virtual reality work environments where I create my own space for dashboards, people, documents, etc.
I read/watched:
What great product leaders do differently
Leading with control, goals and measures maximises what people do with their hands. Leading with context, problems-to-solve and collaboration maximises what people do with their minds.
What is choice architecture?
The product strategy I’m working on is about helping people make the right choices for them so I’ve been learning about choice architecture, cognitive bias, behavioural economics and libertarian paternalism.
I thought about:
Problem/solution matrix
In complex products and services, it can be hard to connect the features we deliver to user problems and see where we’re solving and what gaps exist. I like the problem/solution matrix to help understand this. It looks like this:
| User problem 1 | User problem 2 | User problem 3 | |
|---|---|---|---|
| Solution 1 | ✅ | ||
| Solution 2 | ✅ | ✅ | |
| Solution 3 | ✅ |
Solutions are often features we build into the interface, but they can be policy changes, existing system rules, in fact all the parts that make up the product. By simply ticking which part of the product tackles which user problem, we can see which features are targeting which problems and we see the gaps where a problem isn’t being solved.
It can get really complex if you go into very specific problems, but that’s not a bad thing for complex products and services because hiding the complexity often leads to shipping features that don’t solve the problem. Show the complexity!
It’s also a useful guide for setting expectations about how ‘solved’ a problem is likely to be, and for continuous improvement later if a solution doesn’t sufficiently solve a problem. If the problem looks big and gnarly and we only have one feature targeting that problem, we’re probably not going to solve it.
Explaining outcomes
Had a few chats about outcomes this week so thought I’d try to get my thinking straight.
It would be great if everyone agreed with Josh Seiden that outcomes are a change in user behaviour that gets business results, but not everyone does and time spent arguing over definitions is usually wasted. So, it’s ok to accept a word-cloud of synonyms like result, conclusion, consequence, after-effect, etc.
Outcomes match against problems and come after solutions are successful. So it goes: problem → solution → outcome. Outcomes match to problems, because an outcome can only be achieved by solving the problem. The easy test of a team that says it’s outcome-focused is to ask which problems match which outcomes. If they don’t know, they aren’t outcome-focused. Solutions don’t always lead to outcomes, that’s why we say things like ‘outcomes over outputs’ to make the point that just because we’ve shipped something it doesn’t mean people are using it and it’s actually solving their problem.
The three big outcomes are ‘easier, faster, cheaper’. It’s what every user wants and what every product and service promises. So, if your outcomes are just that (or synonyms of those words like simple, easy-to-use, quick) then you’re saying your product is just like everyone else’s. Easier, cheaper, faster are givens. They should just be what every product and service achieves anyway. Good outcomes go deeper, they differentiate the product, which is why the have to match to real user problems.
Outcomes are outside of our control. We can make the best solutions possible and still not achieve an outcome. That’s why we measure and iterate, but it’s never certain.
Pluralistic product management
The reading I’m doing for my MBA is already helping me understand and explain better why communication and stakeholder management is so important in product work, and why the kind of product management you see on YouTube isn’t fit for every kind of organisation.
The kind of product management you see on YouTube fits in organisations that have a unitarian culture. This comes with the assumption that everyone in the organisation agrees about and works toward the same goal. Things that take people away from that singular focus are seen as bad.
There are a whole bunch of other types of organisation that have pluralistic cultures. These organisations have multiple goals, which are often in conflict with each, push against and negotiate with each other. That is accepted in pluralistic cultures, it’s not considered a bad thing, it’s a normal part of how the organisation works. What that means for product managers working in these kinds of organisations is that the noble effort of trying to get everyone aligned behind the same goal isn’t going to work. It might make good narrative but we have to accept the reality that different people, groups and teams have different goals, and that’s ok. We can understand it, navigate it, and still succeed. It’s a feature, not a bug.