Author: Roger

I did:

Generalist FTW

One of the things I like about being a product manager is how I get to do lots of different things. This week I worked on data protection, cost analysis, planning and resourcing, adoption, preference management, supplier relations, analytics and evaluation, accessibility, reporting… and this stuff too:

• Worked with some of our brilliant user-centred design and research people on the vision for a service.
• Talked about product strategies, including direct distribution, which means users have to use your products to do what they want to do, and indirect distribution, which allows users to do things via third parties.
• Wrote up some thoughts on the direction I want one of our products to go in. The challenge is in getting the right balance of specific actions that need to happen and creating space for things I haven’t thought of yet.
• Joined in with a planning exercise our fantastic lead delivery manager organised to prepare for some big pieces of work coming up.
• Chatted about long-term roadmaps and engaging with stakeholders to shape it.
• Thought about how to formalise and codify my process for assessing new work. And how to get AI to help because I’m just not getting it done quickly enough.
• Helped a few teams prepare for a product launch in a couple of weeks.

One month of tracking against my objectives

I totalled 216 tasks and meetings over 22 working days in October, which is pretty much sticking to my 10-a-day goal. Of them, 37% contributed to my six objectives. Within that, 20.8% was for the objective I worked on most and 0.9% was for the one I worked on least, with the other four in between.

Some of my objectives are broad and others quite specific. Some have end dates and others are open-ended. I’m interested to see how those differences are reflected in the data.

Study kanban

The next module of my MBA starts next week so I’ve been setting up my kanban to manage everything I’ll need to do between now and April. There are over two hundred items that I could never keep track of without my own kanban. Thank you Taiichi Ohno.

I read:

Bizarre love triangle

Thinking and writing like this from Simon Morgan-Wilson is absolutely brilliant. Real answers based on real experience. Not buzzwords, not regurgitated, not what AI mashed together. We need more of it in product management to help us all learn, adjust and refine our thinking about what it is we do.

The feature that made you ordinary

Interesting lesson on the risk of productising away the emotional needs of users. Starbucks’ app focused on convenience, removed pain points for customer, made lots of money… and still failed because customers didn’t just want coffee, they wanted to feel seen and part of a culture. Nothing to do with this, but I still think the TV show Friends was the cultural soft power behind the rise of the coffee shop and the success of Starbucks and Costa.

I thought:

Responsibility = judgment + information + action + control

I thought about responsibility a bit this week, and what it takes to actually be responsible for something. I think it takes four things, and if any of them is missing on incomplete (and they usually are), taking responsibility gets really difficult.

• Without judgement, someone can’t take responsibility for something because they don’t have the capacity for making decisions about it. It’s why mentoring, coaching and getting the reps in is so important for new product managers, it builds judgement.
• Without information, someone can’t responsibility because they don’t know enough . It’s why speaking to people, understanding context and building up mental models is so important for every product manager, it maintains the flow of information.
• Without the ability to take action, someone can’t take responsibility because they won’t be able to make things happen. It’s why influence and relationships are so important for product managers, because they almost always need other people to do things.
• Without control of those actions, someone can’t take responsibility because they won’t be able to correct things that go the wrong way or change things based on new information and learning. It’s why data, feedback loops, reflection and learning are so important for product managers, because they have to be able to detect and understand what is and isn’t working.

(Aside, but personally, I think responsibility is taken, not given which is why the concept of RACI never really works in autonomous product teams (Aside, aside, but I saw a video about autistic understanding that said we don’t get that others know things to be untrue but accept them anyway, so things like RACI’s MECE approach is an accepted fiction that people go along with even though it doesn’t make sense).)

I did:

Workshoptastic

Spent 60% of my time at in-person workshops this week, which has me looking at the flow efficiency of all my other work with raised eyebrows, but still did this stuff:

• Helped out at two delivery playbook workshops and learned a lot from a consultant who’s been helping/challenging us.
• Went to a fantastic workshop about shaping up the vision for one of our services.
• Talked about how we might improve how we manage split tests and build a knowledgebase that helps us understand where we are more able to change user behaviour in ways that gets business results.
• Did some work with other product managers on a group-level roadmap. The really interesting stuff of talking to about a hundred stakeholders is still to come.
• Analysed some new ideas and thought about when and how is the right time to get the team involved.
• Thought about product strategy workshops using AI to create the tools and templates specifically for developing the strategy that you’re working on. Our usual tools, e.g., Lean UX Canvas are generic and fixed because they have to apply to a wide range of circumstances, but that’s no longer the case when AI can create a canvas for a specific situation.
• Chatted about where we want to go next with the user-behaviour-triggered communications capability we’re working on.

I read:

Agentic web evolution

“The interfaces mediating all of this (ChatGPT, Claude, Gemini, etc.) want to keep users inside their own surface. They’re deeply invested in building a web where agents can find the information and do the tasks a user requires without ever sending them elsewhere. To me, it seems natural that these interfaces will start rewarding sites pre-structured for agent operability.”

Where AI capability meets customer need

Started reading Jeff Gothelf’s new book ‘Product management and AI: turning capability into customer outcomes’. “Product management done well in the age of AI takes the raw capability of AI and points it at problems real customers have, in ways that change what those customers do hopefully for their benefit and then turns that into a measurable business impact. Without that discipline, AI makes teams faster at producing things nobody asked for. With it, AI becomes the most powerful accelerant we have ever had for learning what customers need and delivering it.”

AI Doesn’t Change Product Management Fundamentals

Jason Knight talks to Jeff Patton about why product management fundamentals are still so difficult to put into practice, how AI can help teams succeed or fail faster, and why understanding what customers actually do remains more important than ever.

AI week

I haven’t watched all of them yet, but there are some really interesting talks about AI particularly from universities.

Build the Agentic Enterprise

I thought:

Problems and solutions

It’s much easier it is to think in solutions than problems. We all do it and see it. Start talking about a problem and before you even realise it, before you’ve really understood the problem, you’re already thinking about how to solve it. Maybe, when we’re building products, it’s because the solution is almost always known and the same, it’s build software. But it’s much harder to think in problems because problems can be process problems, people problems, user problems, organisational problems, big problems, little problems. Problems are messy, unclear, and difficult to reach a single agreed definition. That’s why product managers have to be really comfortable with ambiguity.

Culture is how we behave

In a workshop this week, one of our senior leaders said, “culture is how we behave”, and it stuck with me. Sure, there are lots of theories about organisational culture, and they have their place, but as a product manager whose job is to change user behaviour in ways that get business results it makes me question whether a product approach is a good fit for changing culture. Previously I’d had the opinion that product thinking gets organisational change wrong because it believes that once a change is made it stays made (because that’s how software behaves), but when changes happen to people, those people can change back or change in different and uncontrollable ways, which means change doesn’t stay made. But I’m not so sure anymore. Maybe all this AI product stuff about nondeterministic tech making changes to user behaviour in unpredictable ways is getting to me.

Marginal gains, diminishing returns

A lot of product management focuses on the exciting stuff of introducing new products, but eventually, if you’re lucky, your new products become old products and then you need a different approach to managing them. Managing mature products is a marginal gains, diminishing returns game.

Marginal gains means recognising that you aren’t going to make big leaps forward on any of your goals. The only progress to be had is in lots of small changes all over the product to get the last few percent increases. Diminishing returns means understanding that those gains require more and more investment, or to put it another way, for the same investment the returns will get smaller and smaller. That point on the lifecycle where maturity crosses into decline is where you have to make some hard decisions about what to do with the product; keep investing, just do the essential maintenance work to keep it running, or retire it.

I did:

Mental models

How we individually understand how things work so we can change them is a constant fascination and theme to my work. It always seems to come back to whether enough people understand something in a sufficiently common way to do something with it. Some examples from this week:

• Finished some idea analysis. It was a idea good but not for our team.
• Got our platform product managers together to work on our long-term roadmap.
• Planned a workshop for introducing a new delivery playbook.
• Chatted about operationalising data-driven decision-making and what the whole loop looks like.
• Facilitated a workshop to categorise products.
• Worked on an evaluation model for split tests.
• Thought about how a product strategy co-writing session might work.

I read:

The return of the feature factory

John Cutler reflects on his feature factory post; the one that coined the term, divided the factions, led to notoriety. We need terms like this to group our understanding around and prompt discussion, and move our practice forward. But John makes the point about the problems with x vs y narratives. I guess, as his post shows, we never know where the narrative might go.

Online learning developments in UK higher education

Neil Mosley’s quarterly reviews are always interesting, with this one reflecting a number of shifts in UK higher education including school leavers choosing to study online and AI courses. Higher education trends often seem like lagging indicators for societal change. The strategic challenge for universities is which societal change to lean into.

Start Before Product

Scott Colfer talks about the product work outside the product in complex service organisations, and getting oriented before starting, which means understanding where you’re working, understanding the change you’re trying to make, understanding who needs to be involved. All good advice.

I thought:

Merge

Most product development processes are linear. I don’t blame Cooper but he has a lot to answer for. It looks nice in diagrams but it’s not the reality.

I have recently come to the realisation that product development processes are really about merging things, or maybe merging the right things at the right time.

When is the right time to bring together technology and use cases? When should compliance and data architecture come together? When does it make sense to bring evaluation in with user experience design?

A merge approach avoids artificial phases and allows for lots of adaptation depending on the product, teams, etc.

WIP x CIP

The calculation for organisational complexity is work-in-progress multiplied by change-in-progress. Work-in-progress is all the work going on, and I mean all the work, not just the stuff on the roadmap but all the side projects, new ideas people took initiative on, leftovers that never really got finished. Change-in-progress is all the change going on, stuff like people leaving and joining, new organising logic, management methods, and all those reorgs and transformations that never completely changed what they were meant to but leftover things that didn’t get fully replaced when the next change came along. Those two multiplied is how complex an organisation is.

Visioning

A vision isn’t just a statement of what the world looks like if your vision becomes a reality. That’s part of it, but a really good vision provides a sharply refined description of all the aspects of that future world. It gives you a sense of what the market might look like, what size and shape the team needs to be.

Four stages to get to a product vision:

1. Setting the boundaries. You need to know what you’re going to try to change and what you aren’t.
2. Diverging on lots of things within the boundaries. User research, new technologies, market trends, operational processes, architecture, budget, teams, etc., etc., gives a sense of all the changeable things.
3. Converging on the things that matter. Narrow in on all those things until you understand which you would have to change to create your new world.
4. Asking what would have to be true. If you want to have any chance of turning the vision into reality you have to be able to articulate the changes you need to make for each thing you converged on. If your vision demands a different architecture, whole bunch of data you don’t collect and partners who don’t even know you exist, you should be fully aware of that before you commit to a vision.

A product vision isn’t just a statement, it’s a mental model. The visioning work is to make that a shared mental model.

Effort-to-value

Effort doesn’t tell you how long the work will take, it tells you if the work is worth doing. It’s a return on investment calculation that helps you understand opportunity cost because if the time spent working on this can’t be spent on that. It’s different to time-to-value because it doesn’t include wait time, it’s the total time everyone will spend/spent on this work to get it to the point where it is returning the required value.