Author: Roger

I did:

Half-time

The bank holiday, a day on campus and a day at Product for the People made it like a two-and-a-half day week.

• Met our new product manager.
• Took part in a retro.
• Set out some direction for scaling a new product we’ve been working on. It’s looking like it’s got a bright future ahead of it.
• Chatted about product managers learning and what I can do to help.
• Presented at our product community meetup.
• Started writing up some thoughts on platform product practice development.
• Set up more of my AI PM OS. Access to reporting data is a problem, but my scheduled prompts are running well. The important thing now is getting writing to where it needs to be for AI to use it.

Product for the people

It was amazing.

A bunch of product and product-adjacent people in a room talking about product and eating donuts. What more could you want.

Debbie, Jukesie and Steve get all my appreciation for organising it.

I read:

Start and finish more initiatives

Ben talks about applying limits at the right level to make work completable.

He made me think about how we treat blockers. The usual assumption is that if a developer becomes blocked, they stop working on that thing until someone else does the work to unblock them. Makes sense because you want to make the most of the developers specialist skill of writing code. Or does it? Maybe it makes more sense for the developer to expand their skills and knowledge in ways that might prevent future blockers. That might be knowing which team to speak to, knowing how other systems work, understanding how stakeholders view risks, learning a new skill that allows them to tackle a problem in a different way.

Treating blockers as a different type of work that is handled off to someone else is falling into the trap of the old industrial mindset. It’s not how modern product teams should work. Unblocking the work is the work.

DHCW Vaccine Service roadmap

Beautiful roadmap from Digital Health and Care Wales.

An old friend of mine used to say, “The more you look, the more you see.” He meant that, for things like public roadmaps, what gets shown tells you a lot about what’s going on behind it to be able show it. In the case of DHCW’s roadmap, it’s not just that they are doing fantastic work, it’s that they are doing the hard work to make the fantastic work open.

I thought:

Opportunity analysis

I thought a lot about opportunity analysis. I really believe that finding worthwhile problems is an important part of product management but so often skipped over. Some of my thoughts on opportunity analysis are:

• Separate opportunity from implementation from benefit realisation. An opportunity can look good on paper but be poorly implemented and so fail to get the benefits, but the value potential was still there.
• Analysis is a comparison of opportunities, not a promise to deliver.
• Define different types of value.
• Calculate the same types of value in a consistent way.
• It’s not a backlog, it’s not committed work. It’s to decide if an idea is worth going on the backlog.
• Finding the right methodology is hard. Comparing very different things in the same way to reach a balanced perspective is impossible. The only way I found is to categorise similar things and then compare them to each other.

Effective first, efficient later

Achieving outcomes is expensive. If I had to guess, I’d say at least three and half times as expensive as delivering outputs. Maybe, in time, achieving outcomes can become cheaper but in the meantime, “effective first, efficient later” should be the mantra of being more outcomes-focused. Get better at dealing with the uncertainty inherent in outcomes, understand the time and skills required for iterative improvement towards being less wrong, build better measurement capabilities to know if your moving towards achieving outcomes. Once you can do that stuff well, then optimise it.

Dumbo’s feather

Or, belief affects behaviour. What we believe to be true, about ourselves and our world, affects what actions we take. So, if we want to change behaviour we have to consider beliefs.

I did:

Creating the conditions

Lots of conversations around the topic of creating the conditions for good work this week. It’s hard because it’s never clear where the problems are and we don’t have the language to describe what needs to be done. But it’s worth it. Also did this stuff…

• Interviews for a content design role in one of our service teams. I’m always the hardest scorer.
• Presented the work I’ve been doing on using AI for product strategy to the other product managers.
• Wrote numerous documents as I continue my one-man mission to move from an oral culture to a written one. They included an onboarding guide, context for a show and tell, and ideas for a product strategy.
• Launched automated reminder emails with the hypothesis that timeliness matters.
• Set up a co-writing workshop with product managers to help us develop a consistent tone of voice for how we talk about our products.
• Set up more of my personal AI OS, including helping with planning at the start of the week, writing reports at the end and looking for gaps in my product documentation.

This week’s numbers

I haven’t looked at my dashboard in a while, so here’s some numbers:

• Completed 52 tasks across 9 projects this week.
• Spoke to 44 people.
• Spent 905 minutes in meetings.
• The number of minutes I’ve spent in meetings since I started tracking my time went over 75,000 this week. That’s over 130 days straight.

I read:

Continuous discovery

Wonderful explanation of why continuous discovery matters. “Perhaps the greatest value of continuous discovery is that it creates a culture of ongoing learning. Rather than treating research as a phase that ends when a service launches, it becomes an integral part of managing and improving the service throughout its lifecycle.” Yes, yes, yes.

(Thanks Benjy Stanton for the link)

The future isn’t multidisciplinary

Jack Strachan writes about how teams and professions work together (in both senses of the word, “work”). He covers a lot, including different ways of organising, and how, “boundaries around that craft can be permeable enough for people to contribute past them, while still knowing where their expertise ends and when somebody with deeper knowledge needs to come in”.

Increasingly, I think dynamic reteaming is the best way to organise teams in complex and resource-constrained environments to tackle urgent, intractable problems.

(Thanks James Green for the link)

AI and Education

MIT’s AI and Education report is really interesting (if you’re into AI and education, that is). One of parts that grabbed my attention was, “Leaning into learning means creating a new “social contract” between teachers and students. All of us who teach at MIT will need to be prepared to help students understand both that the process of education is necessarily a productive struggle, and that the most important product of their education is not a GPA or a diploma but themselves: their personal growth and intellectual maturity and the development of their own imagination, insight, and judgment.” Outside of the education sector, it’s plausible that AI will go further and completely change our relationship with information and knowledge.

I thought:

Simple, complicated and complex work

I’ve been thinking about how we might group different types of work to provide a pattern for organising around it, and the Cynefin Framework offers something very useful:

• Simple – There is a clear, linear link between cause and effect, where the same actions consistently yield the same outcomes, a connection that is widely accepted and undisputed. Things like password resets are this type of work. Once you’ve figured it out once, you can repeat it.
• Complicated – There is a clear, linear cause‑and‑effect relationship, though multiple solutions may exist and choosing the right one depends on expert advice. Most issues are this type or work. Every issue is different and can only be figured out by getting the right people together. I reckon there are efficiencies to be gained from not treating simple work as complicated.
• Complex – Cause and effect are unclear, so solutions only emerge through action. Small, safe‑to‑fail experiments reveal possibilities and gradually make the space more manageable. This is where most product work fits.

There’s probably an ideal volume ratio between these types of work where simple is high volume and complex is low volume.

From oral culture to writing culture

Oral cultures, where information, knowledge and decisions live in conversations and create no tangible record suffer from a lot of context loss. Only those in the room get the full context, and every communication step away from that original conversation losses more and more nuance.

When organisations have a writing culture, and information is more available to everyone asynchronously, any context contained in the writing is maintained.

As AI becomes more pervasive in the workplace whether we have conversations and let AI do the writing, or we do the writing which AI uses as a source, will affect. Personally, I’d rather be telling AI what I think rather than AI telling me what others think.

Roles, responsibilities and relationships

Roles and responsibilities are fine but they are always miss the important stuff; relationships.

Roles and responsibilities treat individuals as isolated, contained, and fixed. The assumption is that, once written down, someone’s responsibility stays the same. And, like cogs in a machine, if everyone sticks to their responsibilities then the machine will keep working. It’s an idea for bygone age.

Introducing relationships into the mix recognises that the connections between those individuals matter. Someone’s responsibilities change depending on who they are working with. Their role changes over time as they learn more. Building in change makes things more robust.

I did:

In-between

We’ve been finishing off the things we were focused on last quarter and getting ready for this quarter. Its not a lull exactly, it’s a different type of work. It’s about reflecting, analysing, improving, preparing. It’s necessary, and it gives me a bit more time to catch-up on some other things, such as:

• Presented a prototype for a north star metric dashboard. It didn’t go down well, but perhaps helps highlight the important questions we haven’t answered (see below for more on the creating ‘a thing’ trap).
• Started trying to figure out how we might calculate opportunity cost and cost of delay.
• Went to a retro about last quarter.
• Chatted about the challenges of showing how far we’ve progressed towards our goals when products are never finished and the goals have to be achieved continuously.
• Wrote an onboarding document for a product manager joining us in a few weeks.
• Talked about roadmaps (so it was lucky James shared the NHS app roadmap and Jukesie shared his roadmap readme).
• Chatted with some colleagues who are leaving. We’re going to miss them.

I read:

Zero distance, zero boundaries

This is a really interesting idea, very over-simplified, but interesting nonetheless, about how bureaucracy, delayed communication and diffused responsibility lead to organisational failure. And how getting close to customers and removing internal silos solves that problem.

(Thanks to Jason Yip for the link.)

Agile is dead. Long live S2S

All kinds of stuff going on in this post, but the thing that caught my attention was the statement, “ceremony doesn’t scale with speed”. Pete goes on the say, “Standups, sprint planning, backlogs, wikis, and retros, these were already fragile abstractions. With AI, they become actively counterproductive. Agile assumes roughly uniform execution speed across a team. AI obliterates that assumption. Some people move an order of magnitude faster than others, not because they’re better engineers, but because they’re fluent in a new mode of work. The process cannot absorb that variance without becoming drag.”

Obviously this ignores the need for coordination and alignment, but it’s interesting to think about what difference AI might make to how teams organise, particularly around time management as AI doesn’t sleep or take breaks.

AI PM OS

I’m really interested in figuring out what an AI product operating system might look like for me and the teams I work with, partly because it forces us to consider and codify what we do. So, I read The Future of Product Teams and Motorway’s AI-powered product management workspace.

I thought:

POM BOM

It occurred to me that product operating model design is fundamentally a question of return on investment. If you have a fixed operating budget, then you need to design your operating model to work within that. It’s pointless designing an operating model that takes £50 million a year to run if you’ve only got £20 million to spend. You’ve failed before you’ve begun. And you need to know what kind of revenue the operating model needs to generate, at what kind of margin, so you can design for achieving that. Most of what you read about product operating models talks about the design, not the constraints, but product operating models sit in the middle of the value stick. Product operating models must reflect the business operating model.

Where the real work is

Before you create ‘a thing’, first tell me:

• Who you’re going to ask about it.
• What you want to know from them.
• How you’ll collect and action feedback.
• Who you’ll have to convince to use it, and how.
• Who you’ll need to influence to get them to convince the people you actually want to convince.
• What you think will motivate them.
• What behaviours you’re trying to change.
• What kind of system it needs around it.
• How will it be maintained and kept up to date.
• Etc., etc., etc.

If you can’t do all that real work first, you shouldn’t create ‘a thing’. If you want ‘a thing’ to be successful, you have to understand the entire system it’s operating in.

Triangulation of responsibility

The usually concept of hierarchical organisations is that, near the top, there is a single small group of people who are jointly responsible for leadership, management and governance. Sometimes, those three things get mixed up and merged into one thing, which means the power and purpose of each gets diluted.

If leadership, management and governance were three separate entities with different responsibilities and different people that have to negotiate on how to meet their responsibilities, would it improve the quality of organisational decision-making?

• Leadership is responsible for direction, priorities and goal-setting.
• Management is responsible for work allocation, capacity and resource management, workforce commitment and compliance.
• Governance is responsible for quality, regulatory compliance.

These three entities, taking a dialectic approach, might reach better decisions.

The AI tipping point

There’s a tipping point where you chat to AI more than humans. I’d rather not say whether I’ve passed that point.