Category: Weeknotes

I did:

Go time

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

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

I read:

Experiment-Driven Product Development

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

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

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

Via Stéphanie Walters.

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

Interesting talk about being outcome-focused.

Via Debbie Blanchard.

How to deliver digital transformation in public services

Seven lessons:

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

Via Rob Cawston.

The strategic product designer

Nice collection of resources.

I thought:

Compounding improvements

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

Hand-offs

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

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

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

I did:

Heatwave

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

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

I read:

How LLMs affect business

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

The right it

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

Bottleneck theatre

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

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

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

I thought:

Changing sociotechnical systems

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

Spirals, not circles

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

I did:

It’s that time of year

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

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

I read:

The manager’s path

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

Asking better questions about AI in education

Locking in costs and quality

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

I thought:

Theory of constraints in complex systems

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

What kind of product manager are you?

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

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.