Month: June 2025

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.