Month: February 2025

I did:

Thinking about things

A lot of my job is thinking about things. Even though I track all my tasks and meetings and can report on which of my objectives they contribute to, these outputs don’t really show where my time and energy goes or what it achieves. I might be fooling myself, but I like to think of my work as dialectical, moving ideas forward to reach a logical conclusion. This week, that included:

• Presented to a few senior leaders about delivery management.
• Delivered a workshop to design monitoring solutions across our tech stack.
• Planned a workshop to figure out team responsibilities and structures. Thinking about the end-state, how we get there, how it matches up with the roadmap, etc.
• Chatted about strategy choices using Martin’s ‘where to play and how win’ and Porter’s generic strategy model. Martin seems to fit better for established products navigating market changes and Porter is more for useful for entering new markets, so both are useful at the moment.
• Started talking about new opportunities in the B2B space and further up our onboarding funnel.
• Wrote an overview doc for future piece of work. It’s nice to actually create an output sometimes.
• Thought about our roadmap, how we use it, what needs it meets, and how it can be more useful.
• Our AI team won an award.

The numbers

Tasks completed: 35

Minutes in meetings: 825

ProductCon

I went to ProductCon London 2025 last week. It’s been ages since I’ve been to a big conference like this but it’s always interesting to hear about other products in other organisations. My three takeaways were that product management is becoming more responsible for revenue and not just tech, AI is starting to find it’s place in organisational workflow rather than in user interfaces, and keeping pace with technology change is a challenge everywhere.

I read and thought about:

Engineering Our Wicked Problems

Wicked problems come about when hard, soft and messy problems come together. It’s an interesting way to break down and understand wicked problems that I’ve never seen before.

Six questions for managing any project

Answering questions to make choices explicit is a great way to bring some clarity to a project. And starting with user needs is always good. I also like the explanation of which methodology to use based on the evolution of the thing being developed. Agile works well in the experimentation space, but it’s too costly to use when optimising and makes no sense when optimising or standardising. Lean is good when optimising. Six Sigma is good for standardisation.

Rethinking funding and development

Whilst I generally agree that funding distinct systems leads to dysfunctional organisational behaviours, it doesn’t necessarily follow that funding some other ‘thing’ resolves the problems. It’s easy to fund systems because they have a cost (software licenses, people’s time, etc.), but you can’t fund meeting a user need because you can’t say how much a user need costs, and our whole concept of accounting is based on balancing cost/investment and value/return. So, as we can’t fund meeting user needs, instead we fund proxies, i.e., teams that meet user needs. But creates a whole new problem because teams are expensive, so it doesn’t make sense to have one team per system or capability. It isn’t clear to me how an alternative funding model would actually work.

(Also, I don’t agree that product development is building tech – product is not tech – but that’s a different point).

Drag factors

John Cutler posted some steps to get teams looking at metrics. It immediately made me think about the drag factors something like this might face; things like, we don’t have the data, we can’t agree on definitions, who ‘owns’ this, what about that other priority, etc., etc. I think about these kinds of things as drag rather than blockers because they are hard to point to as a distinct problem to be solved, they are just the molasses all us gold fish are swimming in.

I did:

Knowledge sharing

If there’s a theme for this week (and it might just be in my head) then it’s about gaining, sharing and questioning knowledge.

• Planned a workshop on team responsibilities loosely based around Team Topologies.
• Presented the final version of my ‘Product manager’s guide to looking for opportunities, writing hypotheses and creating benefits cases’ and talked about how we start using it.
• Talked about estimates and principle-based agile. And then put together a short primer on things like fast flow of change and Better Value Sooner Safer Happier.
• Chatted about some new discovery work coming up.
• Went to ProductCon London.
• Wrote the first draft of my script for a presentation next week.

The numbers

Minutes in meetings: 635.

Tasks completed: 21 (over four days).

Three ways for product managers to think about AI

Wrote about the three ways I think about AI as product manager; in the market, as a tool and in a product.

I’ve since been thinking about an addition for the section on ‘AI in a product’ that talks about product teams thinking about making their product usable by AI agents. For example, a carparking payment product might need a way for a user to grant an AI agent access to their account, to make data available in certain way, to handle errors the Agent AI might make, etc. I wonder how many teams working on transactional products are thinking about this.

I read:

Generative AI and education

This book, subtitled ‘Digital pedagogies, teaching innovation and learning design’, poses some interesting questions about the role of teachers, knowledge and authority that Gen AI raises. It says, “regardless of the exact shape or extent of the changes to come, we need to prepare ourselves for a world where humans and machines work in symbiosis, where the educator is no longer the single voice of authority but rather, for better or worse, one of many.”

I gave an AI agent edit access to my website

Fascinating proof of concept for using agent AI to automate website tasks.

User Needs Mapping

Very cool site providing a guide to user needs mapping.

I thought about:

The Ambiguity of AI

I had a vague thought in my sleep about a statement a bit like the definition of digital but for AI. If anyone wants to write it, let me know. If not I might get around to doing it myself.

Team capacity

We usually think about a team’s capacity in terms of time, so more people with more hours equals more capacity. But that’s quite an industrial-age perspective built on the expectation that people do the same activity over and over again. Maybe a more information-age way might be to consider team capacity as cognitive load, so the team capacity is limited to how much information they can make sense of at any one time. Someone might be working on one thing but it’s a really complicated thing that takes all their attention. Two people might be working on the same thing from different perspectives, so they need to keep hold of their understanding and be able to take on some of the other person’s perspective so be able to communicate. Like so much of the variability of the information-age, we don’t know how to measure cognitive load yet, but we have some useful ways to limit it by creating boundaries that match technology systems.