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.
Weeknotes 459
This week I did:
Balance
Among other things, I…
- Stuck to my new approach to planning my work for the third week in a row. It seems to be working pretty well, probably because it’s not particularly radical. All I do is decide what I want to do this week, add some public accountability, and then get stuff done.
- Went to the CX Circle event and learned some website traffic trends, most interestingly that desktop traffic is growing more than mobile.
- Did some complicated roadmapping work, which was kinda fun. I don’t often have time to get deep into things.
- Planned for an upcoming strategy day that will bring together marketing people, data people, engineering & architecture people, and product & delivery people to think about the next year.
- Chatted through some of the implications of our team moving to more of a build-run-own approach, particularly around access to tools and how much processes need to be standardised (you know how I feel about standardisation).
- Had a conversation about team autonomy and how alignment balances that autonomy. Balance, in all things, is the key.
- Talked about knowing when to quit.
- Got two AI’s talking to each other with humans doing their bidding in between.
The numbers
Tasks completed: 38
Minutes spent in meetings: 885
(First five day week in a long time. Going to have to do something about that.)
I read/listened:
Money stories
Rich Mironov talks about how product managers need to talk about their work in financial terms, which I completely agree with, alongside also telling user stories, systems stories, impact stories and so on.
Minimal product management
Love this idea of picking your four product management tools. Mine are:
- User journey mapping – If one of the core tenets of product management is “create coherence”, then showing the user’s experience the product in a coherent way, and what we’ll need to build to make that coherence a reality is essential.
- Theory of change – Showing the logic of how inputs enable activities, which generate outputs, which allow for outcomes, which achieve impact is amazing for surfacing assumptions, pushing logical thinking, creating a plan.
- Step-by-step – A simple listing technique that brings clarity to actions, and which is so often missed when we only talk about the “next steps” but not what comes after that and after that. If you can’t tell me how you think you’re going to get from A to Z, then you probably aren’t going to get there.
- Kanban – Visualise work, track flow, see current status, limit work in progress. A good Kanban is a thing of beauty.
Imagine a tool that could map user journeys and connect a theory of change at the outputs level, show the activities as a Kanban with the step-by-step for each work item, and the outcomes as metrics. That would be so cool.
State of DevOps report
Read this distilled summary of the 2024 state of DevOps report. The full report goes into the Four Keys, and how to improve measuring them, although I prefer my phrasing of the key metrics. The seven key findings from the report are:
- AI adoption increases as trust in AI increases
- User-centricity drives performance
- Transformational leadership matters
- Stable priorities boost productivity and well-being
- Platform engineering can boost productivity
- Cloud enables infrastructure flexibility
- High-levels of software delivery performance are achievable
AI as normal technology
This is amazing work. “Over time, the superintelligence view has become dominant in AI discourse, to the extent that someone steeped in it might not recognize that there exists another coherent way to conceptualize the present and future of AI… AI as normal technology is a worldview that stands in contrast to the worldview of AI as impending superintelligence… We hope that this paper can play some small part in enabling greater mutual understanding, even if it does not change any beliefs.”
I thought about:
Algorithm of user behaviour
Every product has one, but I’ve never seen it documented. The if-then logic of what a user does and what happens because of that action. Could also think of it as the ‘rules’ layer. I might try to create one for a simple product.
Roadmap zero
You’ve heard of inbox zero, right? What about roadmap zero? Roadmap zero is about taking continuous improvement thinking, the law of diminishing returns, and predictive planning techniques to figure out what a product might look like when it’s no longer worth investing in to keep adding features.
Requirements
I don’t have a problem with requirements, but I do have a problem with the assumption that they need to be known upfront and fixed before work starts. In my experience, every requirement is negotiable and is better shaped through multiple conversations.