Author: Roger

I did:

Loops

Lots of talking and thinking about feedback loops this week (and I started using Microsoft Loop a bit more, but that’s just a coincidence). “Loop” is a fundamental, first principle concept for product management and yet it’s so hard to get right. Anyway, did this stuff too…

• Saw some great leadership.
• Talked about strategy and org change as two sides of the same coin with strategy being about looking outside the organisation and org change looking in.
• Had a few good coaching sessions, particularly about the meta work we have to do so we can do good product work.
• Spent some time on data protection impact assessments which will improve how we handle compliance in the future.
• Brought our simple, consistent way of managing product work to two pieces of change work, so I’m interested to see how well it applies.
• I’ve got next week off which gives me time to step back and replan all the different things I’m working on and think about building the case for something new.

I read/watched:

Shipping Is Your Company’s Heartbeat

Charity majors writes about a letter to CTO’s “explaining why all their grand ambitions and goals with AI are blocked behind their organization’s’ ability to learn.” True, but I’d go further and say all leader’s ambition are blocked by an ability to learn, not just AI. Shipping software is only one way to learn, their are many more. The letter ends with, “If shipping is your heartbeat, then understanding is your breathing.” I want to understand more.

Theories of power

I think it’s hard to successfully navigate within an organisation with a theory of power, i.e., a mental model for who influences who, how decisions get made, which groups have aligned interests, etc. There are lots of definitions and different theories of power, but the pluralist one resonates most with me, particularly the characteristic of countervailing, where groups of similar power cancel each other out and prevent or slow progress.

How People Work, Live! … with Jukesie

Designing in the dark

Lots of great advice from Audree Fletcher on working with stakeholders and convincing them to support your work.

I thought:

Fixing things

Years ago, I had an argument with a developer about a bug in a product. He said it was “working as expected”, to which I replied that his expectations were wrong. Sometimes things can be working as expected but still be wrong, and sometimes they might not work as expected but still be right.

Four P’s of approaching situations

What kind of approach does any given situation need to give us the best chances of success?

	Pragmatic	Purest
Principles	Immediate action is required but it is unclear and so needs guidance to direct figuring it out	The way forward is ambiguous so the guiding principles need to be figured out.
Processes	The specific actions are already known and there is a high likelihood they will be successful.	The way forward is clear but doesn’t yet exist so it needs to be built.

Each has its place, one isn’t better than the other, but choosing between them is important for approaching situations in the right way.

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.

1. 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.
2. Organisation objectives filter – Look across the data behind the user journey to pull out which are the most important parts for improvement.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.

I did:

Countdown

Is it that time of the week again? Where did the time go? Here’s some stuff that happened:

• Welcomed a new product manager to the team.
• Shipped three pieces of work, all of which aim to improve commercial performance, user experience and compliance. That’s the benefit of more cross-functional working showing up.
• Did some capability mapping to understand how we spread investment and what it might need to look like in the future.
• Planned out what we need to do to improve our product instrumentation and behaviour data collection. Obviously I started with what outcome we want to achieve and worked backwards.
• Talked about the financial benefits of our product work, the hypothesis behind it, and the challenge of diminishing returns.
• Watched one of our amazing product managers jump into some complex work and make sense of it really quickly. I was very impressed.
• More interviews.

I read:

AI Safety Index

Unsurprising.

Why product feels hard right now

What is cybernetics

I thought:

The standard of shared understanding

Product teams need shared understanding, and they need a standard of shared understanding so everyone gets to know how it works in a consistent way.

The standard would include artifacts like a roadmap and a kanban board for task management, and a list of stakeholders, a problem statement and

Then, when a team comes together to work on a new product they have an accepted way of reaching a shared understanding quickly.

The real roadmap is all in your heads

The real roadmap isn’t in a slide deck, it’s a social construct in the minds people all across the organisation. What’s on the slides is a weak representation of what people hold in their heads, it lacks nuance and dimensionality and flexibility.

Mirror, signal, manoeuvre

It’s pretty good guide for doing product work too. Working backwards, you decide what manoeuvre you want to perform, but before you do it you figure out how to communicate your intentions, and before you do that you look around to check what’s going on so you don’t make the wrong manoeuvre.

The Doppler effect of deadlines

Deadlines sound different depending on whether they are approaching or receding.