Category: Weeknotes

I did:

Sharper axes

Two day week so only did this stuff:

• Led a co-writing workshop with bunch of product managers to help us develop a shared tone-of-voice for how we talk about our products. I found it really useful, and I hope some of them did too. I think we should do more group work like that.
• Did a surprising amount of planning a) for things I’m working on and b) with others to help them with things they are working on. And, as always, facing the question of how much time you spend sharpening the axe versus chopping down the tree.
• Talked about how we might prioritise work that affects three teams when each team has different objectives, in ways that are fair to everyone. It’s one of the interesting things about matrix organisations.
• Started chatting to product manager’s about where our platform product practices might go. I think more of our teams might be platform teams than we realise it so it’s essential stuff to get right.
• Connected a few different pieces of work that might all have the same need and same solution. It made me think more about how we look out for zeitgeist signals about emerging work, and also, how urgency, recency and frequency bias affects prioritisation thinking.

I read:

Intent-driven design

Really smart and thoughtful article by Carrie Webster about UX design shifting from visible interfaces to guiding transparent, intent-driven AI experiences.

Roadmap essentials

James Higgot’s excellent advice on roadmaps. Like I always say, the roadmap is all in your heads, how it gets expressed depends on the situation.

Golden Era of Product Management

YouTube’s algorithm sent me this video, which got me thinking about the ‘preaching to the choir’ problem of product managers who believe in empowered teams watching videos like this but it never shows up to the people who really need to see it. It’s an interesting organisational change problem.

I thought:

The bluntness of first order thinking

First order thinking tells us there is a single cause to an effect. It makes us believe that we can create an effect through a simple, single cause, and it makes us believe that the effects we see came about because one cause. When you put it like that it should be obvious that no effect ever has a single cause, but still it’s too easy for our brains to jump to that as a explanation.

It might be a natural human behaviour but it has no place in rational, logical product thinking. As product managers, we have to figure out the complex, multiple step causes that create effects. To me, that’s the core, fundamental purpose of product thinking. We use rationality to overcome the naturally occurring bias in human thinking. How we do that is what makes it infinitely interesting.

Analyse, Prioritise, Sequence

The thing about being outcome-focused is that when you set out to change user behaviour in ways that get business results you don’t know what will actually achieve that.

That means you need a different approach to prioritising work and managing backlogs. The output-focused approach takes everything on the backlog as in need of being delivered regardless of whether it might affect the outcome. Lining up work in an outcome-focused way means having lots of ready-to-go ideas, many of which will never get delivered because they don’t help achieve the outcomes that matter at the time.

Maybe the process looks something like this:

1. Have lots of ideas and analyse them to understand things like audience, value, step in user journey, etc.
2. When an outcome becomes important, pick from the list of ideas and prioritise them based which is most likely to achieve the outcome. Prioritisation logic is ‘this, not that’ so it’s about filtering out those ideas that won’t affect the outcome.
3. Sequence those ideas based on constraints such as resourcing, capacity, dependencies, etc.,. Sequencing logic is ‘this, then that’, so it’s about ordering the work to be delivered.
4. Take the first idea into the backlog, break it down, deliver and measure the work.
5. If that delivered work achieves the outcome, stop working on that outcome and move to the next. If it doesn’t, take the next prioritised and sequenced idea into the backlog.
6. Repeat step 5 until the outcome is acheived.

Queuing

Queues, like switches, are an entirely human invention. Based on all kinds of human ideas like scarcity, resource management, growth and fairness, queues allow us to organise our world in a way that makes sense to us. Sure, fire, electricity, AI, etc., are all great inventions, but they’d be nothing without the mental inventions humanity has created, and queues are one of the most important.

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.

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.