Category: Weeknotes

I did:

Unevenly distributed

The future is funny like that, but I like that I get to work on evening it out. Also this four-day week:

• Did some planning work for three pieces of slow moving work.
• Met our new engineering lead. She’s fantastic and I don’t envy her the task ahead.
• Discussed ways to assess features and functionality to help us understand where we might need to focus improvement work in the future.
• Validated some assumptions about team skill-sets.
• Listened to our product director talk about the Decision Stack, which was really interesting because I’ve done some previous thinking about it (here and here and here).
• Chatted to an interaction designer as I continue with my mission to meet everyone. We talked design systems and about whether interaction design will change if AI agents become more widely used.
• Talked about metaphors for product strategy, starting with Formula 1 teams making choices about tyres, suspension, gears, etc., to perform against competitors who are all in the same environment (race track) but have different resources and capabilities they have to make choices about. It also fits nicely because there are organisational choices in the R & D space about whether to invest in suspension or gears which affect the choices that can be made in the operational space (the team can’t leverage different gear ratios if the development didn’t focus on gear boxes).

I read:

Psychological Safety vs. High Standards: A Misunderstood Dynamic

This is a really interesting article about psychological safety, and presents a positive and helpful challenge to the argument that psychological safety is weakness. It shows how high psychological safety fits with high standards to create an environment that is constructively challenging.

Not product thinking

This is not product thinking. Product thinking is not about features and interfaces. I’ve seen a few of these perspectives recently. The “product vs service design” positioning is really unhelpful. It always tries to make one more important than the other, when really, both are essential perspectives for creating good products and services. Can’t we all just get along?

Agent-ready

I was thinking a few weeks ago about whether products teams are thinking about how to get their products ready for AI agents, and then Ben Whitfield-Heap gives me the answer.

It’s really good to see product people thinking about how agents will interact with their products because MCP is going to change things.

Systems loopiness

Doug Belshaw studied Systems Thinking at the Open University, and wrote and blog post about it, which was referenced in the Open University’s System Thinking community of practice. See? It’s all just one big looping system.

I thought:

Know what you bring

The role of a product manager is not standardisable or generalisable. It’s just too context-dependant for that. So, part of your job as a product manager is to do the intellectual and emotional work of figuring out how you best add value to your organisation. It should probably be a combination of what your organisation needs, what good industry practices you think can apply, and what your particular areas of interest and skills are. No two product managers are the same, and given the same product (in parallel universes), should develop it differently.

Open systems and feedback cycles

It’s good to see the discussion about the length of cycles continuing. Unfortunately, it seems to come down to what’s considered acceptable within an organisation rather than what would really work better.

Going deep, working in cycles is because we recognise that ambiguous product work exists in an open system. And one of the key characteristics of open systems, which makes them different to closed systems, is that they need feedback to achieve the goal. So we work in sprints to create a mechanism that brings that feedback into product development. If the product team can’t get any feedback, there’s very little point working in sprints (as they are working in a closed system). If they get feedback monthly or quarterly, then they should match the length of their sprints to that. Having two week sprints, because it seems like the done thing, but not getting feedback every two weeks creates a lot of admin overhead without much value.

It’s a similar problem for all product practices. Applying them in situations they weren’t designed for is wasteful. Understanding those practices deeply, why they are the way they are, what problems they are trying to solve, is essential for applying them well.

Why can there be only one?

Why do so many organisational structures have one person at the top? Companies, governments, militaries, etc., all have a single person to hold ultimate authority. Is that really the best way to run an organisation?

Nonprofit product

Got linked to from an MTP article.

I did:

Quiet week with lots of people out for the Easter holidays and I was only in for three days so I decided to focus mostly on my efforts to help product managers identify new opportunities, including:

• Joined-up some different threads between product-specific opportunity exploration within a team’s ability to prioritise, and the kind of opportunities that require leadership prioritisation and commitment before being assigned to a team.
• Created a copilot chatbot to help product managers assess opportunities.
• Started writing a presentation for our product community of practice, which I think will be about the intersection of ‘PM’s assessing opportunities’ and ‘using AI in product practice’, with the chatbot as the live example.
• Talked about testing approaches and how we start with best practices that the team can revise to fit their needs. Lots more to do around how teams should interact when they both need to test their work, governance, increasing people’s knowledge of testing, etc.
• Picked up some slow moving work, which made me think about what mechanisms drive our focus and how we lean into our ability switch between things.
• Spoke to one of our UX designers and information architecture specialists. It was a high-energy chat and I learned lots.
• Chatted to a product manager colleague about what making our products AI-first might look like in the near future.

The numbers

Time spent in meetings: 360.

Number of tasks completed: 22.

(Three day week)

Experiments with short prompts

I blogged my little experiment with short prompts. The idea is that rather than having to copy and paste an entire prompt into a chatbot, you can tell it to go to a webpage that has the full prompt, and it follows those instructions. It should provide a better user experience for finding out more about a topic after a workshop or using prompt libraries. The next experiment is to make the prompt on the web page more specific and see if that gets better results (thanks to Adam Gillett for his advice).

I read:

The Cybernetic Teammate

This paper examining how AI changes collaboration in teams shows that AI significantly enhances performance to the point where individuals with AI matched the performance of teams without AI, demonstrating that AI can effectively replicate certain benefits of human collaboration.

The tool or team mate question is an interesting one. What does it mean to treat AI as a team mate? Maybe the AI holds most of the power and does most of the work (because it has all the information and capability) and humans are it’s assistants helping to keep it on track. Maybe it’s like pair programming, where human and AI are pretty equal. Maybe it’s more like a digital assistant/infinite intern, where the AI is subordinate to the human. Maybe it’s more tool-like and less team-mate-like, where AI is used to perform a task but gets no recognition. It seems likely we will need to “rethink the very structure of collaborative work” to figure out how humans and AI work together, and how humans work with other humans when they no longer have specialist knowledge or contextual decision-making authority.

A2A

A little while ago I wrote about the need for product teams to think about building their products so agents can use them. The A2A protocol looks like a good step for that as it allows agents to interact with each other. Along with Anthrophic’s Model Context Protocol, which allows agents to interact with data systems, I can start to see a route for product teams to figure out how to make their product agent-ready.

Duolingo

This post poses an interesting question; are engagement and pedagogy so opposite that you have to choose one over the other, or is there a middle ground for a product that engages users and helps them learn?

Four week sprints

Kelly Lee wrote about a experiment her team did running four-week sprints rather than two. She shares lots of interesting insights into things the team needs to do to make four weekly cycles work.

I used to believe in the benefits in fixed timeboxes, but over the years I’ve seen more and more situations where it’s more of a hinderance than a help. Fixing the release cycle and then adjusting the work to match seems backwards to me. It seems arbitrary and like it doesn’t match the messiness of cross-functional team’s work. Some work takes a short amount of time, some work takes longer. Ship when done.

I thought:

Agile leadership

If we accept that agile is the steering wheel not the accelerator, then the first place in an organisation to try out agile transformation is with leaders, not with teams.

So the experiment for leaders to help them figure out if they are ready for an agile transformation is to make decisions on the day they are asked. If they think they don’t have enough information to make the decision, they still have to make it but they iterate on the information people bring until they always get what they need to make decisions quickly. If they learn they made the wrong decision, they make a different one (that’s the steering). If they can’t do this, they know other parts organisation aren’t going to become more agile either.

Good process, bad process

I’ve been thinking about where process is good and where it’s bad. When I say “process”, I mean a sequential set of actions designed to achieve a set goal. The scientific method is a process, so is double diamond. Some processes might be better at dealing with uncertainty than others, OODA, for example, but all processes have three things in common; multiple actions, performed sequentially, to achieve a goal.

With that definition in mind, process might not be helpful where the actions can’t be predicted ahead of time or the goal is unknown, basically in situations of uncertainty. In chaotic circumstances, the best approach is to take a step, look around, and choose the next step based on what you see.

Year one

This week was my one year workiversary. It’s been a pretty amazing year of learning and planting seeds that I’ll hope to grow in my second year. But this week I:

• Chatted about what it takes to create a high-performing team.
• Started chatting to user-centred design people (because I’ve met all the product people).
• Wrote up some thoughts a product strategy. I really need to find some time to blog about this.
• Helped plan a prioritisation workshop.
• Learned a bit more about how unit finance works.
• Got some early feedback on my opportunities presentation. I’m looking forward to encouraging product managers to spend more time looking outside the building and discovering worthwhile problems.
• Reflected on my first year doing product in higher education (which may become a blog post if I get the time).

The numbers

Tasks completed: 25

Minutes spent in meetings: 495

(Four day week.)

AI horizon scanner

Added more entries to my AI horizon scanner and added a Type column to make it easier to see what kind of resource it is. Still adding stuff as and when I find it and don’t yet have a system in place, so I need to figure that out, but it’s on the roadmap.

I read:

Making Better Product Decisions: Approaches and AI Prompts for Product Managers

I think critical thinking is a fundamental product skill, and good decision-making technique is built on top of that. In my experience, most product decisions aren’t made with robust logic because organisations and people are messy, but it’s still really good practice to be able to show your working out.

Sludge

“If you make things harder, I call that sludge. Kind of a fun word for stuff that’s the opposite of fun” – Richard Thaler on the Freakonomics podcast episodes about sludge, friction and administrative burden have been doing the rounds in some product circles.

Sludge, Part 1: The World Is Drowning in It

Sludge, Part 2: Is Government the Problem, or the Solution?

Trilly Chatterjee, head of product management at NHSE, has thoughts about it too.

Disruption

Doug Shapio’s talk at FutureWeek Forum is exactly the kind of analysis product manager’s should be looking at to think about how AI is going to disrupt their industry.

He talks about how the last great disruption to the media industry was the internet, which removed the distribution moat media companies used to have, and how Gen AI is the next great disruption which will remove the production moat. The disruption isn’t Hollywood using Gen AI to replace writers, it’s Gen AI replacing Hollywood.

There’s also an interesting point that if you are monetising attention and engagement, you are a media company. So does that make universities media companies? Education is more complex than entertainment, there’s more to unpack and disintermediate, because education provides knowledge, credibility, connections, etc., and arguably the institutions have far greater control over the status quo, but maybe the disruption isn’t universities using Gen AI to replace lecturers, it’s Gen AI replacing universities.

I thought:

There’s a prompt for that

Had a 5am thought about making Gen AI prompts part of documents, presentations and workshops to help people learn more about a topic. I might try it with the work I’m doing on opportunity assessment.

I haven’t tested it yet, but it would really help if a short prompt could tell the AI to go to a web page to get the full prompt. It would make for a better user experience between document and browser.

Pot holes

I vaguely remember hearing something on a podcast about using AI to improve road repairs. The point was that AI image detection can speed up identifying pot holes but that was never the slow part to fixing pot holes, it’s all other stuff of having enough budget to have enough teams with enough equipment to go out and fix the pot holes. So, yeah, it’s great that no-code and AI had a baby and now you can build a standalone application on your mobile just by sending a few chat messages. But building stuff was never the bottleneck to great products, so it’ll be interesting to see how AI changes all the other parts of product management (beyond summarising information). Maybe I should spend some time imagining that myself.

I did:

Opportunity knocks

This week has seen all kinds of opportunities coming up, some panning out and some not. Long may it continue, I say. I’m always up for doing something new.

Among lots of other things, I…

• Started talking about how we improve our testing capabilities.
• Worked on a training session for retros.
• Went to the product community of practice (it usually clashes with another meeting) about the craft of product management.
• Talked through some feedback on group product strategy and identifying the levers that allow us to achieve the change we want.
• Wrote a presentation on how product managers can look for new opportunities.
• Did data protection training.
• Signed up for AI product management training.

The numbers

• Completed 39 tasks, 12 of which contributed to my objectives.
• Spent 930 minutes in meetings.

I read:

How not to transform

It always amuses me when product people think product approaches are generalisable outside of managing products, especially for organisational change. Product management is not change management. It doesn’t work as a change methodology because it carries the inherent assumption that changes made, stay made. It has no mental model for understanding that in organisations things slip back to old ways, change gets undone.

If you want to change an organisation there is an entire body of knowledge with a long history about organisational design and change management. So, at the risk of stating the obvious, if you want to transform an organisation, or even just how it does product, turn to the disciplines that already know this stuff.

Opportunities

Brushed up on Opportunity Solution Trees and Assessing Product Opportunities, partly because I’m working on how we improve our ability to spot opportunities, and partly because they were mentioned in the Product Leaders group discussion on training. One of the things I’m puzzling is whether the deductive reasoning of OST is right for us as it starts with the outcome you want to achieve, which limits the opportunities you’ll come up with. Maybe it’s useful for analysis and grouping opportunities after you’ve understood them but I need something that is more about how to bring multiple diverse observations together into an idea for an opportunity.

Online and Distance Education for a Connected World

This book goes into a lot. But I’m interested in how distance and online learning meets product management, so hopefully it’ll help improve my knowledge and thinking.

I thought:

Pace layers

Brand’s idea of pace layers describes how change happens at different rates, with fashion being fastest and nature being slowest. I wonder if, actually all change is happening at the same speed but appears different because things like fashion have a simpler, clearer path to follow, whilst culture change follows more routes, has twists and turns and dead-ends, has more ground to cover. Does this change anything about how we approach change? Probably not, but it might be nice to get away from the sense of blame that comes with slow change.

Being clearer

I’ve been thinking about how to frame conversations around deciding what we want to achieve, and that includes defining my terms, recognising that unintentional things also occur

My definitions:

• Goals are general. They can be measurable and specific or vague and qualitative.
• Objectives are specific, measurable, intentional, and upfront subset of goals.
• Outcomes (a change in user behaviour that achieves business results (Seddon)) are a subset of goals that can be objectives (if they meet definition, particularly being intentional) but can also not be objectives if they occur unintentionally.

So, maybe it looks like this:

It gives me three ways to talk about the things we want to achieve to different audiences. Goals fit nicely when story-telling and showing how product work fits into bigger pictures. Objectives are used to talk about the effect we’re having and benefits we’re delivering. And Outcomes give us a way to bring the user into the discussion and show what we’re achieving for them.

I did:

Circle of influence

• Chatted about ways to prioritise work with a team, in particular using criteria as filters rather scores, so for example, any compliance work filters out first and goes to the top of the list, and whatever’s left goes through the next filter.
• Discussed product work in the opportunity space, and how the law of diminishing returns is the gotcha no one talks about for continuous improvement in the solution space.
• Spec’d some work to improve social media lead generation.
• Wrote about product strategy and how to approach creating a strategy that gives multiple products coherence and consistency, whilst giving individual products flexibility and change-over-time-ibility (that’s a word now). I like the definition of strategy of ‘using what we can control to affect what we can’t control’. So, thinking of it like Covey’s circles, the circle of control includes our people, their skills, the tech, etc., the circle of concern has our goals and the problems we want to solve, and then between them in the circle of influence is our strategy that says how the things we build will solve the problems. It’s the bridge between the known and unknown.
• Tried to figure out how to talk about uncertain, emergent things without creating more uncertainty… and failed. My framing/lens/angle/whatever was around how we change what gets fixed and what flexes in response. So, if we think of a tech-driven process as fixed, then the humans have to flex around it when an edge case comes up or a piece of the process doesn’t work. The shift is making the tech flex to different scenarios (using automated decision-making), so that the humans have more of a fixed role to play in the process, which means then they can spend more time doing more interesting things.
• Since I’ve chatted to all the product people across the org, I’m going to carry on and meet all the designers and developers too. I still think one-on-one conversations are the most powerful culture-changer, and it would be awesome to be the only person who has met everyone in our directorate.
• Looked into doing some training, which made me think about how we might identify our blind spots (I know about product management, and I know a bit about AI, so I must know about AI product management, right?). And started Red Hat’s AI Foundations Executive Certificate.

The numbers

Tasks completed: 29.

Minutes spent in meetings: 555.

(Over four days as I took a day off this week).

I read:

Learn wherever the lessons are

Rachel Caldicot, in preparation for presenting to the Science, Innovation and Technology Select Committee’s inquiry into the digital centre of government, started a really interesting thread on the difference between public and private services.

It’s interesting to me because of the perceived (and, I think, ultimately false) duality between commercial and public services, because where I work is a social good organisation that needs to make money to carry on doing social good. Slightly different angle, but a few years ago when the charity sector was in crisis (yes, another one) about social movements taking over some of their territory, I did some analysis of different types of organisations, from social movements that do good but are less ‘organised’ (from a legal perspective), to charities that do good and are organised (which makes them accountable), to socially-conscious businesses that do good because they choose to. The point is, it’s a messy spectrum, not a duality.

My other thought is that the discussion is often about how public services aren’t like private companies, but doesn’t say why they shouldn’t be (I’m not arguing they should be, just thinking through the argument). Public services aren’t perfect. Private companies aren’t perfect. Wouldn’t it be better for everyone to learn from everyone else, find the things that work for them?

Design for a Small Planet

I like Scott Jenson’s thinking about how design thrives in increasingly resource-constrained environments (AKA companies that don’t always see the value of design). The question is how to do design in a more resource-efficient way. Scott’s theory is that “much of our classic “Big Design” process is too insular and a bit too heavy.” And that the solution involves making design “feel smaller, lighter… less opaque”. It’s hard not to fall into the speed vs quality trap, but I think making more conscious trade-off decisions helps (same applies to product, tech, etc., not just design). Personally, I’ve seen lots of time and effort invested to tackle small problems, and not been able to convince people to invest proportionately (bad product manager).

AI power

This week’s book is Building AI-Powered Products by Marily Nika.

I thought about:

Mean-time-to-impact

What’s the average time it takes a team to go from idea to impact. And what would you measure in between idea and impact? Mean-time-to-investment for the opportunity space? Mean-time-to-evidence for discovery? Mean-time-to-behaviour-change for outcomes?

I am not a number

In fact, I am lots of numbers. Pretty much every system that holds a record for you gives you a unique identification number. That means you have thousands of unique and independent ID’s associated with you throughout your life.

How to approach different types of work

Treating all work-in-progress the same is a bit silly because all work is not the same.

	Fast progress	Slow progress
High priority	The oven (with a glass door so we can see what’s cooking). Focus. Track closely.	The slow cooker. The complex stuff. Check on it regularly but give it time.
Low priority	The microwave (gets done quickly but without finesse). Track loosely.	The back burner. The stuff you’ll probably need in future. Keep an occasional eye on it.

(That was actually meant to be more serious than it turned out but the cooking metaphor took over)

I did:

Gradually, then suddenly

Hemmingway’s phrase came up a few times this week, and it nicely describes change; how we experience it and how we make it happen.

• Facilitated a workshop to define future team structures.
• Talked about how we might build up our ability to spot opportunities and what we need to do to be able to jump on them once we’ve spotted them.
• Went to a strategy session. Made me think we don’t need a strategy, we need strategy-agnostic business architecture that still works when strategy changes.
• Got involved in some support tickets to try to understand how that side of things works.
• Started designing training in how to run retros.
• Had a meeting in the woods. It was like the old days.

The numbers

Tasks completed: 30.

Minutes in meetings: 705.

I started tracking my quarterly objectives, and after just one week it’s clear that most of my work doesn’t contribute to them. Might have to do something about that.

Something to think about

Spent some time thinking about ways to help product managers learn, and make use of the thousands of links to articles, blog posts and videos I’ve collected over the years. Maybe it could be some kind of daily prompt for micro learning.

There was a time when I would have jumped straight to building it, but nowadays I’m more considered and cautious of how I commit my time. Or to put it another way, I haven’t actually done anything about it.

I read/listened to:

When to pivot

Researcher Rita McGrath of Columbia University explains inflection points, why we fail to see impending moments of upheaval, and what we can do to be more adept at spotting them.

Impact-first product teams

I started reading Matt LeMay’s new book, and I have to say, it’s as good as everyone says it is. It has simple ‘this, not that’ way of explaining the difference between impact-first teams and low-impact teams that creates a useful mental model for simple brains like mine.

Waterfall is never the right approach

Regular feedback, no hand-offs, small batches, creating shared understanding as you go, accepting what you don’t know, not working in isolation. Is that too much to ask?

I thought about:

Ownership

Ownership is such a messy thing, no wonder it causes confusion. Even between two teams there are lots of scenarios:

Team A	Team B
Thinks Team A owns it	Thinks Team B owns it
Thinks Team B owns it	Thinks Team B owns it
Thinks Team B owns it	Thinks Team A owns it
Doesn’t know who owns it	Thinks Team A owns it
Thinks some other team owns it	Thinks some other team owns it
Thinks some other team owns ‘that’ bit of it.	Doesn’t know which team owns ‘that’ bit of it.
Doesn’t know who owns it	Doesn’t know who owns it

Product, Project, Platform

Don’t really know what I’m trying to say here, just collecting thoughts in progress (TIP™)

	Product	Project	Platform
Goals	Outcomes – change in user behaviour that achieves business results.	Outputs – expected and planned deliverables.	Orchestration – interactions and transactions.
Patterns	Vision, strategy, opportunities. Iterative change.	Scope, time, cost. Upfront plan. Big bang change.	Healthy ecosystem. Strategy-agnostic. Network effects. Standardisation.
Antipatterns	No discovery.	Variances – unexpected changes that go against the plan.	Non-scalable single-point solutions.
Deadline	Time-to-value.	Time-to-delivery.	Time-to-coverage.
Adoption mechanism	Value proposition, maintaining or increasing user value.	Management, marketing.	Policy, monopoly, seeding, critical mass.

Making things self-explanatory

If you need to explain how to interpret documents, spreadsheets, miro boards, etc., then you aren’t designing them very well. A simple ‘rule’ for making things self-explanatory is to follow other common conventions: Time flows left to right, bigger things are more important than smaller things, red is a warning.

Step-by-step

I keep going back to the idea of writing simple step-by-step plans for doing a piece of work. Doing it often reveals that we don’t know how to get from where we are to where we want to get to. And then we wonder why work feels so uncertain and reactive. It’s a skill worth practicing.

I did:

• Talked through some ideas on how to help product managers go looking for worthwhile problems.
• Used the theory of change and the business model canvas to describe a future opportunity.
• Chatted to a project manager about some work they are doing and that I might take over product managing when the project ends.
• Thought a bit about the difference between products and platforms.
• Did some analysis on leadership models to help us think about future needs.
• Read a market analysis report which made me think about ‘where to play’ strategy choices.
• Finished planning a workshop for next week.
• Started applying for an MBA.

The numbers

Tasks completed: 36

Minutes in meetings: 585

Anchors and AI

I setup anchor links for headings on my website to make it easier to link to things in my weeknotes.

And added more to my AI horizon scanner. I’m now up to 50 entries going back to 2015.

I read/watched:

Public sector AI week

Watched some of the talks for public sector AI week.

AI-driven business model innovation: A systematic review and research agenda

This is the kind of thing product managers should be reading about AI. It suggests companies are approaching AI from a technology application perspective and not giving enough consideration of the business model.

The state of product management

I read ProductPlan’s state of product management 2025 report.

Three highlights:

• Product strategy is a central focus
• Product teams favor tool consolidation
• AI is more prevalent and more concerning

Systems thinking differently

Watched a presentation on systems thinking by one of my colleagues. They talked about how “high performing, adaptable organisations recognise the importance of continuous evolutionary change in response to the changing external and internal environmental conditions”.

I thought about:

Unit of energy

I prefer to think about work as using my energy rather than using my time. I don’t judge a day’s work by the number of hours spent on my laptop, I judge it by how drained or energised I feel.

But I’ve been thinking about how time and energy fit together. Most meetings are 30 or 60 minutes, which gives us an average of 45 minutes. With breaks and interruptions, that gives us 8 blocks of 45 minutes a day, and not entirely coincidentally, I average 7 tasks completed a day. So maybe one unit of energy equates to 45 minutes. Sometimes it’s focused energy, like in a meeting, and sometimes it’s spread over the day.

Flexible working

Maybe the shift in work being more flexible is (or at least should be) rooted in the definition of work being more flexible. Maybe it used to be that our definition of work was more fixed. It only happened at the workplace, during work hours. But nowadays, with more work being knowledge work, what we define as work should be more flexible. If I think about work as I’m taking a walk, am I working? If I read a book one evening to improve my professional knowledge, am I working?

I did:

Timing

So much of success is down to timing. Too early and there isn’t enough impetus or incentive, too late and the opportunity is missed. Timing doesn’t get talked about enough in product management, and now, next, later doesn’t cut it. Other stuff this week:

• Planned a workshop for exploring responsibilities in and across teams.
• Updated our roadmap, by which I mean the data we use to analyse opportunities, not just how we visualise things.
• Talked about the difference between revenue-generating product work and revenue-protecting work, and how new revenue-generating work has to be marketable, it has to change the offer, making it more attractive to potential customers.
• Went to strategy workshop to explore communication systems and where we want to get them to. It helped me think about internal and external coherence.
• Met some colleagues from the B2B side of the org to talk about exploring new opportunities.
• Wrote up some future work that connects existing users with potential future users to create an advocacy loop.
• Chatted to another product person. I’m going to have to go on to product-adjacent people soon.
• Talked about my objectives and the kind of product work I want to focus on this year.

What’s happening in AI

Started working on a kind of AI horizon scanner for product managers working in the UK public, higher education and charity sectors. It’s very basic and manual at the moment (and still quite empty), and there must be a better way of doing it, but for now I want to see what trends I can understand from what’s going on. My hypothesis is that AI isn’t going to generate the expected economic benefits for many years to come.

I read/listened to:

To Change or Not To Change: That is Not The Question

I found this article really interesting. Even if kind of states the obvious – that organisations need to balance responding to change and gaining quick wins with developing a long-term advantage – it’s good to see it thought through like that.

I’ve been thinking about strategy playbooks recently, and the kind of strategic questions that would have to be answered to decide on the play. Is this a throwaway quick win or an enduring investment seem like important questions, particularly with my thing about ‘experiment, optimise, standardise’ and picking the right evolution for a product, i.e., don’t bother standardising something you know to be temporary.

Citation as pilgrimage

“Do you owe other people your knowledge? I think my answer is yes. We do owe each other. Why? Because my mind was built with other people’s knowledge… It puts me on the map, it puts me on other people’s maps.”

As I think more about dialectic practice in product management, the idea of citing our sources to give our ideas providence and those who informed us their due, matters more and more.

Stories

Story-telling is one of those product skills that often gets talked about but is hard to put into practice. This podcast, part one and part two, have some interesting insights into why and how stories work in our brains and our culture.

Not about technology

Completely agree with this. Whether it’s 21st century government, higher education, charity or business, a wholesale change is required to exist and be effective in a permacrisis world. That isn’t just about funding delivery in a different way; it’s about different ways of thinking, changing who has power, relationships between organisations, network-based business and operating logics and models. But this change will take hundreds of years to play out.

I thought about:

Three evolutions

The three evolutions for a product are experimentation, optimisation, and standardisation.

Experiments are great for learning how to tackle new, ambiguous problems but they are costly with almost no financial return. Agile is a good approach here, with cross-functional teams able to learn quickly how to affect the problem they’re tackling. But cross-functional teams and multiple experiments can be expensive so aren’t the right mode for managing a product over the long-term.

Optimisations are about doubling down on the experiments that worked. Lean is a good methodology in this evolution with it’s focus on continuous improvement, but that has diminishing returns which means we can’t optimise forever and which leads to the next evolution.

Standardisation is the final evolution. It’s about building efficiency in having figured out how to be effective in earlier evolutions. Six Sigma is the right kind of approach here as it’s about reducing variation. This phase establishes good practice and policy to achieve consistency.

The main point is that, given the financial constraints every organisation is facing, they can’t apply the same mindset and methodology to every problem, situation or opportunity. Organisations trying to introduce agile as a single methodology for dealing with every situation will find it expensive and ineffective if the product actually requires standardisation.

Dialectical product practice

Whenever anyone talks about the skills product managers need it’s usually not product skills but organisational navigation skills, things like communicating, aligning, influencing. I think it matters how product managers do this kind of work, and I think a dialectic approach fits best.

Dialectic is “a form of reasoning based on arguments and counter-arguments, advocating propositions (theses) and counter-propositions (antitheses). The outcome of such a dialectic might be the refutation of a relevant proposition, or a synthesis, a combination of the opposing assertions.” It’s about allowing people to hold different points of view and help them arrive at the truth through reasoned argument. Whenever we talk about data-driven decision-making, evidence, critical thinking, etc., we’re talking about being dialectic.

If we stray into making emotional arguments to convince others of our position, we lose the robustness and validity that a dialectic approach brings, and I think, undermine something special about product management.

Outcomes-based roadmaps

Products don’t achieve user’s outcomes, products change user’s behaviour and it’s that change that achieves outcomes.

This is important to understand when thinking about outcomes-based roadmaps that connect and communicate how a product changes over time to changes in user behaviour in ways that achieves business results (Seiden, 2019).

The product management problem is to figure out which behaviours lead to the intended outcomes, and then what changes can be made in the product to make those behaviours more likely.

Outcomes-based roadmaps can show the changes in many ways; as thresholds in user behaviour (x% doing y action), as hypotheses (if users do x behaviour, then y outcome will be achieved), as opportunities to explore how to encourage new user behaviours (new feature), etc.

Although outcomes aren’t measurable, user behaviour within a product is. That behaviour might be logging-in, clicking links, submitting a form, etc., whatever is causally connected with the outcomes.

Mapping role responsibilities over sociotechnical system

Messy and incomplete, obviously, but I was thinking about who’s responsible for the different aspects of a sociotechnical system. Arguably, everyone is responsible for culture. Who should be responsible for processes and procedures?

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.