Category: Weeknotes

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.

I did:

• Wrote up last week’s workshop with the Delivery Manager’s community which focused on reporting and conflict resolution.
• Talked about vibe, and using it for workshops as a way of setting shared expectations. My go-to vibe is ‘rocket dog’, a happy jack russell riding a rocket. To me, it means we’re going to do this at pace, jump around a bit, and stay positive.
• Started planning a workshop to design team responsibilities, mandate level, interactions, etc.
• Met my new line manager. Was good to talk through the product vision and possible routes for getting there over the next few years.
• Did some more market analysis and theory of change work on a new opportunity, and lined up getting buy-in from senior stakeholders.
• Talked about how Profession and Community complement each other, with Profession providing the top-down ‘what’ and the Community creating the bottom-up ‘how’.
• Got my ticket for ProductCon next week.

The numbers

Tasks completed: 37

Minutes in meetings: 825

I read/listened:

The Impact of AI on Product Management: A Systematic Review and Future Trends

The integration of AI has greatly increased its functionality in product management across innovation and market development from the initial concept to the actual market share. AI tools have helped product managers to improve traditional processes as it is an advanced tool which can analyze a large dataset, identify the patterns and facilitates to generate efficient strategies. AI product managers are essential in driving the identification of business problems best solved with AI, defining the overall strategic plan, and guaranteeing that AI is implemented ethically, safely, and with transparency and reliability. The paper provides an idea of what is an AI product manager, how does AI influences more traditional marketing models (B2B and B2C). These advancements accentuate how AI holds promise for constant enhancement and sustaining competitiveness in a rapidly changing market environment.

The challenges of studying in the ‘platformised’ university

University life is now increasingly mediated by digital platforms. Joe Noteboom’s research looks at the everyday realities of studying through platforms, and how students’ dependence on these technologies can lead to a number of problems.

Remote-first team interactions

The tragedy of the anticommons

The ‘tragedy of the anticommons‘ occurs when a resource has many owners, all of whom have the ability to exclude others from using it, leading to the under-utilization of that resource. I wonder if/how this happens in organisations?

I thought about:

Looking back

Thought about how hard it is to see progress in the moment and how it only makes sense when we look back. Maybe this is why product histories are so important for helping teams see how far they’ve come.

AI for product managers

Few things going around this week about AI and product so I thought I’d try to get some of my thoughts down.

I see three interconnected layers of AI.

Starting at the bottom is what’s going on with AI even if you do nothing. This is about having a way of dealing with any emerging tech. It includes horizon-scanning, market analysis, trends, behaviours, etc. It also includes how AI effects you and your users, because it will.

The middle layer is using AI in how we do our jobs, which for now probably just means using Gen AI and Machine Learning, but which will probably include Agent AI in the near future. Understanding how to use AI is like understanding how to use a mobile phone or email. It’s another tool we’ll use to do our work regardless of whether we use it well (I’m looking at you, email). So, we might as well apply some of that critical thinking and figure out how to use it well (when is it worth it for the environmental impact, for example).

The top, and most interesting layer, is how we might use AI in the products we build. I’d suggest we won’t do this very well if we aren’t doing the other two layers because we won’t have wide and deep contextual knowledge about how people are using AI more generally. This layer of AI also includes machine learning, image recognition, data analysis and decision-making, and all the other kinds of AI that is used in products without the user necessarily knowing. But they are still part of the product so product managers need to understand how they fit.

I did:

It’s groundhog day… again

It actually was, that isn’t a metaphor. Although we did talk metaphors, including changing the wheels on the car while we’re driving and steering the ship without speaking to the engine room. Other stuff happened too:

• Ran a skills development workshop with the delivery managers community.
• Finished writing a guide to looking for opportunities, writing hypotheses, and evaluating benefits for product managers. Now over to our coach to use it.
• Learned a bit about the B2B part of the university.
• Wrote three Theories of Change to express my hypotheses for new opportunities.
• Discussed what problems we’re actually trying to solve with coaching, mentoring, training, community-building, etc.
• Was asked, “Why do you stay?” Answered, “Interesting problems.”
• Chatted about the rogue work I do, the stuff that doesn’t have permission or oversight, the stuff that just tries to make things better but has a high chance of failure (which is most of it, TBF).

The numbers

Minutes in meetings: 705.

Tasks completed: 25.

(Over 4 days as I was on leave one day this week.)

OKRs at the product leaders group

Attended Tom Dolan‘s presentation about how they do OKRs at Which? I think OKRs allow teams to jump over organisational hierarchy and connect directly to strategy, so I find it really interesting to see how different organisations do OKRs, and Tom’s a believer in working in the open so his presentation was really interesting.

I read:

7 D’s

I read Kent J Macdonald post on using his 7 D model to deliver internal products. I used a similar model in my dissertation about the product development processes charities use. Since then I’ve expanded it to: direct, define, discover, due diligence, design, develop, deliver, distribute. I’ve haven’t gotten around to writing it up yet but I don’t think of it as phases, it’s more of a checklist of things to think about.

Agents

I love a good whitepaper. This one goes into how it is a “combination of reasoning, logic, and access to external information that are all connected to a Generative AI model [that] invokes the concept of an agent, or a program that extends beyond the standalone capabilities of a Generative AI model.”

And Steve wrote about how Agentic AI needs UCD smarts.

Can I suggest no one names their agent ‘Smith’, just in case.

Anything can be thought about as a product

But I’m not sure that means anything can be a product (let’s not get into trying to define a product). Using product thinking to uncover worthwhile problems and hypotheses about how to solve them is definitely generally applicable.

Efficiency obsession

The shift from making sure everyone is working hard to maximising the flow of work is part of the transformation (along with the shift from outputs to outcomes, functional teams to cross-functional teams, etc., etc.) My pondering is; who’s job is it? Which role in a team is responsible for focusing on flow?

Love newsletters? You’re gonna love RSS

Andy Bell wrote about using an RSS reader to know when the people you want to read publish their posts and newsletters (which I read in my RSS reader).

Here’s the OPML file of all the newsletters, websites and blogs I’m currently following.

I thought about:

Conflict resolution, and other skills

After a conversation about skills like conflict resolution, I thought about how people might learn such highly technical (by which I mean need lots of expert knowledge), soft skills (by which I mean not easily quantifiable and measurable).

Empowered team leadership

There doesn’t seem to be enough written and talked about for how to lead empowered teams. I think that kind of leadership is rooted in a coaching approach, it that creates and holds space for the team, it doesn’t have the answers but tries to help the team ask the right questions.

Two types of product managers

I remembered a conversation with Michael Wilkinson from a while ago where he said that there are two types of journalists; those that are good at finding stories and whose that are good at writing stories. I was thinking something similar about product managers. Some are good at finding problems, some are good at solving problems.

In numerology, the number 444 represents clarity, stability and progress. So, we’ll go with that.

This week I did:

Horizons

It’s been a week of thinking in horizons, some near, many farther away, but doing the do included…

• Worked on some market research and business model options for a potential new product.
• Ran a workshop to help a team focus in on some measurable work.
• Went to a workshop about mapping capabilities and matching investment to where the competitive advantage is.
• Presented to our engineering director.
• Reviewed a theory of change so it’s ready to build an evaluation plan for a series of changes to a product.
• Chatted about show and tells, and shared boring magic’s post.

This week’s numbers

Number of minutes in meetings: 685.

Number of tasks completed: 35.

My new work tracking system is working pretty well. I still struggle with planning my week but that’s probably more to do with the uncertainty and pace of the environment rather than the system (although I guess you could say it’s not a very good system if it can’t handle the environment it operates in).

I read:

How to create a Real (Strategic) Roadmap

Saeed Khan published two articles on how to create a Real (Strategic) Roadmap:

Part 1 & Part 2

As always, I’m a bit torn. On one hand I agree with the product profession developing it’s practice and coming up with standard ways of doing great product work. But on the other hand, I’m not keen on the idea that there is only one way to do things like using a roadmap. I think organisations have such diverse situations and needs that flexibility in practices is a good thing. As I’ve said before: experiment → optimise → standardise.

Does the service standard work for local government

Phil’s answer is no. And he goes on to suggest some really useful improvements that could make it work. I think there’s a lot there for universities to learn from in using “a” service standard to assess products and services.

Architecture Modernization: Aligning Software, Strategy & Structure

Impact of Facilitation on Performance & Innovation

This looks like a cool site, especially for delivery manager.

I thought about:

Governance systems

I thought about governance and the system needed to govern well (because I’m cool like that).

ISO 37000, the standard for governance, is a good place to start to get a shared understanding of what governance systems need to do, things like accountability, value model, and viability and performance over time. It helps keep governance groups focused on their key outcomes of effective performance, responsible stewardship and ethical behaviour.

And on the systems side, I was thinking about Ashby’s Law of Requisite Variety and how it states that a system must be as complex or more complex than its environment to function effectively.

So, if a governance system “is to be able to deal successfully with the diversity of challenges that its environment produces, then it needs to have a repertoire of responses which is (at least) as nuanced as the problems thrown up by the environment. Or, to put it another way, a viable governance system is one that can handle the variability of its environment.” The more complex the environment, the more a governance system needs ways to monitor the environment, spot changes quickly, and have responses.

Given that most governance systems in organisations are slow, bureaucratic and generally have information flowing one way, I’m pretty sure they don’t adhere to Ashby’s Law. And that’s a problem.

Alignment practices

Thought about what we product people actually do to keep things aligned with teams and stakeholders, including:

• Using easy to remember and repeat statements and slogans.
• Writing follow-up notes after meetings and drop them into chat or email.
• Listening out for misunderstanding.
• Arranging and offering check-ins to create space for people to uncover misunderstandings they might not have realised they have (and so you aren’t telling all the time).

The medium is the message

The format we use to share information matters. In my head, its more important if it’s in an email rather than a chat message, a slide deck tells me you want me to listen to what you want to tell me, and a document suggests you want comments and to work on something together.

I did:

Diagnosis

Seemed like this week was about diagnosing some of the challenges we’re facing, which reminded me of Janice Fraser’s idea of product management as differential diagnosis. And I…

• Took part in some technology strategy workshops.
• Talked about how we manage risks and wrote a proposal for how to improve it.
• Said goodbye to the awesome Kate Ivey-Williams.
• Chatted to the delivery management community about delivery managing delivery management.
• And to our product coach about product managing product coaching.
• Met our new Group Product Lead.
• Prepared for a prioritisation workshop based on theory of constraints.

The numbers

Spent 1260 minutes in meetings.

Completed 39 tasks.

Bluesky

Finally got around to verifying my domain name as my Bluesky handle.

I read:

Decarbonising user journeys

James Chudley wrote a presentation about why we need to urgently decarbonise the internet, the thinking behind his approach and explains how you can start to decarbonise your own user journeys.

What Makes a Good Team?

Cate wrote a list of what makes a good team.

Taking a platform approach to help people interact with Royal Greenwich online

Ste Shine and Alex Sturtivant wrote about creating a platform that consists of reusable capabilities.

I thought about:

Adjacent possible and path dependency

Adjacent possible and path dependency seem like two important ideas for organisational change. The next step in any change is defined by the adjacent possible. If that step is too big or radical, it’ll fail. And as a few of those steps are taken they create a path dependency that is difficult to turn away from. Both of these tell me that organisational change might be better done continuously rather transformationally.