Author: Roger

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.

I did:

Seeing around corners

One of the less appreciated product skills that I try hard to cultivate is my ability to predict what’s going to happen based on observable signals. A few things I predicted came true this week, and a few more are looking more likely. It’s a skill I keep trying to calibrate and get better at. And did this stuff too:

• Chatted about the product strategy I’ve been working on. I did some more competitor research but still have so much work to do on it..
• Shared the bad first prototype dashboard for our North Star Metric for feedback ahead of presenting it next week.
• Handed over product management of our big bet for one of our products to another product manager. Part of me would have liked to have worked on it but I know he’ll do a much better job of taking it where it should go than I would.
• Wrote some definitions of “validation” and “time-to-value”, which I really enjoyed because it tested my logical thinking.
• Agreed recommendations for what we do next with an AI feature we’ve been testing.
• Got a volunteer to take on managing our analytics capability.
• Brought together different thinking on delivery reporting and product evaluation. Where I’d like both to go in the future is using Bayes to show the probability of delivering on time and achieving outcomes.
• Short-listed candidates for a content role in our service.
• Planned more work. Like I always say about agile planning; I can tell you what will be delivered but not when, or when but not what.

I read:

Know Your Agents

Read Tom Loosemore’s full briefing for Know Your Agent, which he very kindly sent me.

Tom says, “People are starting to send software, not themselves, to deal with your organisation. If that sounds slightly odd, it won’t for long.”

I completely agree. There was a time when organisations thought the internet wouldn’t change how customers interact with them. And then it was mobiles. Now it’s AI. The pattern repeats. Get ready.

I thought:

Loops, not lines: a modern product development process

Most product development processes follow linear steps based on manufacturing processes, often to their detriment. Far too much software gets shipped that that no one wants because once the process starts it doesn’t know how to stop.

I’ve been trying to figure out what a looping product development process that seeks progressive validation of an opportunity (rather than delivering on unvalidated assumptions) might look like.

1. Analysing existing evidence
   1. Evidence quality: Existing research data, not from users, not from interacting with a product.
   2. Techniques: Performance data, previous user research, third-party information, industry case studies.
   3. Decision: If this analysis shows the opportunity to not be worth investing in, stop. If the analysis suggests potential value, go to step 2.
   4. Confidence-in-value level: Low.
2. Collecting new evidence
   1. Evidence quality: New research data, from test users, interacting with a test product, with an intermediary.
   2. Techniques: User interviews, prototyping, observation study, fake door tests.
   3. Decision: If this analysis shows the opportunity to not be worth investing in, stop. If the analysis suggests potential value, go to step 3.
   4. Confidence-in-value level: Medium.
3. Generating real user proof
   1. Evidence quality: New usage data, from real users, interacting with a test product, without an intermediary.
   2. Techniques: MVP, split, concierge and wizard of oz tests.
   3. Decision: If this analysis shows the opportunity to not be worth investing in, stop. If the analysis suggests potential value, go to step 4.
   4. Confidence-in-value level: High.
4. Collecting proof at scale
   1. Evidence quality: New usage data, from real users, interacting with a real product. without an intermediary.
   2. Techniques: Data analysis of a large user base, performance data that signals continued, repeated use or a pipeline of new users.
   3. Decision: Continue to invest in supporting the product.
   4. Confidence-in-value level: Very high.

This approach tries to fit with the stuff I go on about the job of product management tools is to filter out the ideas that won’t work. If there ever was such a tool, it might be based on this concept of progressive validation.

Disruption-proof

Are any industries not susceptible to disruption, and is higher education one of them?

We know what the pattern of disruption looks like. A new market entrant provides an offer that looks worse than the incumbent offers, attracts a new audience, builds momentum and investment to grow, provides a different or better offer to the incumbents audience and steals enough of them to make the incumbent fail, and the new entrant becomes the incumbent and sets the direction of the category.

That model works for fairly straightforward industries such as mobile phones (Nokia and Apple), watching movies (Blockbuster and Netflix), but the higher education industry is far more complex and extremely difficult for new entrants to unbundle in a way that creates a disruptive offer.

Universities bundle many things in tightly-knit ways; learning, accreditation, making friends, choosing a career, finding a partner, shaping identity, growing up, changing careers, having a sense of achievement, and so much more.

I think that bundling lots of things together in a tight-knit way where everything connects to everything else, makes universities really difficult to disrupt. Those that say things like, “YouTube is free university”, don’t get what a university is. This also means universities have no need to innovate on their business models, but then again, do they need to?

Sociotechnical systems change mechanisms

When we talk about change, what things can we actually change within an organisation? Sociotechnical systems theory gives us a broad framework of six areas so I listed all the changeable organisational elements I could think of within them.

Goals:

• Vision
• Strategy
• Prioritisation
• Target-setting
• Performance measures
• Governance

People:

• Recruitment
• Role design and responsibilities
• Reward and recognition
• Management and reporting lines
• Coaching
• Training
• Community
• Incentives
• Motivations

Process:

• Workflow design
• Policies

Technology:

• Tool utility (how well does it do the job without workarounds)

Culture:

• Leadership behaviour
• Communication
• Storytelling
• Role modelling
• Shared norms

Infrastructure:

• Workspaces
• Facilities
• Equipment

So, if you want to have a well functioning organisation, you need to get all those things right in ways that they don’t contradict each other.

Copilot notebooks

Microsoft might have actually found a way to make OneNote useful by connecting it to Copilot.

I did:

Happy new year

This week is the start of our new financial year. It’s one of those things that makes a big difference and no difference a all at the same time. Anyway, this stuff happened too.

• Interesting chat about mapping product capabilities to architecture patterns.
• Improved my opportunity analysis spreadsheet as the first step towards bringing the work of different teams into one place so all the product managers can see it.
• Wrote my quarterly objectives.
• Set up a workshop for the team to pitch ideas for future work.
• Had a good chat about whether org change work is a product manager’s responsibility. My take is that our job is changing behaviour, and sometimes that includes our colleagues behaviour.
• Started planning the business change and rollout of a new product.
• Did a first-pass walk-through of the strategy I’ve been working with another product manager. Got some useful feedback ahead of presenting to a group in a couple of weeks.

I read:

Your decision queue is your delivery problem

‘The work’ is only wasting time waiting if you think decision-making isn’t the work. But in product work, making the right decisions with the right people is the work. That carries a coordination overhead and demands due diligence, all of which takes time. So, this raises questions like, should we speed up decision-making, how might we do that, what might the risks and implications be if we did?

Agents are coming

And honestly it is one of the things that keeps me up at night. I’ve read lots of stuff this week to try to get my head around what it might mean for all our products and the scale of change is mind-blowing.

Agent experience

David Hoang talks about Mathias Biilmann’s concept of Agent Experience and bringing it together with user experience and developer experience to build systems that work for all three. As is often the case with new things, it’s important to figuring out what makes it different. The example David gives is how intuitive slide-to-unlock an iphone is for humans that have fingers and understand what touch is, but wouldn’t make sense for an agent.

Know Your Agent: Why you should act now, to avoid playing catch-up later

Tom Loosemore calls for large public sector organisations to start figuring out how to deal with AI agents interacting with them on behalf of people. He asks two important questions about who sent the agent and what authority does it carry. There are going to be so many more important questions to answer over the next few years.

Agents Week

Lots of interesting posts from Cloudflare about agents.

I thought:

What does AI mean for product operating models?

I’ve been pondering this question because of various conversations around operating models that haven’t considered the effect AI (I don’t just mean the tech, I mean social, economic, process, etc.) is going to have.

Generally speaking, the reason to move to a product operating model was to adopt a more cost-efficient ‘build once, sell the same thing to lots of customers’ approach because the economics of software on the Internet allow that. The project operating model that companies were trying to move away from didn’t have those economies of scale because software was customised for each customer. I think AI reverses that. It will allow companies to produce software that is customised and personalised for customers at the speed and economics of the build once approach.

Of course there are lots of ways to think about product operating models but as an example to see how an AI operating model plays out, lets take Itamar Gilad’s framework:

• Research – AI enables more research to be done more quickly, and analysed in ways humans can’t, to produce insight into new opportunities. Being able to connect market trends with user research reports with analytics data to identify and audience segment with specific emerging needs was really hard to do before. AI can do it, and it can do again and again to find niche after niche an organisation could serve.
• Strategic context – Then comes picking from those opportunities to ensure they take the organisation in the right direction. AI has an analysis role to play here too that changes how organisations pick the right opportunities. It’s not the ‘more, faster’ of Research, it’s
• Goals and metrics – I see this as the more challenging change for/with AI because with most of the other aspects of the operating model there is no single right answer, but with metrics there is, and that’s not AI’s strength (yet). So, maybe the way AI changes this part of the operating model is to pressure organisations to sort out their data.
• Discovery – I think AI changes discovery in the same way it changes research. Get more done faster. Discover worthwhile problems-to-solve in real-time, as they emerge, in new niche markets.
• Delivery – There’s already lots of stuff out there about whether AI coding does or doesn’t make software delivery faster, but given how much AI companies are going after this I can’t see a future for software development without AI. If this really does change the economics of software development then delivering on multiple opportunities at the same time becomes a reality.
• Go-to-market – AI can definitely accelerate the planning and asset creation for taking a product to market.
• Operations and infrastructure – AI is already playing a part in managing product infrastructure and that only looks like it’ll get better and better.
• Culture – AI makes us all generalists. That leads to a very different organisational culture than one that values specialism, expertise, seniority and experience. I’m not idealistic enough to think that makes for better culture, but it will be significantly different in ten years as incentive structures, career develop opportunities, who we work with, and who knows what, catches up with the change.

If we look back at the narrative around building products over the last few years it’s been about ‘big bets’, ‘one vision’, ‘single strategy’, all stuff that suggests a unified alignment towards one thing. AI changes this, shifting it towards multiple narrower, and possibly even temporary, focuses for organisations.

Really Simple Sharing

Why is there no platform for sharing and swapping your RSS feeds? Someone build it for me, I don’t have the time. And in the meantime, here’s mine.

I did:

No off switch

I was on leave this week but I got a bit bored (intellectual stimulation is one of the good things I get out of work) and a few things needed progressing, including:

• Laying out an approach to creating a product strategy that focuses on making choices about market opportunites. Still lots more to do on it, but I’m aiming to present it to a group of product managers in a couple of weeks.
• Having an interesting chat about data protection impact assessments and how much risk we’re willing to accept. Risk, much like prioritisation, just doesn’t work in a spreadsheet. There’s too much context to consider.
• Planning out my priorities for the next quarter. I’m working on two big products, a small one, a bunch of improvement initiatives and lots of coaching. Luckily for me, I have two years of productivity data which I used to set my goals and capacity for each piece of work.
• Having a budget meeting for one of our products. I’ve got some complicated sums to do next week.

I read:

The end of competitive advantage

Got a signed copy of Rita Gunther McGrath’s The end of competitive advantage. The premise is that too much strategy thinking is about creating a one-time sustainable competitive advantage and that organisations would be better served by being able to quickly move on temporary advantages.

Systems thinkers at Netflix

Management Tips on Setting Strategy When the Path Is Unclear

See now, this is part of the problem. The headline says “setting strategy” but the article is about organisational change, not strategy. There’s nothing about how to look outside the organisation, understand the market, and respond in a way that gives the organisation a competitive edge. And then we wonder (or at least I do) why managers can’t do strategy and mistake it for org change.

(Thanks Emily Webber for the link)

Disappointed designers

Christina Wodtke on cursed problems, conflict and contradiction, “AI lowered the floor of what anyone can produce, but it didn’t raise the ceiling of what’s good.” So, what does?

Bundling and unbundling

Interesting idea of using bundling and unbundling to explain role change within an organisation. It’s a well-known approach to building products, so I’m trying to figure out if it might actually explain and predict how roles might change by accident and on purpose. If it does, that it could make a really useful tool.

User Journey Mapping: a practical guide

Nice guide to user mapping. My problem with this approach to user journey mapping is that it’s too vague to be useful. Any of the steps could easily be replaced by a different step without making much of a difference. And that lack of making a difference is a sign that the journey map doesn’t take a strong enough stance to be a useful decision-making tool.

When I talk about user journey mapping I explain how every change of state is a step to the right along the journey. And every crossing of a system boundary is a move up or down the map. This means that the knock-on effect of any and every change can be seen throughout the map. Change a link in an email and the map shows you which web page traffic now goes to, which analytics tools track it, which dashboards get updated, what actions a user can take on the page, which database records a form submission, etc., etc. That kind of user journey map is actually useful.

I thought:

Everyone has their own system

I went to the farm shop early, just as the lady behind the till was setting up (they have the best grapes). She couldn’t find the till roll and said she wasn’t working yesterday but the person who was would have put it somewhere that made sense to them. She offered the insight, “Everyone has their own system”.

Everyone in every organisation has there own system that makes sense to them given the organisational systems around them. Even if there is a well established procedure, the people following the procedure have their own system.

When you see organisations and work through this lens you can only conclude that variability is a fundamental feature of the whole system. The idea of standardising out the variability is risky myth because it hides how things really are.

Product workflow

A while ago, after a chat with a company that was trying to build a tool for product management, I wrote up some initial thoughts on what I want from a product tool. It’s been bubbling away in the back of my mind and recently I’ve been trying to distil it into a simple explanation.

The difference between what a product management tool needs to provide, and what almost every workflow management tools provides is the difference between filtering out and everything going through.

All workflow management tools based on kanban boards come with the assumption that everything on the board has to get from left to right. Anything not in the right-hand column is considered unfinished and that’s bad. Those are fine assumptions for workflow management but they don’t work for product management.

A product management tool would be based on the assumption of having to filter out items because they don’t match the user research or strategy. In this tool, the more things left behind the better because it means we’re being focused, but it should be for rational reasons.

And this is one of the ways I see AI changing product management in the near future. It allows for faster customer and competitor research and analysis, which means far more opportunities can be considered, which means the bar for honing in on the right strategy goes way up, which means we need tools to do the filtering.