Weeknotes 520
I did:
Outcome-focused
We’re putting lots of time and energy into being more outcome-focused. It’s something I really believe in because of what it means for meeting user’s needs, for what it means for teams and trust in their expertise, and for what it means for efficiency within organisations.
- Got back into planning my week which I’ve been a bit slack on recently but think I should practice what I preach.
- Set up a wiki for a piece of work, which is another thing I preach.
- Did some more detailed capability mapping against one of our products. Next steps are to analyse the current investment into each capability.
- Prototyped a dashboard for reporting our north star metric.
- Talked about outcome-focused roadmaps that give teams the space to explore different ways of achieving goals.
- Talked a lot about analytics, metrics, measurement and, most importantly, insight.
I read:
The portal trap
Not just because everyone else is reading it, but because it’s an interesting perspective on the kind of solutionism that is the arch nemesis of user-centred design and product thinking.
The cost of ambiguity
Super insightful point from Holly Davis about how it used to be that the good practices we’ve known for a long time can reduce ambiguity could be ignored because people thought they were good at dealing with that ambiguity (they’re wrong, but that’s another point), but now AI is part of the picture, and it doesn’t deal with ambiguity very well at all, all those practices take on another level of importance.
I thought:
How to make outcome-focused roadmaps work
Outcome-focused roadmaps are a great way to balance an organisational need for predictability and financial planning with giving product teams the scope and space to understand problems and solve . But creating outcome-focused roadmaps requires a different approach than the usual approach of specifying deliverables on a roadmap.
- User journey – Map the actual user journeys at a task level so you have a clear representation of all the actions users do as they use the product.
- Organisation objectives filter – Look across the data behind the user journey to pull out which are the most important parts for improvement.
- Outcomes – Write outcomes for the important parts of the user journey that should be improved. When we say “outcomes”, we mean Josh Seiden’s definition of “a change in user behaviour that gets business results”. We can phrase outcomes as “who, does what, by how much”, e.g., new visitors view three pages 15% more than they currently do, or, logged-in users convert through x journey in less than 30 seconds, or, users from the US provide marketing consent twice as much as they did last year.
- Roadmap – Place those outcomes on your roadmap. Assuming you use a Now Next Later format, then everyone can see that the priority right now is new users, with the US market something for the future.
- Hypothesise ways of achieving outcomes – The vital part about expressing outcomes in the way we do is that it doesn’t tell the team what to build. It tells them what to achieve and lets them figure out lots of different ways to achieve it. The team might come up with five hypotheses for reducing the time taken for logged-in users to get through a journey, but they aren’t committing to delivering all five. They can decide to deliver one and see what effect it has before they decide what to do next.
- Deliver one/some of them – The team delivers on one of their hypotheses. They probably picked the one they thought was most likely to reduce the conversion time.
- Measure – Then the team measures the shipped changes. If the outcome has been achieved, then you go to 4 and pick up what’s next on the roadmap. If the outcome wasn’t achieved, they go to 5 and pick another hypotheses to deliver. This way they continue to work on an outcome until it’s achieved, but are efficient in only doing the right amount of work to achieve it.