Category: Weeknotes

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.

I did:

Loops

Lots of talking and thinking about feedback loops this week (and I started using Microsoft Loop a bit more, but that’s just a coincidence). “Loop” is a fundamental, first principle concept for product management and yet it’s so hard to get right. Anyway, did this stuff too…

• Saw some great leadership.
• Talked about strategy and org change as two sides of the same coin with strategy being about looking outside the organisation and org change looking in.
• Had a few good coaching sessions, particularly about the meta work we have to do so we can do good product work.
• Spent some time on data protection impact assessments which will improve how we handle compliance in the future.
• Brought our simple, consistent way of managing product work to two pieces of change work, so I’m interested to see how well it applies.
• I’ve got next week off which gives me time to step back and replan all the different things I’m working on and think about building the case for something new.

I read/watched:

Shipping Is Your Company’s Heartbeat

Charity majors writes about a letter to CTO’s “explaining why all their grand ambitions and goals with AI are blocked behind their organization’s’ ability to learn.” True, but I’d go further and say all leader’s ambition are blocked by an ability to learn, not just AI. Shipping software is only one way to learn, their are many more. The letter ends with, “If shipping is your heartbeat, then understanding is your breathing.” I want to understand more.

Theories of power

I think it’s hard to successfully navigate within an organisation with a theory of power, i.e., a mental model for who influences who, how decisions get made, which groups have aligned interests, etc. There are lots of definitions and different theories of power, but the pluralist one resonates most with me, particularly the characteristic of countervailing, where groups of similar power cancel each other out and prevent or slow progress.

How People Work, Live! … with Jukesie

Designing in the dark

Lots of great advice from Audree Fletcher on working with stakeholders and convincing them to support your work.

I thought:

Fixing things

Years ago, I had an argument with a developer about a bug in a product. He said it was “working as expected”, to which I replied that his expectations were wrong. Sometimes things can be working as expected but still be wrong, and sometimes they might not work as expected but still be right.

Four P’s of approaching situations

What kind of approach does any given situation need to give us the best chances of success?

	Pragmatic	Purest
Principles	Immediate action is required but it is unclear and so needs guidance to direct figuring it out	The way forward is ambiguous so the guiding principles need to be figured out.
Processes	The specific actions are already known and there is a high likelihood they will be successful.	The way forward is clear but doesn’t yet exist so it needs to be built.

Each has its place, one isn’t better than the other, but choosing between them is important for approaching situations in the right way.

I did:

Outcome-focused

We’re putting lots of time and energy into being more outcome-focused. It’s something I really believe in because of what it means for meeting user’s needs, for what it means for teams and trust in their expertise, and for what it means for efficiency within organisations.

• Got back into planning my week which I’ve been a bit slack on recently but think I should practice what I preach.
• Set up a wiki for a piece of work, which is another thing I preach.
• Did some more detailed capability mapping against one of our products. Next steps are to analyse the current investment into each capability.
• Prototyped a dashboard for reporting our north star metric.
• Talked about outcome-focused roadmaps that give teams the space to explore different ways of achieving goals.
• Talked a lot about analytics, metrics, measurement and, most importantly, insight.

I read:

The portal trap

Not just because everyone else is reading it, but because it’s an interesting perspective on the kind of solutionism that is the arch nemesis of user-centred design and product thinking.

The cost of ambiguity

Super insightful point from Holly Davis about how it used to be that the good practices we’ve known for a long time can reduce ambiguity could be ignored because people thought they were good at dealing with that ambiguity (they’re wrong, but that’s another point), but now AI is part of the picture, and it doesn’t deal with ambiguity very well at all, all those practices take on another level of importance.

I thought:

How to make outcome-focused roadmaps work

Outcome-focused roadmaps are a great way to balance an organisational need for predictability and financial planning with giving product teams the scope and space to understand problems and solve . But creating outcome-focused roadmaps requires a different approach than the usual approach of specifying deliverables on a roadmap.

1. User journey – Map the actual user journeys at a task level so you have a clear representation of all the actions users do as they use the product.
2. Organisation objectives filter – Look across the data behind the user journey to pull out which are the most important parts for improvement.
3. Outcomes – Write outcomes for the important parts of the user journey that should be improved. When we say “outcomes”, we mean Josh Seiden’s definition of “a change in user behaviour that gets business results”. We can phrase outcomes as “who, does what, by how much”, e.g., new visitors view three pages 15% more than they currently do, or, logged-in users convert through x journey in less than 30 seconds, or, users from the US provide marketing consent twice as much as they did last year.
4. Roadmap – Place those outcomes on your roadmap. Assuming you use a Now Next Later format, then everyone can see that the priority right now is new users, with the US market something for the future.
5. Hypothesise ways of achieving outcomes – The vital part about expressing outcomes in the way we do is that it doesn’t tell the team what to build. It tells them what to achieve and lets them figure out lots of different ways to achieve it. The team might come up with five hypotheses for reducing the time taken for logged-in users to get through a journey, but they aren’t committing to delivering all five. They can decide to deliver one and see what effect it has before they decide what to do next.
6. Deliver one/some of them – The team delivers on one of their hypotheses. They probably picked the one they thought was most likely to reduce the conversion time.
7. Measure – Then the team measures the shipped changes. If the outcome has been achieved, then you go to 4 and pick up what’s next on the roadmap. If the outcome wasn’t achieved, they go to 5 and pick another hypotheses to deliver. This way they continue to work on an outcome until it’s achieved, but are efficient in only doing the right amount of work to achieve it.

I did:

Countdown

Is it that time of the week again? Where did the time go? Here’s some stuff that happened:

• Welcomed a new product manager to the team.
• Shipped three pieces of work, all of which aim to improve commercial performance, user experience and compliance. That’s the benefit of more cross-functional working showing up.
• Did some capability mapping to understand how we spread investment and what it might need to look like in the future.
• Planned out what we need to do to improve our product instrumentation and behaviour data collection. Obviously I started with what outcome we want to achieve and worked backwards.
• Talked about the financial benefits of our product work, the hypothesis behind it, and the challenge of diminishing returns.
• Watched one of our amazing product managers jump into some complex work and make sense of it really quickly. I was very impressed.
• More interviews.

I read:

AI Safety Index

Unsurprising.

Why product feels hard right now

What is cybernetics

I thought:

The standard of shared understanding

Product teams need shared understanding, and they need a standard of shared understanding so everyone gets to know how it works in a consistent way.

The standard would include artifacts like a roadmap and a kanban board for task management, and a list of stakeholders, a problem statement and

Then, when a team comes together to work on a new product they have an accepted way of reaching a shared understanding quickly.

The real roadmap is all in your heads

The real roadmap isn’t in a slide deck, it’s a social construct in the minds people all across the organisation. What’s on the slides is a weak representation of what people hold in their heads, it lacks nuance and dimensionality and flexibility.

Mirror, signal, manoeuvre

It’s pretty good guide for doing product work too. Working backwards, you decide what manoeuvre you want to perform, but before you do it you figure out how to communicate your intentions, and before you do that you look around to check what’s going on so you don’t make the wrong manoeuvre.

The Doppler effect of deadlines

Deadlines sound different depending on whether they are approaching or receding.

I did:

Go time

We’re four weeks from an important deadline so everyone is flat out and we’re starting to figure out which work isn’t going live on time and what that means for our numbers. I love this kind of pressure. Did this stuff too.

• Planned onboarding for a new product manager joining us next week.
• Interviewed some very talented product managers.
• Talked about task completion as the unit of analysis for our north star metric.
• Chatted about playbooks, what that looks like with AI (writing evals and prompts rather than specific plays).
• Had some really good coaching sessions.
• Booked my ticket for Product for the People.
• Got cited in “Bridging theory and practice – implementation insights on artificial intelligence in health care”.

I read:

Experiment-Driven Product Development

Started reading Paul Rissen’s book about using an experimental approach to develop products. It sets out a framework for asking questions and getting answers in a structured way.

We took away psychological safety and then told everyone to be more productive

“What needs to change is the fundamental assumption that people are resources to be optimized rather than humans who require certain conditions to do their best work.”

Via Stéphanie Walters.

The Builder’s Job Is Not to Build: A Mindset for Better Outcomes

Interesting talk about being outcome-focused.

Via Debbie Blanchard.

How to deliver digital transformation in public services

Seven lessons:

• Anchor the programme in a clear, shared vision of the outcomes you want to achieve.
• Show leadership: take accountability and own risks and decisions.
• Cultivate the right mix of skills and collaborative ways of working.
• Build a picture of who your users are and what they need.
• Get your scoping right: work out where to start, what to prioritise and what to exclude.
• Prioritise the needs that are most critical to achieving your vision.
• Get to grips with the commercial environment and different delivery and funding models

Via Rob Cawston.

The strategic product designer

Nice collection of resources.

I thought:

Compounding improvements

Once we’ve finished a piece of work, the board we used to manage the work just gets abandoned or archived. We don’t analyse it and turn it into a template for future work. That seems like a lost opportunity for continuous, compounding improvement.

Hand-offs

We all know how bad hand-offs are, but maybe we don’t recognise just how bad. Knowledge loss is mostly invisible until something goes wrong because of it so it’s easy for no one to realise the scale at which it’s happening.

But practically speaking, it’s impossible to keep the same people working together on the same thing all the time, and documentation never captures the tacit knowledge that we create for ourselves.

Is knowledge loss just part of organisational life, part of the entropy of modern knowledge work?

I did:

Heatwave

The second order effects of things like heatwaves always fascinate me. In-person sessions cancelled, schools closed, more people on leave, people not feeling their best, more stress, maybe different decisions get made than would have in other circumstances. Anyway, this is some of the stuff I did during the heatwave:

• Did a training course in AI product strategy. We used AI as a tool to consider how changes in the AI market affects AI in our products.
• Set up a spreadsheet for doing Bayesian analysis on product outcomes. It needs more work but there’s definitely something useful in being able to express uncertain outcomes as probabilities.
• Chatted about Total Quality Management and where it could be useful for us.
• Created a little agent for answering questions about some work we’re doing.
• Me and three other product managers pitched our ideas to a group of stakeholders and got lots of good feedback.
• Presented my thinking on the future direction for one of our big products.

I read:

How LLMs affect business

Interesting post from the CEO of Buttondown about customers having used LLMs to research their product and what that does to support needs, lifetime value, etc. It’s an important consideration for every organisation. When customers come to you having already established an understanding about your business that you haven’t had much control over, it changes the nature of the relationship. This is AI as an intermediary.

The right it

Stumbled across Alberto Savoia whilst wandering around YouTube so bought his book. Despite calling Howard the Duck a failure, he has some good advice about collecting data to validate new ideas.

Bottleneck theatre

“Imagine the “bottleneck” really was engineering or coding. What does that imply about the competitive game you were playing? Are you saying the only thing holding you back was something relatively commoditized—something you could just hire more people to do? What does that say? It suggests you were competing in a world where speed of execution mattered more than insight, where everyone was building roughly the same thing, and whoever shipped faster won. But if that’s true, you better hope engineering wasn’t your bottleneck. Because if it was, and AI removes that constraint for everyone, your competitors will take you to the cleaners.”

I mean, no one ever really believed that organisations actually only have one bottleneck stopping them from suddenly being more successful, right? In many cases, the way the organisational structure is set up to operate is the actual bottleneck, and AI can’t fix that.

So a lot of this is just AI theatre. And when we talk about theatre we’re talking about the suspension of disbelief, which is to say, everyone knows it’s not real but everyone goes along with pretending it is. AI can’t fix that human trait either.

I thought:

Changing sociotechnical systems

There’s a pacing layers thing going on where technology can be changed quite quickly, changing tasks is slightly slower, structural changes happen more slowly still and people changes can be really slow. So there’s an uneven distribution of benefits of the change.

Spirals, not circles

So many diagrams explaining methods like Theory of Constraints, Agile, Scrum, etc., are circles. I get the simplicity but I think it’s too easy to interpret as repetitively going through the same process again and again but not really getting anywhere. I think spirals might explain the process better. The work flows through the same steps but each time it is more refined and closer to the target in the middle of the spiral.

I did:

It’s that time of year

This week was a four-dayer, and the next few weeks will be too as I use up annual leave, so I’ve got to figure out what that 20% drop in time means for the work I do and try not to squeeze five days into four, and still achieve what we’re trying to for upcoming deadlines.

• Lots of good chats with the product managers I’m working with. We’re working in new ways that are pushing us out of our comfort zones and I’m so impressed with how they are responding.
• Kicked off more recruitment.
• Didn’t talk about the unit of analysis we measure our products by because some ideas are so deeply held they can’t be given up.
• Had a really collaborative session with our marketing automation team. I can see much more joined-up multichannel experiences coming soon.
• Joined a demo of a new product we’re launching soon.
• Talked about product strategy for chatbots (I need to write up my thoughts because it showed a different approach to creating a strategy).
• Started writing up my three big bets for next financial year.

I read:

The manager’s path

I found it boring with basic suggestions like have one-to-one’s. 1/10.

Asking better questions about AI in education

Locking in costs and quality

Eric Ethington writes about how in Lean Product and Process Development it’s well known that 70% of the cost and quality of a product are locked-in by decisions made during the concept stage, before implementation even starts.

I thought:

Theory of constraints in complex systems

All the examples I can find for theory of constraints are in linear systems like manufacturing processes. I can’t find anything that explains or visualises constraints and bottlenecks where there are thousands of flows and the bottlenecks are often at the interaction points between two flows, which means improving that bottleneck for one flow has consequences for all the connected flows. Anyway, even if I don’t have a visual, imagining it helps me understand how complex organisations work.

What kind of product manager are you?

I’ve been looking for an analogy to explain what it means for product managers to have a strong stance about their products. My music analogy is that you’re either Coldplay; mainstream, middle-of-road and liked by the masses, or The Jam; strong opinions against the mundane. Without a strong and evidence-based defensible stance, a product manager risks falling into being an administrator just bringing together other people’s opinions which creates bland products.