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.