Category: Weeknotes

I did:

Honing-in

This week was a honing-in kind of week. A few things I’ve been working on are becoming clearer, especially what I’m trying to achieve with them, which always changes (in a good way) as time moves on. Did lots of other things too:

• Presented my eight product KPI’s and chatted to one of our data analysts about them.
• Met our new delivery manager. They are fantastic and already making a difference.
• Progressed a piece of work that joins some new tech and data with existing, so the challenge is going to be how to make them make sense to users, but really interested to see what it does for performance.
• Picked up some compliance work, which I always enjoy. Translating regulations into a product is quite different from translating user needs.
• Used our emerging product capability matrix in a coaching session to frame which skills to demonstrate in a piece of work.
• Set one of our product managers off on some new work. Really keen to see where he takes it.
• Talked about the importance of explicit end-to-end journeys and not leaving it up to the user to find their way.
• Set up a little chat group about AI in product.

I read/watched:

Only Variety Beats Variety

The Law of Requisite Variety is one of my favourite laws. Mike Fisher says, “Does my organization’s internal variety match the variety of the environment it operates in? If the answer is no, you have two options. You can attenuate the environment, meaning narrow your scope, focus on fewer customer segments, simplify the SKU set, or limit the markets you serve. Or you can amplify your variety, meaning decentralize decisions, add sensing channels, shorten feedback loops, and increase the diversity of perspectives in your decision rooms.”

Common knowledge is the secret engine of social life

The Product Culture Shift

“Adding product management to more traditional software infrastructure organizations, sometimes with a shift towards platform engineering, is all the rage today. As someone who has done both these things, it doesn’t surprise me to see so many people struggling to make it work. Both of these shifts require going from a siloed, process, tech-focused mindset to a portfolio, usability, and customer-focused mindset. This is a hard transformation, and it’s easy for people who have spent their whole career building infrastructure to misunderstand what product and platform really mean. So I thought I’d share the secret to making this work.”

Matrix vs. hierarchical organisations

Interesting piece on leadership in matrix vs. hierarchical organisations. What it misses is that they aren’t mutually exclusive, both can operate at the same time and with varying strengths in different contexts. Authority can be hierarchical and capacity be matrix, which makes for a far more interesting (and real and pluralistic) situation.

I thought:

Opportunity, leverage, advantage

Been thinking about a different framing to my ‘problem, solution, success’ framework for product strategy. ‘Opportunity, leverage, advantage’ follows the same reasoning (set the boundaries to focus on what change is required, try multiple things to effect that change, measure which of those things achieves the change), but sounds more business-y. Although product managers understand ‘problem’ to mean anything that’s getting in the way of success, I get it that some people think of problems as negative things, so hopefully this framing is more positive.

It also makes the action part of the strategy more explicit by calling it leverage. In my thinking about ‘solutions’, I have ‘levers’ as the things that actually make the change based on hypotheses but they were always a bit disconnected.

Throwaway frameworks

I’m increasingly interested in how we might use throwaway frameworks to help understand problems on the fly. Usually, it goes like this: a group of people on a video call encounter a problem, they talk about it from different perspectives, and leave with different understandings. But if they quickly put together a throwaway framework to help them visualise and frame the problem, they might leave with a better shared understanding.

The Fermi Paradox

I’m fascinated by the Fermi Paradox. Not because of what it tells us about aliens, but because of the logical thinking it demonstrates in identifying the factors that contribute to the problem and enumerating an exhaustive list of possible solutions. Maybe the product paradox is why we can’t come up with the equation for successful products.

Implementing in the status quo

Sure, change is hard, but implementing in the status quo ain’t no picnic either.

I did:

Shaping product strategy

Had the week off work and actually managed not to look at emails or teams messages. It gave me some thinking time to consider product strategy, why we need one, what it might look like, how it’ll help us. My temporary conclusions/assumptions to test are:

• A strong vision really is essential for developing a product strategy. It’s the starting point for the hypothesis the strategy expresses and the end point that tells you if that hypothesis was correct.
• Beware of your data – Using data about successful users doesn’t tell you much about those your product didn’t work for, and they’re the ones you need to know about to figure out what you need to do differently. Generic industry data is probably more useful and less misleading than your own data.
• Preserving and amplifying an existing competitive advantage is easier than creating a new one, even if it’s more limiting.
• No single tool or framework or way of thinking about strategy is enough on its own. Putting together different approaches helps create different perspectives and so a more well-rounded strategy.
• There are two ways to use Ansoff’s matrix (probably other tools too); as buckets to put decisions you’ve already made in to see how they relate (we are going to focus on new products in our existing market, which means we aren’t going after new markets), and as a decision-making tool where you choose how risk tolerant you want to be and (we only want low risk expansion which means we’ll be providing existing products to existing markets).
• Direct distribution is at the core of any product strategy we develop because our users have to use our products to study our courses. The question we need to answer (especially as agentic AI use grows) is, should it stay that way or should we create other distribution channels?

I read/watched:

A Deep Dive Into #NoProjects

I’ve been reading Bob Marshall’s stuff for years. He’s a fantastically knowledgeable thinker with solid, well-informed opinions. This post uncovers the challenge with the shift from project-oriented organisational process for product development to more modern, agile, product-oriented ways.

Bob say, “The harder work — and the more important work — is the assumption shift itself. That means making assumptions explicit in governance conversations, building funding gates around learning rather than plan adherence, rewarding teams for honest discovery rather than confident prediction, and developing leaders who can coach the scientific thinking pattern rather than just demand results.”

How big a deal is AI?

Benedict Evans talking about AI, applying the logic of previous emerging tech shifts, and that we can’t know whether anything will be different this time around.

Living lab for using AI

Dan Shipper talks about how Every, a media and software company, is using AI, and what he thinks the near future of AI usage inside companies looks like.

I thought:

AI as intermediary

I’m adding another way for product managers to think about AI to my list. I’ve currently got AI as a tool, AI in products and AI in the market, and I’m adding AI as an intermediary.

Thinking about AI as an intermediary helps us consider what happens when AI gets in between our users and our product because it’s part of another product. For example, Google’s business model has always been to get in between organisations and their customers, and they are going to use AI to turn that up to eleven.

As AI becomes an intermediary in marketing and product interaction, we’ll have lots of change to consider:

• Email marketing – AI in email clients will summarise emails and present to points it thinks are important to the user, which means email marketing teams won’t be able to control the message their customers get.
• Advertising – AI will generate hyper-personalised ads. Ad teams won’t actually be able to know what every customer has seen, what message they’ve understood.
• Search – AI will provide answers to search queries in ways that make it unnecessary for users to visit websites. Marketing teams won’t be able to rely on search results to bring users to a website.
• Using products – AI agents will be performing actions on behalf of users. Product teams will be building products without user interfaces because AI agents don’t need them.

Cat and mouse

If you don’t know what your competitors might do in response to your strategy, you don’t know your competitors well enough. And if you don’t know what you’ll do in response to their response, you don’t know your strategy well enough.

I did:

Conjecture

Three day week so very busy having lots of conversations about all the new work we’re doing. I love this phase of product work. It’s high energy, high ambiguity, and high fidelity guessing, which is why ‘conjecture’ is my word of the week. Also did this:

• Chatted to product managers about defining outcomes and scoping work to match. It’s been a opportunity for some good product thinking about how to set scope that is deliverable by the deadline but still achieves an outcome.
• Technical proof-of-concept for bringing user behaviour data from websites into our marketing automation platform.
• Thought about ways of building consensus and support for a new product and decided using an existing product to seed usage has a good chance of success.
• Talked about three ways to use data in product work: new opportunities for product development, operational reporting and evaluation, strategic performance analysis.

I read:

Platform Product Management

Nikhil Shrivastava says, “The modern platform PM is no longer responsible only for APIs, SDKs, documentation, and developer experience. Those still matter. But in many commercial platforms, the PM is also designing business systems, operational workflows, monetization architecture, ecosystem incentives, compliance boundaries, and multi-persona product journeys.” I completely agree. Platforms are becoming the cool products, and working on just the technical stuff isn’t enough for platform product managers any more.

Vibe coding is obsolete, product management isn’t

Jeff Gothelf talks about how what Andrej Karpathy, research scientist and founding member of OpenAI, said about agentic engineering is actually just product management. I suppose some of that is true, but only about product management as it is now, not as it will be in the future. It’s a little embarrassing that engineering is changing so quickly and us product people are still hanging on to a soon-to-be out of date idea about what we do.

Seven Myths about AI and Productivity

Fascinating article by Dritjon Gruda and Brad Aeon about the productivity and economic benefits of AI. The conclusion is that its different for different organisations in different situations.

I thought:

Started vs. Finished

What does the number of pieces of work started versus the number finished say about an organisation?

	High finish rate	Low finish rate
High start rate	+: Lots of work gets done. -: Lacks discernment, nothing gets stopped.	+: Good agile decision-making. -: Starting work that never gets finished is wasteful.
Low start rate	X	+: Maximum ROI, not much waste. -: Not getting enough done.

Organisational taxonomies

What organisations call things, what those things mean, who gets to define them, will be increasingly important as AI becomes part of organisational operating systems. AI will need those things clearly defined to treat them consistently.

Opportunity cost is a killer

I’m doing this but could I be doing that instead, or that other thing, or doing more analysis to find things I don’t even know that I could be doing yet.

Judgement is king

“Use AI at the speed of judgement” is the new “ship only as fast as you can learn”.

I did:

Move fast and brake things

This week was a lot about quickly figuring out what to stop. Or why that work started and whether it’s right to carry on. That involves lots of talking to people, getting different perspectives, looking at data, considering end-to-end, and making decisions about whether to speed up or slow down. Did this stuff too:

• Presented new opportunities to stakeholders, all of which they approved thanks to the solid thinking our product managers did.
• Talked about doing cohort-based reporting so we can see the difference between users who are successfully completing their enrolment and those that aren’t.
• Worked on a marginal gains strategy. There’s lots of thinking to do that will help us focus on the right things in the right way as returns diminish.
• Avoided a sabotage moment.
• Started planning the next six months of roll-out for one of our products.
• Used Microsoft Planner to organise some work. It’s changed a lot so I might have to update my guide.
• Did some interviews for a senior product manager role.

I read:

Rhizomes FTW

I love rhizomes. It’s my go-to mental model for organising without a centre, so it was great to read two things this week about rhizomes. Rachel Wood exploring rhizomatic service design, thinking about services as non-linear, interconnected, adaptive ecosystems that are constantly evolving. And Steve Messer shared some links to interesting thinking about rhizomes.

Continuous Discovery Habits That Actually Work

Listened to Melissa Perri’s round out of continuous discovery habits. Made me realise how much I miss the pace continuous-x work, but also how it’s only appropriate in certain circumstances.

Product strategy

Watched Ant Murphy’s talk about product strategy, which was cool and all, but like so many talks/posts/articles about product strategy, talk about what it is rather than how to do it. I don’t think I’ve ever seen anyone explain how they created a product strategy. It’s both strange and understandable at the same time. Strange because of how much a product manager’s job is about product strategy, and understandable because strategy is an ongoing emergent thing that is difficult to explain.

I thought:

Moving the goal posts

The problem with the metaphor is that in sports the goalposts don’t move, and so moving them is considered unfair. In business, the goalposts move all time and that’s a good thing.

The difference between wrong and getting righter

Ignore the grammar, it was never my strong suit, but I was thinking quite a bit this week about the difference between unitarist, binary, right/wrong thinking and the idea there is an end state to be reached; and pluralistic, more or less right thinking that recognises constant change as the norm. These co-exist but they feel mutually exclusive. You can’t have both and not have them conflict each other because they see the world in completely different ways. And there doesn’t seem to be any way to reconcile that conflict without changing people’s entire paradigm. It’s an interesting meta-problem.

MOPEDD teams 🛵

We’re experimenting with hexagonal teams (which is obviously twice as good as a trio). These teams that have six roles; marketing, ops, product, engineering, design and delivery. Putting people together is easy. Helping them reach a shared understanding is going to be the hard bit, so I’ve been pondering the different concepts and perspectives each role brings and how they might fit together. Maybe marketers think about audiences and campaigns, whereas maybe designers think about users and journeys. Where is the overlap in these concepts that helps create common ground and shared understanding?

I did:

HSLD

Universities have an annual cycle of students enrolling, starting studying, completing their first assignment, etc. It’s a cadence that drives everything else that happens. It gives us product people focus but means if we don’t ship in time, our work isn’t going to have impact for a whole other year. This week has mostly been about:

• Discussed service-level KPI’s, including switching our thinking from funnels to cohorts. I’d like to mock-up a dashboard to help me get my head around it but I doubt I’ll get time. Luckily, we’ve got fantastic data analysts who do a much better job than I would.
• Reviewed a whole bunch of new features as part of a fixed scope piece of work. Sometimes I think we’ve been convinced that agile is the only way to do things right, but it’s just not true. Right tool for the job.
• Pushed a couple of ideas forward through technical feasibility analysis that have been suffering from a flow efficiency problem (small pieces of work with lots of time in between them).
• Kicked off some new work with a new way of working for product managers. It’s going to be a challenge to do quickly but it’s an interesting part of repositioning product managers as responsible for outcomes (changing user behaviours in ways that get business results).
• Enjoyed a coaching session talking about outcomes.

I read:

Webinars

Watched Jeff and Josh’s webinar on prompting AI for outcomes using their ‘who does what by how much’ template to generate ideas for achieving that outcome. And I watched four four’s webinar on using AI to organise and analyse customer feedback.

You can’t fake belonging

“The best organizations don’t just give you a paycheck. They give you a shared language, a sense of purpose, a reason to show up that transcends the specific task in front of you. That is not a recruitment tagline. That is, increasingly, a documented competitive advantage, and it is built, or destroyed, one interaction at a time.” Interesting points about the effect a sense of belonging has personal and organisational performance.

Shipped Isn’t Solved

“…speed is an amplifier, not a strategy. It amplifies whatever you point it at. If you point it at a deeply understood customer problem with thoughtful design, you get to a better product faster. If you point it at a half-understood problem with no design thinking, you get to the wrong answer faster.” Arguing that adoption is the biggest constraint, which I agree with, and that’s why product managers care about time-to-value, not time-to-delivery.

No rules rules

Trying to get back into using my Kindle for reading so I bought Reed Hastings and Erin Meyer‘s No Rules Rules. It’s about how “Hastings rejected the conventional wisdom under which other companies operate and defied tradition to instead build a culture focused on freedom and responsibility, one that has allowed Netflix to adapt and innovate as the needs of its members and the world have simultaneously transformed.” The implication is that organisational culture positively correlates with business success, which is impossibly hard to prove.

I thought:

Shots on goal

One of the problems with product managers working on the same product for a long time is that it often means they don’t get to build up the experience of dealing with different problems. I think, the more shots you take, the more you goals you hit, and the better judgment you develop from the experience of winning and losing. Maybe the measure of product managers is how many how shots on goal they have.

Decisions in the garbage can

It’s an unfortunate metaphor because it suggests everything in it is rubbish and that’s just not the case, but the garbage can model is a really useful for thinking about how decision-making works in organisations like universities.

In the garbage can, decisions take a long time to be made, involve lots of people with lots of different perspectives, they change as they are being made, and they don’t always stay made.

At first glance, that seems like an ineffective way to make decisions, and the obvious way to improve it seems like it would be to add structure, process, documentation. But garbage cans resist that. The only way to make decision-making work in the garbage can is through relationships, discussion, influence, negotiation.

Jonah Berger, in his book Contagious, says ideas move through people and culture in predictable patterns. They spread like social viruses through networks, relying on human psychology, social dynamics, and the environment. Decisions are the same. Decision-making in the garbage can relies on having a mental model for how things work in the garbage can that closely matches reality.

What if bottlenecks are release valves?

Not quite sure what I mean but I was wondering what would happen to a system of work that had no bottlenecks, one where everything flowed at maximum capacity all the time. Sounds to me like it might have some knock-on effects, so maybe the bottlenecks serve a purpose.

I did:

Focus

Focus is such a hard thing. We all know we need more of it but can’t really say how we’d know if we had it. Is it fewer things? The right things? Short-term or long-term things?

• Went to a session on this quarter’s focus.
• Worked on two features without following any kind of phased product development process because I want to understand what difference process makes.
• More encouraging product managers to hustle and pitch and explore opportunities.
• Planned out operationalising a new product including process design for the team that will be using it.
• 16% of my time this week was spent in one-to-one conversations with product people because I continue to believe it’s the best way to create change.
• Had our half-yearly business review with senior stakeholders.
• Talked about how product managers are positioned with an organisation, especially as part of org change initiatives.

I read:

Conversational design

Scrum as governance, not delivery

Fantastic write-up from Simon Wilson on Dave West’s (CEO of Scrum.org) talk at Agile Yorkshire about on What happens to Scrum in an AI world. Does it become a governance framework rather than delivery?

I thought:

Coherence

Grace Kwon shared her service design 101 course curriculum which centres the idea of mapping. It made me think about what central theme I’d choose for a course on product management and I chose ‘Coherence’. That’s what I think product managers try to achieve, and what makes what we do different to project management, which is about coordination. Coherence is the “logical connection, consistency, and fitting together of parts to form a united whole, whether in ideas, text, or physical systems”. It’s the closest I’ve come so far to a unified theory of everything for product management that helps us understand the a product is made up of architecture, budget, data, process, etc., etc. All different kinds of things that have to work together in complementary (or at least non-conflicting) ways.

AI-enabled PDF’s

Yeah, that’s a thing Adobe released. Why, you may ask. Obviously there’s the ‘sprinkle AI everywhere’ answer, but I think it shows us something else about products that are designed to be used in lots of different ways; they are more open to misuse. The only reason you might need AI to summarise the contents of a pdf is if the pdf has too much poorly structured information in the first place. If you create products without any guardrails then users can use them in all kinds of ways that end up ultimately not achieving their goals (which in the case of a pdf might be to present information). It’s an argument for product managers having a strong stance about their products.

I did:

What a difference a day makes

A product manager said, “You know how in some job interviews they say no two days are the same but really there are. Here, no two days are actually the same.” Navigating complexity and ambiguity, wherever it occurs, is an essential product skill. Did this stuff too:

• Went to a really good problem-solving workshop.
• Released a new product we’ve been working on.
• Tried Jeff Gothelf’s exercise for prompting AI for outcomes.
• Thought about another of my little exercise sessions for exploring opportunities.
• Chatted about working in organised anarchies.
• Was quite impressed with some decision-making in uncertainty.
• Talked about product managers hustling and creating opportunities to increase their learning pace.
• Wrote user stories and acceptance criteria in ADO. It was actually quite fun.

I read/watched:

How to win when software is not a moat

Fascinating interview with Evan Spiegel, CEO of Snap, which I enjoyed more than I thought I would. Its interesting to hear distribution talked about as a moat because it’s always been our moat.

Customer focus vs standardisation

Jason Yip lays out the basics of what makes a product business model or not. A product reuires a deep understanding of customer problems; solutions expressed as repeatable, scalable offerings; and technology, not headcount, drives scale.

The decision stack

Started reading Martin Eriksson’s new book. It’s billed as tackling the alignment problem in organisations, which is interesting to me because I think alignment is over-emphasised, unitarist, unhelpful myth, so I’m interested to see if this book changes my mind.

I thought:

Will AI change product management?

I keep reading stuff that says AI might change how quickly prototypes can be built but the fundamentals of product management won’t be affected. I think this is naive. AI is going to change theories of management, how businesses operate, how knowledge is handled across society. The fundamentals of product management will change because so many other things that affect those fundamentals will change.

I blame blue links

If you’ve been around the internet for as long as I have, you’ll probably remember the story of Google a/b testing 40 different shades of blue for their text links in order to figure out which one was clicked the most. You can only test this kind of thing if you have the number of clicks Google has on it’s links, but I think that part gets missed from UI lore and conversion optimisation. Instead, there’s a belief that making small UI changes will lead to a measurable change in conversion, and in most cases that’s just not true. I believe in making user interfaces easy to use, accessible and inclusive because it’s a good thing to do, but in all my years I’ve never seen better UI significantly change user behaviour at scale.

I did:

Hustlin’

This week involved quite a lot about how product managers sell their ideas, influence the right people, do the right kind of analytical thinking to support the ideas. It seems more like a personality trait and individual behaviour thing than a ‘lets have a process’ thing. Also did this stuff:

• Played around with personal OKRs again. I’m a big believer in them for dealing with uncertainty, but I’m not convinced they work in an organisation with lots of interdependences.
• Chatted about incremental and/or iterative product development, and how path dependency is the biggest enemy of agility.
• Did a few interviews for a senior product manager role.
• Talked about my nudge tools product concept.
• Ran a retro to help guide improvements for the next phase of a complex programme of work.
• Spent two days in the office.

Product meetup

Went to Product MK’s meetup and chatted to other product managers about validating ideas, refining value propositions, and using AI to analyse customer feedback.

I read:

Garbage can model

“The garbage can model (GCM) is a model within the area of organizational behavior that describes the decision-making process in so-called organized anarchies (organizations facing extreme levels of ambiguity in their decisional environments). The GCM attempts to explain how organizations make choices without having consistent, shared goals and how the organizations’ members are involved in these decision-making processes. The decision-making process within the organized anarchies is portrayed as a garbage can into which a mix of problems and possible solutions are dumped, with the particular mix determining the decision’s outcomes.”

I think it’s really important to understand how things work, and even though no model ever fully explains the complex and ever changing reality, models like this are genuinely the best way we have to think about the world around us. Thanks to Mike Gallagher for mentioning the idea.

The secrets of better judgement

Good decision making skills are essential for product managers. I go on (a lot, I’m sure people get bored of it) about product managers bring rationality to their work and be able to explain how they reached conclusions, which relies on good judgement.

Why 95% of employees don’t know their company strategy

I thought:

Learning rate

In a competitive environment, rate of learning matters more than what you learn. That’s true for product managers, product teams and organisations. But ‘learning’ often gets a bad rap because it doesn’t explicitly say, ‘and apply that learning’. And because learning is often applied later or in a different context in ways that prevents problems occurring in the first place, it’s almost impossible to see. But ‘not learning’ is easy to see in repeating the same mistakes or in making mistakes that were obvious to everyone else.

Slightly connected thought; the most important part of a leaders job is to be constantly updating their mental model about how the organisation works. The farther away that model is from the realities of how things actually work, the worse decisions a leader will make. The faster their rate of learning (Tip: one of the best ways to get that insight is to talk to lots of different people at all levels of an org).

What’s slowing you down?

Everyone seems to be talking about bottlenecks at the moment. If AI means that writing code is no longer the bottleneck, then the bottleneck becomes figuring out what’s the right thing to build, at least that’s what the narrative seems to be. I’m not sure. Bottlenecks can move downstream as well as upstream so maybe adoption becomes even more of a bottleneck. If everyone is quickly building products people want, then how they are differentiated, marketed, adopted, commercialised, etc., becomes the bottleneck. We know what happens to demand when markets are over-supplied. Remember product people, the goal isn’t to ship, it’s to create successful product.

“Humans are the constraint. Throttle speed to the constraint.” is John Miller’s advice.

Don’t align, resonate

You know what I think about alignment (and the garbage can model helps to explain why). Maybe “resonate” is a better alternative. It means to produce a deep, clear signal that continues for a while and feels meaningful to someone.

I did:

NudgeStack

Had lots of chats with Copilot to help me think about lining up a new internal product offering (and thinking of names for it which is always the fun part).

• Lots of analysis and scenario planning whilst we wait for a decision from senior stakeholders.
• Talked about different product development processes and frameworks and what factors help choose between them (luckily my masters thesis was about that).I think DABL works ok for new products or wholesale replacements, but it doesn’t work so well for mature products where marginal gains matter a great deal.
• Excellent coaching session talking about product thinking.
• Chatted about our product profession and what we’re doing to set expectations for the with product managers.
• Got told a product manager’s job is like being the guy wearing the padded suit that police dogs attack. Could be worse.

I read:

Reshuffle

Started reading Reshuffle: Who wins when AI restacks the knowledge economy.

Built for biological bandwidth

Jurgen Appelo’s idea of biological bandwidth really caught my attention. It’s a phrase that captures the problem AI creates. Our organisations, processes, methods and techniques have been designed for human minds to understand. And maybe, with AI, that’s no longer enough. As organisations become more algorithmic, more decisions will be made and more actions taken more quickly than any of the humans can keep up with.

From spark to launch

This paper looks at how AI shapes organisational innovation capability across new product development. It finds greater AI usage is associated with higher innovation capability, with the strongest gains in concept development.

I thought:

No answers in the building

Steve Blank popularised the phrase and insight that customer insight is essential for product development. I think it’s easy to assume it means user research and data analysis but everyone else carries on as before. But there’s so much more to it than that. It’s the difference between organisations assuming they know best and accepting uncertainty and ambiguity, and building the organisational muscles for dealing with it. It means having a culture of creativity, of stating things as hypotheses, of running experiments, and learning being held as the ultimate goal.

Agglomeration

Got interested in the idea of agglomeration, which is “the action or process of collecting, gathering, or heaping together a diverse mass of items”, and homophily, which is “the tendency for individuals to associate with others who are similar to themselves in terms of attitudes, values, background, beliefs, and social characteristics.” Basically, I’m interested in what forces drive things together. What explains how, in organisations, resources are pooled into departments, how pockets of knowledge and skills come to be in certain places, certain groups of people become aligned and some ideas and assumptions become dominant. I wonder if there’s any kind of universal theory that explains it.

I did:

Purist to pragmatist

This week involved deliberately sliding back and forth along the purist-pragmatist scale, and being as intentional as I could about what that means and doesn’t mean. And accepting that misalignment is a feature, not a bug. I also did:

• Did lots of planning for a roll-out over the next three months.
• Got approval to build an AI feature.
• Ran a session with technology leaders to consider how they manage different types of work, funded in different ways, for different teams and with different reporting requirements.
• Watched the team deal with an issue really well, and thought about how the potential for issues grows exponentially with every change in complex, interconnected tech.
• Worked on paper to explore some ideas, which I haven’t done in ages.
• Started planning a workshop to look at conversion rate optimisation opportunities.
• Ran a product vision exercise (not quite a workshop yet). It asks what needs to be true for the vision to become a reality to identify the conditions required for a product to succeed.

I read/watched:

Reality drift

I read reality drift from Boring Magic. It reminded me of a conversation I had a couple of weeks ago about trust and expectations of AI systems.

We’ve spent decades working with technology that is about providing a single right answer. Your HR system tells you how many days leave you have left, your banking app shows you how much money you have, your washing machine tells you how long the spin cycle will take. If they tell you the wrong answer, we know something is broken and needs to be fixed. That’s the nature of the deterministic technology we’ve all come to know and trust.

Now, with AI, we’re having to learn to deal with technology that doesn’t provide a single right answer, works in nondeterminisitic ways, and where getting something wrong isn’t a failure. With AI, the answers become take some time off, don’t buy those new shoes, and the sun is shining so hang your washing outside. Those answers aren’t the single right answer and they might be wrong or they might be what you’re looking for.

Problems occur when we expect AI technologies to work like other, more traditional, technologies. There are plenty of times where AI is the right tool to use, but my go-to reminder is ‘only use AI if there isn’t a single right answer’.

The purpose of data is knowledge

And the purpose of knowledge is to allow you to predict the outcomes of your business actions. Common Cog’s series on Becoming Data Driven in Business is fantastic. I started at the end with Becoming Data Driven, From First Principles (you’ll get the joke if you read the intro to the series), which talks about spotting the difference between routine variation and when the data is telling you something significant has changed, either because you did something to change it or because you didn’t. It ends with, “Understanding variation leads to the process control worldview, which leads to an org-wide pursuit of knowledge.”

Rory Sutherland’s 2026 Predictions

Rory talks about businesses being in cost-reduction mode, which might not be a very revolutionary prediction given everything that’s going on in the world. He says modern business is an efficiency competition and that AI will be used by business leaders attempting to win that competition. What I think is interesting about this is that it shows how things without a clear definition, e.g., AI, mean whatever we want them to mean given our worldview.

AI interfaces

Interfaces-on-the-fly is one of those interesting ideas that’s been around a little while. Maybe it’s the path to making personal AI devices ubiquitous MacGuffins in our lives. Imagine a blank smart phone screen that becomes a chat window where you ask your AI assistant to compare running shoes and the interface evolves into a comparison site -looking interface to help you choose and then into a shopping experience to buy them, and later a map interface as you track the delivery.

I thought:

Misunderstanding evidence

When we talk about being evidence-led, what do we mean? I think, we shouldn’t mean undisputed proof that something is true. We should consider evidence as how a phenomenon appears in the real word to allow us to test theories against it. It’s more of an academic definition than a criminal investigation definition and it allows for more useful thinking. If we take evidence to mean incontrovertible proof, and for all kind of reasons, we aren’t able to get that evidence, then we’re stuck. There’s no where else to go. But when we treat evidence as not an end in itself but as part of the process of theory-evidence-analysis, then we can use the observable evidence (accepting its incomplete) to test our theories.

The product operating model for non-product companies

One view of the firm says there are three big value-driving functions: customer relationships, new product development, supply chain management. For the university I work at, new product development is for the information goods (courses) that our customers purchase, not the technology products they use to interact with the course material and tutors. Technology products are in the supply chain management function because they are how the organisation distributes it’s goods. In our case, we use a direct distribution strategy which means the only place you can study our courses is with us, using our technology products. That’s why they are essential to our business model, and make for an interesting product operating model.

Marty Cagan recently posted about the difference between internal and commercial products, which may (or may not, I’ll let you decide) fit for this kind of (mostly mythical) modern product organisation where customer relationships, new product development and supply chain management are all wrapped up in the same commercial product and internal products which support the commercial ones. Our products aren’t like that. We don’t have commercial products in the sense that someone pays to use our products (because what we actually sell are information goods, as I explained above), so by Cagan’s definition all our products are internal products, except they aren’t because they are used by our users. Our products are something different.

So when we talk about a product operating model in the context of a university, we have to be quite strict and critical with our thinking to make sure we stay within the supply chain management function, which sounds like it should be about lorries and logistics but for a distance learning organisation that distributes its products via the internet, is actually about data and technology. Our product operating model isn’t like that of a product-led commercial company, but neither is it like that of a non-technology company with a traditional IT function. Our product operating model is something else.