Category: Weeknotes

I did:

Expected future value

I realised this week that most of my product management work is underpinned by an unswerving belief that we can create a better future. Solve problems for users because it will make their future easier. Set-up tools and process because it will make the team more effective in the future. Coach people because they’ll do better work in the future. Everything we do is the promise of a better future. Here’s some stuff that is now in the past:

• Grouped up a few problems of the same type so we can try to solve them together in a consistent way, rather than individually and differently. It was a good lesson in looking for the patterns and knowing when to change approach.
• Chatted about finding the right problems to solve and how they are usually non-obvious. Also, when it comes to strategies for solving problems, expected future value sooner and later matters.
• Joined a demo for Monday Dev. Made me think about how solutions are easy and organisational momentum pushes us to prematurely pick solutions.
• Had a surprisingly good session about setting up ADO, which is not usually the most interesting topic, but branched off into discussions about agile, ways of working, and organisational change.
• Wrote a short story about an imaginary team creating their product strategy and setting OKRs. I haven’t really used it yet but I’m interested to find out if something like this helps people understand differently to instructional content.
• Won a small victory for plain English.
• Went to EduCamp in Sheffield. It was awesome. Spoke to lots of wonderful people and learned so much.

I read/watched:

Are we more creative when under pressure?

No, according to this HBR article on creativity and deadlines. The pressure of deadlines doesn’t help people be more creative, which is worth considering when tackling complex problems that need creative thinking.

Platform as a Product: Building Trust, Not Just Tools

More goodness from Ragan McGill. Treat your internal platform like a product – with a clearly defined value proposition, customer personas (your engineering community), feedback loops, and success metrics.

The feature factory strikes back

“A Feature Factory is a team that exists to ship features. Not to solve problems. Not to deliver outcomes.” But I’d like to offer an alternative perspective; optimising on known solutions. If you manage products for a large organisation with a well-established product suite and no new problems to solve, then the feature factory is probably the most efficient and effective configuration for your product org, because the goal isn’t to have leading edge product practices, it’s to have business and user impact.

OKRs and impact-first product teams

Feel like this is going to be my go-to video over the next few weeks.

I thought:

Lots of thoughts this week. Don’t know why, maybe it’s the weather. Some of these should probably be blog posts in their own right but we all know I’ll never get around to that.

Tendencies

Rather than processes, principles or practices, I think I’d prefer tendencies. Tendencies say, all things being equal, we tend to do this rather than that, but if things change we’re not locked in.

When to use GenAI

I don’t get why people are still getting worked up about GenAI making stuff up and getting stuff wrong. That’s exactly the point of it. That’s what the “generative’ part of Gen AI means. Maybe we should be better at using tech for the right things.

	Known solution/answer	Unknown solution/answer
No verifiably correct answer	Use GenAI. E.g., what should be included in a business case.	Use academic discourse. E.g., what’s the best approach to education.
Verifiably correct answer	Use established knowledge. E.g., how to calculate the circumference of a circle.	Let the experts figure it out, come back later. E.g., what’s going on inside black holes.

Standardise

External-facing product management is all about experimentation. Experimenting your way to market-fit via viability, feasibility and usability. If you’re not experimenting to learn what users actually need and will use, you’re just guessing (I don’t mean you personally, I mean the organisation you work for). So, what’s the equivalent for internal products? Standardisation, maybe? Internal-facing product management is focused on standardising the interface, functionality and usage of a product to meet the needs of the organisation.

And as they start at opposite ends of the experiment-optimise-standardise spectrum, we could say that experimentation is about changing the product to meet user needs, and standardisation is about changing the user need to meet the product (so everyone does things the same way).

Defining a product

I’ve been thinking about how organisations define products so they can talk about them coherently and not get confused between what’s a product, what’s a piece of technology, what’s a channel, etc.

I start from the stance that a product is the sum of other things. And, so far, my incomplete list of those things has six categories that make up a product, and for something to be defined as a product, it requires all six to be involved.

Thing	Examples	Reason
User need	To purchase a car, to record information, to listen to music.	Solves a worthwhile problem.
Value exchange	Payment, data, attention, action.	Users, customers and organisation get something they desire from each other.
Channel	Website, app, email, phone, API, etc.	Interfaces between the user and organisation.
Technology system	CRM, CMS, ESP.	Enables structured transactions at scale and speed.
Organisational capability	Data analysis, order management, payments.	Brings together and uses multiple organisational capabilities.
Business logic	Market & customer choice, pricing.	Surfaces business decisions in codified, repeatable ways.

Some implications of this definition:

• Multiple products can use the same channels or technology systems, or organisational capability.
• Different products within the same organisation should have different business logic and user needs, those are the things that make one product different from another.
• How organisations organise their products across channels, capabilities, etc., helps them understand commonalities.
• Parts can be changed and replaced, but the product continues to exist.
• This definition make the goal of product management to bring those things together in coherent way. Product manager roles have different responsibility coverage in different organisations. Some have more focus on particular aspects such as being a specialist for a technology system. I think this might be because organisations like to feel that people have something tangible to say they manage, but they are doing all the other stuff too, it’s just not so visibly.

Things to think about:

• Should Data be the seventh thing?
• What would a mapping of the different parts look like to show how things overlap?
• What other characteristics might sit alongside the parts to help people define products, e.g., long-standing, focused on outcomes, etc.?
• How could this be tested to find out how useful it is?

Digital transformation = Organisational codification

Heard an interesting definition of digital transformation: converting organisational structures and business logic into a machine-readable format. Not because any machine will ever need to read it but because the discipline of standardising and codifying things forces organisations to change away from analogue variations.

More or less agile

Requirements, feedback, requirements, feedback, requirements, feedback, design, feedback, design, feedback, design, feedback, build, feedback, build, feedback, build, feedback, test, feedback, test, feedback, test, feedback, launch, feedback…

…is more agile than…

…discovery, design, build, test, launch, discovery, design, build, test, launch, discovery, design, build, test, launch.

Or to put it another way doing all of the same types of work together (waterfall) but with feedback is more agile than iterative delivery without feedback.

No new ideas in the building

Was thinking about organisations creating porous boundaries again.

It relates to the return-to-office debate and claim that watercooler moments don’t happen if people aren’t in the same physical space (ignore that fact that if an organisation relies on chance encounters to drive innovation they’ve got bigger problems). What often gets missed is the question of where did those people get the ideas they talked about whilst sipping their cool filtered water.

If an organisation has the expectation that work only happens at a desk, in the building, between 9 and 5, how can people ever get new ideas? Go to one conference a year and then go back to the office to get on with “the real work”?

But if we set the expectation that work can happen anywhere anytime – that going to a conference, talking to customers, having impromptu conversations with people at a co-working space, listening to a podcast while going for a walk, all of that is “work”, then people have lots of sources of inspiration and new ideas.

The thing is, the anywhere anytime work expectation that is necessary for getting all those new ideas is incompatible with the expectation of everyone being in the same place at the same time to discuss the ideas. There are no new ideas in the building, but there are lots of ways to discuss them anywhere anytime.

Hiring process

There’s a weird hypocrisy in hiring processes where organisations expect one type of person to put lots of time and effort into applying for a role, but expect another type of person (who is being paid) to spend as little time as possible reviewing applications. The use of AI in the hiring process, writing job applications and/or assessing them, has surfaced the discussion more, but the problem goes to hiring processes not being designed in a human-centred way.

I did:

Never finished

A fairly practical conversation about ways of setting up ADO turned into a philosophical conversations about the difference between the project and product mindset, particularly about how products are never finished and our tools for managing products need to reflect this. Also this week:

• Designed a workshop to turn strategy into action plans.
• Wrote up a simplified version of a product strategy to get feedback.
• Took part in a workshop on how better manage lines. People over process was the general consensus.
• Wrote a user guide to OKRs to help product teams align their work to the group strategy. My challenge was designing the way we do OKRs to be as lightweight as possible but still give us the benefits of focus, alignment, autonomy, etc.
• Watched a session on architectural decision records and the process in github for generating Word docs.
• Got pimped out to other teams (Kidding, I enjoy helping out where I can).
• Looked into long-term impacts of using AI, especially on strategic alignment and financial investment, which could be summed up with the phrase, “you get what you pay for.”

Other things that’ll never be finished

Started writing blog posts I’ll never finish. One on the economics of AI in higher education looking at how costly it’ll be for universities to adopt AI (because it’s a volume play with poor ROI for orgs with a low number of actions AI can do). Another on use cases for AI in product management using the six use case primitives and applying them to different product activities, essentially building on the idea that AI is good at solving problems that have already been solved and making the case for getting rid of repetitive work so we can focus on creative thinking about novel problems.

I read:

Pitch

Started reading Pitch by Danny Fontaine.

Exploring AI’s Role in Education

Lots of interesting ideas in WAO’s thought-pieces on AI in education.

Let’s debunk a myth of Now-Next-Later

“What the time horizon roadmap gets you is the flexibility to show deadlines and milestones where needed, and never get trapped by showing a bunch of arbitrary deadlines.” I’m still not convinced, but Janna’s the expert so listen to her, not me.

Feedback Is Not an Attack

“Feedback should be thoughtful, specific, grounded, and mutual. If you’re not doing it with intention, you’re not doing it right.”

(Also I added Ashley’s blog to my feeds along with about a hundred other writers, bloggers and weeknoters)

Discovery and delivery are different

Ragan McGill is right. This brilliant post describes some of the ways product discovery/development and delivery are fundamentally different, and how applying the thinking of one to the other causes problems. “Treating delivery like discovery is like running scientific experiments on an assembly line – it slows everyone down. Treating discovery like delivery forces premature decisions and suffocates learning.” If you’re a product manager switching between them every day it’s no wonder things get confusing.

I thought about:

Unbundling university

One approach to innovation is the unbundling and bundling of existing products. The more an industry bundles together, the harder it is for an innovator to disrupt it by unbundling. Take higher education, for example. It bundles qualification and accreditation, knowledge and expertise, kudos and achievement, making friends, developing independence, networking, choosing a career, etc., etc. Now imagine trying to unbundle that and pick one aspect to innovate on.

That’s what the ‘YouTube is free university’ proponents get wrong, that just being able to watch a bunch of videos may impart some knowledge but that is one very very small part of what people get from university. If attending lectures and remembering information was all there was to university, higher education would be easy to disrupt. But there is so much more, and it’s all interwoven, and so well-established, that it really really hard to innovate on, especially for universities themselves.

Internal product life cycle

Internal product life cycle looks very different to customer-facing products. The usual product lifecycle shows the number of users going up through growth, levelling off with a mature product, and then a declining number of users is a signal to the business that the product is going into decline. But for internal products, the number of users isn’t a sign of success and decline isn’t signalled by lessening number of users. An internal product usually only comes to an end if the business changes what capabilities it needs, e.g., outsourcing payroll or closing down an ecommerce offer.

Measuring AI

The problem with the ‘using AI equals better efficiency and productivity’ narrative is it misses the nature of general purpose technologies. Asking and trying to measure the time or cost saving of using AI is like trying to measure the time or cost saving of using the internet or electricity.

The perfect process

There is no single perfect product development process. Obviously. The “right” process depends on the team, the product, the organisation, and so many other factors. I’m not a fan of overly standardising things that work better flexibly, and product development process is something teams should be allowed to decide for themselves. Sometimes, a process is implemented for reasons other than giving teams the best chance of developing great products.

The product of Theseus

What is a product? It is the sum of user interface, policies and business logic, technologies, budget, people’s knowledge and skills, etc., etc. Any single part can be replaced but the product continues to exist. In fact, over time, all the parts can change or be replaced and the product still exist.

I did:

Completeness

Yeah, I know no product is ever finished, but ‘complete’ is the closest word I can find to describe the approach of a product offering all/enough of what it’s users need. It’s been a big part of things I did this week along with this stuff…

• Wrote up last week’s strategy day as a first draft presentation to get feedback.
• Talked about helping our product teams adopt OKR’s to help focus on their most important strategic priorities.
• Went to the Salesforce Agentforce World Tour.
• Discussed standardising data systems and integrations to simplify things for users. But getting there is going to be anything but simple.
• Chatted about how we could use a citizen developer approach to encourage more automation, and what the safety guardrails might look like.
• Started planning some product strategy sessions for the product teams in my group.
• Did some consequence mapping for how different decisions might play out over the next five years. It helped with the rationale for some of the decisions we’re making now.
• You know how there are certain pieces of work that stay with you as highlights of your career? Had one of those this week.

I read:

Who does what by how much

Bought this book a while ago and as I had a bit of focus on OKR’s this week I decided it was time to read it. Although I don’t agree with everything, and some of the leading edge thinking on OKRs has moved on in the time since the book was written, the majority of the book has really good advice on how to actually become more outcome-focused, which is a big step past all the ‘outcomes over outputs -but we don’t know how’ rhetoric.

What is business value anyway

Revenue? Profit? Yes, but as Kent says, those are lagging indicators and product teams can’t use them to prioritise. So they need to identify a north star metric that, “leads to revenue, reflects customer value, and measures progress”. As much as I agree with the concept a north star metric and how it helps prioritisation and alignment, in practice in complex organisations, the product manager’s job is to balance lots of priorities, multiple shifting alignments, constantly changing views on what business value is, and the impossibility of ever getting to an agreed set of metrics that actually have data behind them. There’s an interesting messy space between the best practice frameworks of simple, usually commercial, organisations, and the context product manager’s in complex organisations work within. I kinda love that mess.

The AI execution gap: Why 80% of projects don’t reach production

I think it’s right that so many projects fail. It’s part of the collective learning lots of organisations are going through at the moment. Eventually they’ll settle on an understanding of the economics of AI that tells them it’s really costly to invest in and succeed at, and so it’s really only worth it for extremely high volume transaction businesses where there’s an efficiency gain to be had. I’ve previously talked about adopting AI in the same way email was adopted; that everyone will do it because it doesn’t make sense to be left behind being the only organisation that communicates with letters. But now, I think it’ll follow a different adoption pattern, one that is far more industry-specific.

Change needs change management

“Effective OKR implementation requires thoughtful change management grounded in behavioural science, organisational psychology, and adaptive leadership.” OKR’s, product operating models, or any new thing that seeks to create change in an organisation needs change management.

I thought about:

Building strategy bottom-up

Strategy doesn’t have to be top-down, it is also possible for a team to create a strategy bottom-up, by thematic analysis of all the ideas everyone has for new features, grouped by which user group would benefit, which capability it develops, what kind of value it would deliver, etc., and then choosing which combinations of groups to focus on. It doesn’t matter how you get there, it only matters that the strategy has coherence, makes choices, is aligned with organisational priorities, delivers user value.

Time horizons

What time horizons should product managers be considering and be responsible for? Posts like this suggest as short as the next six weeks. I think product managers should be looking at the next ten years, considering social, technological and economic trends, and how these might inform the direction of the product and the organisation. Of course, they also need to be able to work in the present to deliver value. I guess that’s what makes product management so cool, shifting between now and future, zooming in to the detail and out to the big picture, going between strategy and implementation.

CORE

You’ve probably heard of the POSSE content strategy where you Publish (on your) Own Site, Syndicate Elsewhere. I’m waiting for the first publishing platform (my money is on YouTube) to use GenAI to reformat content for any/every channel. So, if creating videos is your thing, it’ll create a podcast interview and a Medium article, and a LinkedIn post. If you prefer writing, it’ll create an informational video in twenty different languages, and thread for BlueSky. I call it CORE – Create Once, Rechannel Everywhere.

Digiphors

The problem with understanding digital is all the metaphors are about the physical world. It’s more confusing than clarifying.

This week I did:

Where to play

Even for internal products, where to play and how to win questions are still essential for success.

• Watched a talk about leadership by the brilliant Oli Lovell, with gems like “Outcomes are slow magic”.
• Facilitated an all-day strategy session with folks from marketing, engineering, architecture, data and delivery. Went pretty well, got some answers, got good scores on my feedback survey.
• Pitched some cross-team work for a proof-of-concept. Now all the follow-up work.
• Worked on a team costs model to help us make better decisions about investing our time in different pieces of work.
• Went on a mission to find someone with PowerAutomate skills and failed (but failure is all part of learning).
• Played around with grouping work into Epics and Features and writing user stories. It’s been a few years since I’ve used that structure, and it makes me question why and who it’s for.
• Chatted about data quality, and how intractable problems are a messy combination of ownership, incentive, focus, etc., etc.

The numbers

• Tasks completed: 29
• Minutes in meetings: 510.

Not bad for a four day four week with one day in the office.

Old news

Moved my old newsletter posts onto my website so I can delete my Substack account.

I read:

Product Management vs Service Design

I completely agree with Scott about product and service design bringing different but complementary perspectives (same goes for business analysis, content design, development, etc.).

Agile AI

“Problematically, there is no standard practice for how to implement AI in your business. That makes it very difficult for business leaders to reduce their risk of project failure… First, make sure you’re working on the correct business problems. It is difficult to identify business cases for which AI solutions will drive impactful change to the business. Some business problems are not economical to solve with a model because gathering, cleaning, and storing the data are cost prohibitive.” Sounds like you need product managers.

User story mapping

I thought about:

A range of outcomes

When we talk about outcomes, and especially outcomes over outputs, we seem to treat them as conceptually the same kind of thing. But outputs are deterministic, we know what we’re building. Outcomes are uncertain and probabilistic, we don’t know for sure what we’ll achieve. So we should think of outcomes as a range, maybe as best-case to worst-case, or likely to unlikely. We should talk about possible outcomes and not get caught in the trap of treating like better outputs.

AI economics

Last week I mentioned how AI might affect product pricing models, and this week it’s how AI might affect software economics. If cost-per-token becomes a metric product teams monitor to understand the costs of using AI in their products, how might that affect how they use it? I know understanding true cost is next to impossible but it seems very likely to be that AI will change product development costs.

Failing gracefully

Thought about failure quite a bit this week. Read a bit about Amy Edmundson’s spectrum of reasons for failure, reflected on a few recent failures and where on the spectrum they sit. Mostly, I think we still regard failure as a bad thing, something to be avoided, often by having more checks in place. But I think that approach lulls us into a false sense of security because our checks can never cover the unknown unknowns.

I did:

A stitch in time

Some of the interesting stuff I did at work this week included:

• Finalised next week’s strategy day.
• Wrote up some work that is going to require coordinating multiple teams. It’s going to be an interesting thing to figure out as all the teams already have plenty of their own work to do and there are no established mechanisms for handling dependencies like this.
• Prepared some slides for a proposal me and another product manager are presenting to our teams next week. It’ll be an interesting little experiment of product managers pitching work to teams to see how much buy-in we can get.
• Talked through a fantastic impact model that shows how a product affects time-saved (our north star metric) and projected revenue.
• Chat to a wonderful UX designer as I continue on my mission to meet everyone.
• Discussed the metrics that will help us measure and reduce our delivery time.

Not bad for a three day week.

AI-first

Wrote a few thoughts on what AI-first means. To me, it’s different to terms like ‘user-centred’ or ‘product-led’ because they are used to make one perspective more important than others, whilst ‘AI-first’ should be about considering all the perspectives.

Daynotes

Tried to get back into writing daynotes but most of my days are so busy with non-daynote-y stuff that I don’t have much to write about.

I read:

The Trickiness of University Strategy

Roger Martin argues that universities and charities are multi-sided marketplaces with professors in the middle serving all sides of the marketplace, and so need a strategy that balance the different sides.

What made Intercom throw away its product playbook?

Spoiler: it was AI.

There’s an interesting part about how AI affects pricing. If you’re an enterprise SAAS AI product who’s value proposition is that your customers don’t need as many staff, then the usual seat-based pricing doesn’t make sense for your business. So Intercom is changing their pricing to per-resolution model. It’s the first hint of changes we’ll see because of AI that go beyond just adding Gen AI.

4 Lenses on Organisations

Models of models of models.

6 predictions for product teams in the era of AI

Read Airtable’s 6 predictions for product teams in the era of AI. One of them is about the shift from “measuring speed to focusing on time to value, and that is a much better representation of return on investment,” (Inbal Shani, chief product officer at Twilio). It’ll be interesting to see if AI does finally disrupt Schumpeter’s first mover advantage.

I thought about:

Strategy answers questions

If a digital strategy is “business’ answers to questions posed by technology”, and a technology strategy is “technology’s answer to questions posed by the business”, then a product strategy is “business’ and technology’s answer to questions posed by customers.”

Cadence is a killer

Having meetings on a regular cadence of weeks or months enforces large wait times between discussions and decisions. One hour this week, one hour next week, 166 hours in between. Even if you only count working hours, that’s still 36 hours, or 97%, wait time. Which gives weekly meetings a flow efficiency of 3%.

Coherence & coordination

You that autonomy and alignment diagram for teams. Maybe there’s one for product strategy that shows low/high coherence/coordination.

Low coherence / high coordination The strategy lacks a rational logic and has lots of unvalidated assumptions, but everyone knows what they should be doing.	High coherence / high coordination The strategy makes intuitive and logical sense, and everyone understands it and knows what they are doing to achieve it.
Low coherence / low coordination The strategy lacks a rational logic, and is mostly in people’s minds and spoken about in vague terms.	High coherence / low coordination The strategy makes intuitive and logical sense, but not everyone understands it and it isn’t clear what they should be doing.

Team focus is a prisoners dilemma

“The prisoner’s dilemma is a paradox in decision analysis where individuals acting in their own self-interest do not produce the optimal outcome.” It also affects teams interacting with teams.

If your team has two much work in progress, the obvious answer is always to focus on fewer things. But, wait, you say, most of our work involves coordinating with other teams, so we can only work on fewer things if all the other teams work on fewer things, and no team can make those decisions on behalf of other teams. If a team did decide to do less, the affect on would be either they have more to do or they fail to achieve. And so everyone carries on trying to do too much.

I did:

Behind the scenes

Behind the scenes is one of my most hated phrases. I hear it every week and it always makes me think that what’s behind the scenes for one person is another person’s main priority. Everyone’s work is behind someone’s scenes, because no one can know everything that’s going on. I did lots of stuff behind the scenes this week, and here’s some of the highlights…

• Worked with another product manager to think through a future piece of work across both our products. We’re presenting it to both our teams in a couple of weeks and I think it’s going to be interesting to see how we navigate the two teams working together.
• Felt really proud of the team for focusing on investigating options and getting to a decision quickly about where to go next for a piece of work. We got from seven options to one, and now comes the hard bit.
• Realised how hard it is for people to see the impact they have.
• Bit of capacity-building work for the future shape of the team so they can take on more responsibility and have more autonomy.
• Waded into university hiring processes.
• Said goodbye to my amazing line manager.
• Talked tools, and individuals and interactions over processes and tools.
• Made the mistake of posting a late-night thought on LinkedIn. Should have put it on Bluesky where no one would have seen it.

I read/watched:

The genius of John Cutler

Skip over the stuff about SVPG and scroll down to the interesting points:

• “Your biggest challenge is leading a major change effort while keeping the organization running.” – And we probably don’t realise how different those two are, what different mindsets and skills and systems they need.
• “Constraints add up.” – They are complicated, interwoven, structural, political problems that get in the way of doing things differently. Behind every constraint is a hall of mirrors that is confusing to navigate and which no one understands.
• “Product management, as a profession, doesn’t have a theory of change (especially not for organizational change). Outside of “treat it like a product,” and “lead well”, there’s not much.” – Absolutely. It’s pretty ridiculous to think product managers know anything about organisational change.

Roadmaps

“Product roadmaps are a tool for communicating the future direction of your product… how you intend to evolve the product over time, how it might look one day in the future and in what sequence?”

If roadmaps are first and foremost a communication tool, would you still need a roadmap even if no one saw it? I think, yes. I think the act of roadmapping demands critical thinking that is absolutely necessary in product management even if no one else sees it. One of the problems with roadmapspeople is that we get caught up with the visual and what it implies. I think, if you can’t roadmap on a piece of paper in plain and simple language, then you can’t roadmap.

AI eats the world

I thought:

Universities online

I’ve noticed a few universities launching separately branded offers of “University of whatever online”, as if people won’t know it’s online unless they spell it out. It’s like the nineties again. I wonder what research led to the conclusion that offline and online learning have to be different. Why does the study experience have to be split by channel? I think they’ll come to regret the artificial separation too late.

Every product has competitors

Thought about understanding competitors for a product, sparked by a conversation about whether internal products have competitors. I think they do. From a Jobs To Be Done perspective, a product competes with all the other ways people get those jobs done. Manual tasks, emailing requests, spreadsheets, bespoke solutions are all ways people find to help them get a job done. The internal product management work is figuring out and applying the mechanisms that drive adoption of the internal product so it replaces all those other things.

High-levels of software delivery performance are achievable

Last week’s weeknotes had the key insights from the DevOps report. I’ve been thinking about how they make pretty great principles, and so how doing research on the best ways to do x is a pretty great way to create principles for that thing. These principles are pattern for organising around the goal of creating great software and creating them based on research are better than making random guesses or asking AI.

National Health System

I spent some time watching a busy emergency department and chatting to people who work in the NHS. Their general conclusion seemed to be that the system is broken. What I saw was a system that works on triggers. So no predicting and acting ahead. A doctor only thinks about looking at test results once he’s been notified they are there, which inevitably causes delays. I completely agree that the NHS needs more money, but that isn’t going to fix an inefficient system.

What business are we in

MacDonald’s isn’t in the hamburger business, they’re in the real estate business. Knowing what business you’re in matters for good strategy. And one way to identify it is to ask what is truly your unit of analysis. Land, not hamburgers. What business is Netflix in? Attention, not movies? Or for the product I’m currently working on – data, not campaigns. We’re in the data crunching business. That’s how we drive marketing automation success. More data in, more data out.

The problem of overstated problems

It’s not easy to state a problem accurately and completely so as to understand whether it is truly worth solving, or how we would know if it had been solved.

Intuitively, we could state a problem as a simple formula of how many people have the problem multiplied by how much the problem affects them, multiplied by how often or how long the problem lasts. Problems that affect a small number of people in a small way and occur very rarely aren’t worth solving. Problems that affect lots of people in significant ways, very often or for a long period of time, are definitely worth solving. But most problems are somewhere in between.

We overstate the problems we want to solve. We make them seem easier to tackle or are more certain than we should be about the outcomes solutions might achieve.

Discovering worthwhile problems doesn’t always mean discovering solvable problems. Finding solvable problems can mean a focus on doing the easier things which invariably have low impact.

So, us product managers operate in the overlap, trying to discover solvable, worthwhile problems. This is where the outcomes and the impact are. But it’s a narrow space.

This is the product manager’s paradox; solving easy problems is easy but it isn’t worth doing, solving difficult (or wicked) problems is difficult but it’s hard.

This week I did:

Balance

Among other things, I…

• Stuck to my new approach to planning my work for the third week in a row. It seems to be working pretty well, probably because it’s not particularly radical. All I do is decide what I want to do this week, add some public accountability, and then get stuff done.
• Went to the CX Circle event and learned some website traffic trends, most interestingly that desktop traffic is growing more than mobile.
• Did some complicated roadmapping work, which was kinda fun. I don’t often have time to get deep into things.
• Planned for an upcoming strategy day that will bring together marketing people, data people, engineering & architecture people, and product & delivery people to think about the next year.
• Chatted through some of the implications of our team moving to more of a build-run-own approach, particularly around access to tools and how much processes need to be standardised (you know how I feel about standardisation).
• Had a conversation about team autonomy and how alignment balances that autonomy. Balance, in all things, is the key.
• Talked about knowing when to quit.
• Got two AI’s talking to each other with humans doing their bidding in between.

The numbers

Tasks completed: 38

Minutes spent in meetings: 885

(First five day week in a long time. Going to have to do something about that.)

I read/listened:

Money stories

Rich Mironov talks about how product managers need to talk about their work in financial terms, which I completely agree with, alongside also telling user stories, systems stories, impact stories and so on.

Minimal product management

Love this idea of picking your four product management tools. Mine are:

• User journey mapping – If one of the core tenets of product management is “create coherence”, then showing the user’s experience the product in a coherent way, and what we’ll need to build to make that coherence a reality is essential.
• Theory of change – Showing the logic of how inputs enable activities, which generate outputs, which allow for outcomes, which achieve impact is amazing for surfacing assumptions, pushing logical thinking, creating a plan.
• Step-by-step – A simple listing technique that brings clarity to actions, and which is so often missed when we only talk about the “next steps” but not what comes after that and after that. If you can’t tell me how you think you’re going to get from A to Z, then you probably aren’t going to get there.
• Kanban – Visualise work, track flow, see current status, limit work in progress. A good Kanban is a thing of beauty.

Imagine a tool that could map user journeys and connect a theory of change at the outputs level, show the activities as a Kanban with the step-by-step for each work item, and the outcomes as metrics. That would be so cool.

State of DevOps report

Read this distilled summary of the 2024 state of DevOps report. The full report goes into the Four Keys, and how to improve measuring them, although I prefer my phrasing of the key metrics. The seven key findings from the report are:

1. AI adoption increases as trust in AI increases
2. User-centricity drives performance
3. Transformational leadership matters
4. Stable priorities boost productivity and well-being
5. Platform engineering can boost productivity
6. Cloud enables infrastructure flexibility
7. High-levels of software delivery performance are achievable

AI as normal technology

This is amazing work. “Over time, the superintelligence view has become dominant in AI discourse, to the extent that someone steeped in it might not recognize that there exists another coherent way to conceptualize the present and future of AI… AI as normal technology is a worldview that stands in contrast to the worldview of AI as impending superintelligence… We hope that this paper can play some small part in enabling greater mutual understanding, even if it does not change any beliefs.”

I thought about:

Algorithm of user behaviour

Every product has one, but I’ve never seen it documented. The if-then logic of what a user does and what happens because of that action. Could also think of it as the ‘rules’ layer. I might try to create one for a simple product.

Roadmap zero

You’ve heard of inbox zero, right? What about roadmap zero? Roadmap zero is about taking continuous improvement thinking, the law of diminishing returns, and predictive planning techniques to figure out what a product might look like when it’s no longer worth investing in to keep adding features.

Requirements

I don’t have a problem with requirements, but I do have a problem with the assumption that they need to be known upfront and fixed before work starts. In my experience, every requirement is negotiable and is better shaped through multiple conversations.

I did:

Countdown

Most of my time was focused on team logistics of budgeting, hiring, planning and such. I need to pull all of this into a plan to make sure I can get it all done on time. But I also…

• Got involved in a few pieces of work to try to keep them on scope. It’s interesting to try to understand what causes work to expand it ways that create delays and more complexity.
• Planned out the agenda for a strategy workshop in a few weeks.
• Talked about how we think about the future life of products, that continuous improvement always hits up against the law of diminishing returns, and that the balancing of how much it costs to keep using a product vs how much value it delivers is the ultimate definition of success.
• Diagrammed our new organisational structure to help me understand how it works. If I was to write a blog post about it, it would be titled “Breaking down silos by optimising for the power of weak ties”.
• Did some problem/solution/success mapping to help me reverse engineer and understand a strategy. Might try turning this into a workshop.
• Went to a product community of practice session about Jobs To Be Done.

The numbers

• Number of minutes spent in meetings: 690.
• Number of tasks completed: 35.

(Another busy four-day week)

Focus for May

I used to do monthly planning and retro sessions with myself, but as I haven’t had much time over the past year to work on personal projects I stopped doing them. I’m trying to get back into the habit, even if just to give me focus on a few goals:

• Set up my product resource library on a subdomain of my website (and decide what to call it). Done (but now there’s lots more to do).
• Write a blog post about product strategy. Started.
• Complete AI product management course. Starts next week.
• Get running again. Maybe tomorrow…

I read/watched:

Predicting the future, with dice

Nicholas Brown wrote about educating leaders on predictive planning. It’s a brilliant example of using a simple exercise to explain a complicated but very powerful technique. I bought his book too (so blogging and content marketing do work).

Why AI Is Our Ultimate Test and Greatest Invitation

Tristan makes an important point about why AI is such a wide-sweeping game-changer. He says that when you make a technological advancement in rocketry, you only make a technological advancement in rocketry. But when you make a technological advancement in intelligence, you make a technological advancement in every field of human endeavour.

How Anthropic Designs for AI

I thought:

My thinking hasn’t been very clear this week because of a lack of time. I’ll add the thoughts below to help me come back to them in the future but they don’t make much sense at the moment.

Situation, risk, consequences

I have a vague idea about a different way to think about risks, seeing them not assessed in isolation but within a wider ‘situation space’ so we can see if/how things that aren’t risks affect things that we do consider to be risks. And then from the risks we think more about consequences rather than making guesses about likelihood and severity.

How multiple strategies work together

In a complex organisation, there are often multiple strategies that teams have to figure out how to use to guide their work. My thinking about it at the moment is about trying to identify the factors that are relevant to all strategies but applying differently. For example, all strategies are ultimately about value but some have different time horizons. So, one strategy about delivering present value and another about enabling future value could work nicely together.

I did:

Intersection of intersections

This week felt like lots of things intersecting with each other as their shape emerges, including strategy, technology, business, AI, product practice, education.

• Discussed how we might shape the future of our tech stack and all the pieces we need to get into place.
• Joined a couple of webinars about AI, one on how it affects product development and the other on how it affects pedagogy.
• Went to three show and tells, and thought about what equivalent of looking outside the organisation might be.
• Did some prep work for a strategy session, mostly around trying to get all the ideas to the same fidelity so they can be talked about equally.
• Chatted about AI learning assistants. And about the difference between a university providing one and a possible future where users already have their own AI assistant and the university provides the data.
• Talked about business and budgets. Made me wonder about ‘business sense’ and whether it’s any clearer than ‘product sense’.
• Reviewed a draft strategy document. Not sure my feedback will be of any use but the exercise helped me clarify some thoughts about strategy that I should blog about some time.

The numbers

Number of tasks completed: 37.

Number of minutes in meetings: 420.

Another four day week for me. I could get used to this.

I read/listened to:

Change your mind

That’s the secret to good forecasting of the future – changing your mind in light of new evidence – and what is product management if it isn’t hypothesising and creating a future change?

Total competition

On a recommendation from Scott Redrup, I started reading Total competition, about Formula One. This line jumped out at me, “winning this engineering war is the foundation of winning a World Championship.” The same can be said for digital products. You might be able to vibe code your way to a prototype but if you want a reliable, secure, scalable product you need good engineering.

How different disciplines see, think and act

If ever there was a chance of understanding what ‘product thinking’ is, then this paper is a good start. It doesn’t mention product thinking, but it analyses lots of other [discipline] thinking, in particular design thinking, systems thinking and entrepreneurial thinking. I’d argue that scientific thinking is the closest to, and basis of, product thinking, as it requires criticalness, openmindedness, hypothesis testing and looking for true cause and effect relationships.

Backlogs

If you’re adding work to your backlog that isn’t aligned with your strategy, then you’ve got bigger problems that deleting things isn’t going to fix.

Overcoming inertia: Experiments trump analysis

“The most successful transformations I’ve witnessed working at Red Hat shared one vital characteristic: they balanced rigorous analysis with practical experimentation, making incremental progress and building confidence through real-world tests rather than betting the whole budget on an unproven master plan.”

I thought:

No unifying theory

Following on from last week about product vs service design, I’ve been thinking about what differences the disciplines have that makes them seem like they contrast rather than compliment each other.

One of the things I’ve come up with is that product has no unifying theory, whereas that’s what design excels at. Design is all about bringing parts together to make a whole, and this thinking is reflected in artefacts like service blueprints. Product on the other hand, deals with parts that don’t fit together, not exactly in isolation, but certainly without a cohesiveness that design has. That’s not a lacking on product’s part, it’s the reality of the wide range of things product has to consider (and the historical approach of how humans organisation knowledge). There is no way to unify the psychology of individual behaviour change with economics of behaviour change at scale in the market with an organisation’s strategy with investment choices in technology with lots and lots of other things.

RACI ruined us

It told us we can abstract the complex social interactions required to navigate organisations into simple frameworks. Lots of other frameworks try to do the same but all with the same degree of failure. You can’t abstract away social interactions into a framework, and you shouldn’t try.

If I was going to write a book…

…it would probably be about the first principles of product management, things like the scientific method as the basis for the product development process, Dialectic reasoning as the basis for decision-making, stakeholder negotiation and communication. It would be interesting to explore some ideas like user stories are boundary objects and maybe product metrics should be constructivist.

I did:

Unevenly distributed

The future is funny like that, but I like that I get to work on evening it out. Also this four-day week:

• Did some planning work for three pieces of slow moving work.
• Met our new engineering lead. She’s fantastic and I don’t envy her the task ahead.
• Discussed ways to assess features and functionality to help us understand where we might need to focus improvement work in the future.
• Validated some assumptions about team skill-sets.
• Listened to our product director talk about the Decision Stack, which was really interesting because I’ve done some previous thinking about it (here and here and here).
• Chatted to an interaction designer as I continue with my mission to meet everyone. We talked design systems and about whether interaction design will change if AI agents become more widely used.
• Talked about metaphors for product strategy, starting with Formula 1 teams making choices about tyres, suspension, gears, etc., to perform against competitors who are all in the same environment (race track) but have different resources and capabilities they have to make choices about. It also fits nicely because there are organisational choices in the R & D space about whether to invest in suspension or gears which affect the choices that can be made in the operational space (the team can’t leverage different gear ratios if the development didn’t focus on gear boxes).

I read:

Psychological Safety vs. High Standards: A Misunderstood Dynamic

This is a really interesting article about psychological safety, and presents a positive and helpful challenge to the argument that psychological safety is weakness. It shows how high psychological safety fits with high standards to create an environment that is constructively challenging.

Not product thinking

This is not product thinking. Product thinking is not about features and interfaces. I’ve seen a few of these perspectives recently. The “product vs service design” positioning is really unhelpful. It always tries to make one more important than the other, when really, both are essential perspectives for creating good products and services. Can’t we all just get along?

Agent-ready

I was thinking a few weeks ago about whether products teams are thinking about how to get their products ready for AI agents, and then Ben Whitfield-Heap gives me the answer.

It’s really good to see product people thinking about how agents will interact with their products because MCP is going to change things.

Systems loopiness

Doug Belshaw studied Systems Thinking at the Open University, and wrote and blog post about it, which was referenced in the Open University’s System Thinking community of practice. See? It’s all just one big looping system.

I thought:

Know what you bring

The role of a product manager is not standardisable or generalisable. It’s just too context-dependant for that. So, part of your job as a product manager is to do the intellectual and emotional work of figuring out how you best add value to your organisation. It should probably be a combination of what your organisation needs, what good industry practices you think can apply, and what your particular areas of interest and skills are. No two product managers are the same, and given the same product (in parallel universes), should develop it differently.

Open systems and feedback cycles

It’s good to see the discussion about the length of cycles continuing. Unfortunately, it seems to come down to what’s considered acceptable within an organisation rather than what would really work better.

Going deep, working in cycles is because we recognise that ambiguous product work exists in an open system. And one of the key characteristics of open systems, which makes them different to closed systems, is that they need feedback to achieve the goal. So we work in sprints to create a mechanism that brings that feedback into product development. If the product team can’t get any feedback, there’s very little point working in sprints (as they are working in a closed system). If they get feedback monthly or quarterly, then they should match the length of their sprints to that. Having two week sprints, because it seems like the done thing, but not getting feedback every two weeks creates a lot of admin overhead without much value.

It’s a similar problem for all product practices. Applying them in situations they weren’t designed for is wasteful. Understanding those practices deeply, why they are the way they are, what problems they are trying to solve, is essential for applying them well.

Why can there be only one?

Why do so many organisational structures have one person at the top? Companies, governments, militaries, etc., all have a single person to hold ultimate authority. Is that really the best way to run an organisation?

Nonprofit product

Got linked to from an MTP article.