Month: March 2025

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.