Weeknotes 460
I did:
Behind the scenes
Behind the scenes is one of my most hated phrases. I hear it every week and it always makes me think that what’s behind the scenes for one person is another person’s main priority. Everyone’s work is behind someone’s scenes, because no one can know everything that’s going on. I did lots of stuff behind the scenes this week, and here’s some of the highlights…
- Worked with another product manager to think through a future piece of work across both our products. We’re presenting it to both our teams in a couple of weeks and I think it’s going to be interesting to see how we navigate the two teams working together.
- Felt really proud of the team for focusing on investigating options and getting to a decision quickly about where to go next for a piece of work. We got from seven options to one, and now comes the hard bit.
- Realised how hard it is for people to see the impact they have.
- Bit of capacity-building work for the future shape of the team so they can take on more responsibility and have more autonomy.
- Waded into university hiring processes.
- Said goodbye to my amazing line manager.
- Talked tools, and individuals and interactions over processes and tools.
- Made the mistake of posting a late-night thought on LinkedIn. Should have put it on Bluesky where no one would have seen it.
I read/watched:
The genius of John Cutler
Skip over the stuff about SVPG and scroll down to the interesting points:
- “Your biggest challenge is leading a major change effort while keeping the organization running.” – And we probably don’t realise how different those two are, what different mindsets and skills and systems they need.
- “Constraints add up.” – They are complicated, interwoven, structural, political problems that get in the way of doing things differently. Behind every constraint is a hall of mirrors that is confusing to navigate and which no one understands.
- “Product management, as a profession, doesn’t have a theory of change (especially not for organizational change). Outside of “treat it like a product,” and “lead well”, there’s not much.” – Absolutely. It’s pretty ridiculous to think product managers know anything about organisational change.
Roadmaps
“Product roadmaps are a tool for communicating the future direction of your product… how you intend to evolve the product over time, how it might look one day in the future and in what sequence?”
If roadmaps are first and foremost a communication tool, would you still need a roadmap even if no one saw it? I think, yes. I think the act of roadmapping demands critical thinking that is absolutely necessary in product management even if no one else sees it. One of the problems with roadmapspeople is that we get caught up with the visual and what it implies. I think, if you can’t roadmap on a piece of paper in plain and simple language, then you can’t roadmap.
AI eats the world
I thought:
Universities online
I’ve noticed a few universities launching separately branded offers of “University of whatever online”, as if people won’t know it’s online unless they spell it out. It’s like the nineties again. I wonder what research led to the conclusion that offline and online learning have to be different. Why does the study experience have to be split by channel? I think they’ll come to regret the artificial separation too late.
Every product has competitors
Thought about understanding competitors for a product, sparked by a conversation about whether internal products have competitors. I think they do. From a Jobs To Be Done perspective, a product competes with all the other ways people get those jobs done. Manual tasks, emailing requests, spreadsheets, bespoke solutions are all ways people find to help them get a job done. The internal product management work is figuring out and applying the mechanisms that drive adoption of the internal product so it replaces all those other things.
High-levels of software delivery performance are achievable
Last week’s weeknotes had the key insights from the DevOps report. I’ve been thinking about how they make pretty great principles, and so how doing research on the best ways to do x is a pretty great way to create principles for that thing. These principles are pattern for organising around the goal of creating great software and creating them based on research are better than making random guesses or asking AI.
National Health System
I spent some time watching a busy emergency department and chatting to people who work in the NHS. Their general conclusion seemed to be that the system is broken. What I saw was a system that works on triggers. So no predicting and acting ahead. A doctor only thinks about looking at test results once he’s been notified they are there, which inevitably causes delays. I completely agree that the NHS needs more money, but that isn’t going to fix an inefficient system.
What business are we in
MacDonald’s isn’t in the hamburger business, they’re in the real estate business. Knowing what business you’re in matters for good strategy. And one way to identify it is to ask what is truly your unit of analysis. Land, not hamburgers. What business is Netflix in? Attention, not movies? Or for the product I’m currently working on – data, not campaigns. We’re in the data crunching business. That’s how we drive marketing automation success. More data in, more data out.
The problem of overstated problems
It’s not easy to state a problem accurately and completely so as to understand whether it is truly worth solving, or how we would know if it had been solved.
Intuitively, we could state a problem as a simple formula of how many people have the problem multiplied by how much the problem affects them, multiplied by how often or how long the problem lasts. Problems that affect a small number of people in a small way and occur very rarely aren’t worth solving. Problems that affect lots of people in significant ways, very often or for a long period of time, are definitely worth solving. But most problems are somewhere in between.
We overstate the problems we want to solve. We make them seem easier to tackle or are more certain than we should be about the outcomes solutions might achieve.
Discovering worthwhile problems doesn’t always mean discovering solvable problems. Finding solvable problems can mean a focus on doing the easier things which invariably have low impact.
So, us product managers operate in the overlap, trying to discover solvable, worthwhile problems. This is where the outcomes and the impact are. But it’s a narrow space.
This is the product manager’s paradox; solving easy problems is easy but it isn’t worth doing, solving difficult (or wicked) problems is difficult but it’s hard.