Weeknotes 468
I did:
A one-day week so super focused:
- Updated a workshop plan and wrote comms for it.
- Talked about how we match the right teams to different kinds of work.
- Chatted to another product manager about how much thinking about the future we should do.
- Wrote a quick one-pager on updating our architecture vision and target state to give the team clearer direction on how our tech stack should evolve in the coming years.
- Went to a session on using AI in the student user journey.
- Chatted about what a good product strategy looks like (forces focus, balances alignment and autonomy, easy to remember, adapts to change… that kind of thing).
Lessons learned
Started trying to write down some of the things I’ve learned about product management over the years. It should be an easier side project over the next few months while I don’t have much time.
I read:
Designing for behaviour change
Lots of hints for how to design products that are actually trying to change user’s behaviours (and you can’t say you are outcome-focused if you aren’t trying to change user’s behaviours). I like “Commit to begin – Secure an early ‘yes’ that carries them through the hard middle” and “Set the standard – Show the benchmark up-front and keep reminding people where they are”. I can see these these could be built into user interactions to change behaviour, not just complete actions.
Product operating model
Nice article trying to explain some of the differences between a project and product operating model.
Would have been better if it was more critical and evaluated the downsides of the product operating model. I did a quick search for any research comparing the project and product operating models but couldn’t find anything. I think it’s important to talk about product operating models as hypotheses in an uncertain and ambiguous space, rather than as ‘the answer’ to the downsides of the project operating model.
The product-led organization
Started reading Todd Olsen’s the product-led organization.
I thought about:
Thinking in bets
I was looking back over my notes from Annie Duke’s Thinking in bets and the quote, “I had to learn to focus on the things I could control, let go of the things I couldn’t, and work to be able to accurately tell the difference between the two.” This is an essential product skill in the Measurement space, which makes it really interesting to me because I’m particularly interested in the opposite ends of the product development process; opportunities and measurement.
Simplest possible outcomes
I like the idea of getting changes in user behaviour down to a single verb. It makes them easier to remember and talk about. So in our comms product that’s Open, Read, Click. Three user behaviours, that are within our ability to affect, and which lead to business results.
AI interaction modes
I think there are only four ways for AI to be involved in how users and organisations interact with each other.
- User to Org AI. E.g., person uses a chatbot to interact with an organisation.
- User to Org system with hidden AI. E.g., person receives emails from an organisation and doesn’t know AI wrote it or selected them.
- User AI to Org system. E.g., person uses AI to provide information or complete a task by interacting with an organisation’s website.
- User AI to Org AI. E.g., person uses their AI agent to interact with organisation’s AI agents to complete tasks.
AI replacement cycle
I think replacing humans with AI in organisations cycles through three steps:
- Unbundling to the smallest explainable unit, e.g., a task like writing a business case.
- Move the task from being completed entirely by a human, to machine-in-the-loop (like asking ChatGPT for suggestions), to human-in-the-loop (checking automated outputs), and finally all machine (human no longer needed for the task to be completed).
- Rebundle multiple tasks into a role (replacing the human entirely), rebundle roles to replace teams/functions. Rebundling requires thinking about how tasks, roles and functions should be grouped as wouldn’t make sense to do it the same way as it was done with humans.
Capability and capacity
Capability is being able to do a certain thing that an organisation needs to operate. It is made up of people, processes and tools.
Capacity is the rate work flows through the capability. It isn’t the number of people on a team, even though that’s often how it’s used.
Neither of these is fixed. And planning against them as if they are fixed leads to unrealistic plans. The more complex or novel a problem is, the less flow, because the team has lots of figuring out which involves false starts and changes in direction. The more familiar and predictable a problem is, the more flow because the team knows what they are doing.
Cross-functional teams create the illusion of fixed capability and fixed capacity with consistent output. But it’s not true. Output is always constrained by the biggest bottleneck, and more often than not, that’s outside the team. Large teams face the same bottlenecks as small teams, so adding more people to a team doesn’t increase capacity if the bottleneck is outside.
Which led to thinking about…
Bottleneck patterns
Bottleneck patterns might be:
- Unclear responsibilities. Teams aren’t sure who should be doing certain things.
- Insufficient knowledge and skills in the team. Cross-functional teams don’t always have everything they need to deliver value.
- Poor collaboration across teams. Teams don’t always know who to talk to or how to get them to take notice.
- Misaligned priorities. What is super important for one team is not important for another team.
- Poor communication from and with stakeholders. Teams don’t always understand what stakeholders want or how to give it to them.
There must be a lot more but the meta-pattern here is having to figure things out from scratch every time a team starts a new piece of work. That’s a huge bottleneck to flow.
Weeknotes 467
I did:
Turned out nice again
Only worked three days this week but I achieved everything I planned, and it’s always nice when that happens.
- Planned a workshop for a leadership team to help them operationalise a complicated strategy. There are lots of different perspectives on the strategy, just like the blind men touching an elephant.
- Wrote a discussion paper to try to help with setting the long-term (5 to 10 years) direction of a product.
- Talked about how to manage dependencies between teams, and that the answer is always better conversations.
- Found some opportunities to encourage a few people to use copilot to get some stuff done more quickly.
- Tried out a product tool to see if I could set it up for actual product work rather than project delivery.
- Chatted about personal objectives a bit. You know what I think about them but I’m keeping an open mind to see if there’s a way they can be useful.
- Started working my way through the process to assign new work to another team. We definitely need to get better figuring what work isn’t for us.
- One of our team won an award. So proud.
Calm social feed
Added lots more to my feeds. I’d much rather spend time reading what’s going on with people I’m actually interested in than scrolling through nonsense on social media.
Gave blood
The whole experience of giving blood gets better each time. I used the app to book an appointment for the next day, received helpful text messages, and had a smooth donation. A year ago that wouldn’t have happened, so well done to the team working on this.
I read:
Solving for Value – A Journey of Ambition and Stupidity
Started reading this book because I wanted to give scrum another chance and validate my thoughts on cadence vs continuous approaches. But it’s really badly written so I don’t know if I’ll finish it.
It is Time to Reclaim What Product Managers Are Here For
“Your team doesn’t need a product manager writing stories in Jira. They need someone making sense of uncertainty and pushing decisions forward.”
The problem with problems
“How do we build organisational muscle for problem discovery that’s as sophisticated as our solution discovery? How do we create space for people to step back and ask not just “how might we solve this better?” but “what if this isn’t the right problem at all?””
The evolution of delivery
“The best delivery teams I’ve seen recently aren’t obsessing over governance, RAG statuses or waterfall vs agile anymore. They’re asking a much simpler question: “Where’s the friction, and how do we unblock it?” That’s it. That’s the work”
Finding out if you’re right
John is right, OKRs don’t solve all problems but they tackle one problem really well; connecting inside an organisation (strategy, hypotheses, experiments, etc.) with outside (user behaviour) to see if you’re right.
Problem-solving speed
“…the winners are distinguished by one thing: their ability to identify and solve problems at high velocity.” This changes the long-standing talk of competitive advantage being achieved by being first to market, from shipping fast to solving problems fast. It also fits the shift in product management from project output to uncovering worthwhile problems. Things are moving in the right direction.
I thought about:
How AI changes product management
Most of what I read about AI product management seems to basically say do product management right, regardless of the AI. So I’ve been thinking about whether having AI in products actually changes product management or not. AI changes things like the company ethos and ethics, regulations, pricing models, time to market, return-on-investment time horizons, but those are all things product managers should be considering anyway. So, does AI change product management? If it does, the effects are much smaller than other factors like the economy.
How far ahead
One of the elements that I think makes product management different to lots of other disciplines is how far ahead we think. The future is uncertain and ambiguous (just like the market) so product skills are perfect for dealing with it.
Maybe the time span a product manager considers is a useful signal for the quality of product management too. If product managers are only thinking about this quarter, they are probably too involved in delivery. If they spend more time thinking about how things might be in five years then they’re more likely to be doing good product work. I’m interested in how we might develop this skill in product managers.
Up and down
Thought some unfinished thoughts about how work flows through an organisation. The traditional and dominant way is mapped to the hierarchical org chart. Those at the top think of the big things they want the organisation to do, tell those the next level down, who interpret it and tell the next level down, and so on until the work is broken down into small enough chunks. We created cross-functional teams because we recognise the information loss from handing-off work between teams. Maybe we need a similar solution to handle information exchange up and down organisations.