Author: Roger

I did:

You can’t make an omelette with breaking some eggs

You always lose something when you create a new thing. That’s part of the work to change and improve things. Did this stuff too:

• Talked about what’s next on our roadmap and when it becomes now.
• Went to a workshop to help join up product, policy and operations, which was really helpful in agreeing our responsibilities.
• Saw a really excellent example of the team critically evaluating work and deciding not to do it.
• Chatted about the conundrum of needing to know what you want to achieve to justify starting work and needing to start the work to figure out what you want to achieve.
• Had a great chat with a product manager about career development.
• Said farewell to one of our associate product managers who’s taking a year off to travel. I’ve really enjoyed getting to know him.

Future of education AI

Went to a jam with Oxford University’s UX team. We spent the day going through a user-centred design process for understanding a problem. It was interesting to see how others approached it.

I read:

Platform product management

Read two books on platform product management. The power of product platforms and Effective platform product management. They’re both good but aren’t quite giving me what I’m looking for, mostly because I’m not sure what that is, other than some way of framing the difference between platform product management and the other sorts of product management.

Your Theory of Change Isn’t a Theory

This caught my attention because I’m a big believer in theory of change. I agree that the theory of change documents we create tend to be too linear and fixed. A theory is any hypothesis or set of ideas intended to explain something, especially one based on general principles independent of the thing to be explained. The point of it is to test it against reality and refine it until it provides consistent and reliable explanation. That’s a big mindset shift from how most organisations operate. They still work on the assumption of a predictable world where a theory of change can be specified upfront and doesn’t need testing.

What can we automate?

“What can we automate?” rather than, “What future are we trying to create, and does this tool help or hinder it?” I wonder about this too when using AI in product management, but maybe the either/or nature of the question is wrong. Maybe the future we’re trying to create is just one of improved efficiency and productivity through automation. That’s certainly the economics perspective. There is a future where the scale of change AI brings is similar to email; it doesn’t fundamentally change what we do, it just makes it faster at scale. And there is another possible future where AI’s scale of change is akin to electricity, and so it does change what we do, how we do it, and why we do it. Of course, the future isn’t evenly distributed so different parts of society will experience change differently, and the timeline matters, are we talking about a year or a century.

I thought:

Self-efficacy: Toward a Unifying Theory of Behavioral Change

Self-efficacy is an individual’s belief in their capacity to act in the ways necessary to reach specific goals. The concept was originally proposed by the psychologist Albert Bandura in 1977.

It’s an important concept for product manager’s because as our job to change user behaviours in ways that achieve business results (you know, outcomes)

Bandura’s model says “expectations of personal efficacy are derived from four principal sources of information: performance accomplishments (such as previously being successful in accomplishing something on the product before, AKA “aha” moments), vicarious experience (learning from other products that behave in consistent ways, e.g., the X to close a pop-up is always in the top right corner), verbal persuasion (spoken or written communication such as onboarding videos and micro-copy explanations), and physiological states (how calm the person is because the product is quick and easy to use). The more dependable the experiential sources, the greater are the changes in perceive self-efficacy.”

Achieving a stronger sense of self-efficacy makes it more likely users will change their behaviours and achieve the outcomes we want.

Backlogs

There’s a lot more to backlogs than most people think.

What’s most important:

• The principles – forcing function to reduce options and increase focus, limit work in progress, make work visible, etc.
• The logic – prioritisation criteria, queuing theory, etc.
• The information – about the item, e.g., assignee and status, which allows the item to be managed, and info about the work the item represents, etc.

What’s less important:

• The tool – Jira, ADO, Trello, Post-it notes, whatever works for the team.
• Who manages it – It should be a shared team task anyway.
• Why the work is on it – Obviously that’s important for other reasons, but the backlog doesn’t represent those decisions.

Productisation

“Productisation relates to the process of analysing a need, defining and combining suitable elements, tangible and/or intangible, into a product-like defined set of deliverables that is standardised, repeatable and comprehendible. “ Yeah, that’s product management.

Flow efficiency

Thought about the flow efficiency of the things I’m involved in, which things have higher and lower flow rates, and why.

If I spent all my 37.5 hour week on one thing, it would have a flow efficiency of 100% because I’m at full capacity on it, and a piece of work that has one 30 minute meeting a week has a flow rate of 1.33%. Knowing this helps us understand the difference between working on something for four hours in one week, which has a flow rate of 10.7%, and working on something for one hour a week for four weeks, which has a flow rate of 2.7%. We spend the same amount of time on the work overall, but focusing and getting it done in one go is more efficient.

Observations:

• Flow rate becomes more interesting the longer the time period it’s measured. My coaching work had a flow rate of 10% last week, which is pretty consistent with other weeks. Learning and development had a flow efficiency of 21% this week, but if I look over a year it drops to 0.5%.
• It’s also more interesting as an indicator of time trade-offs. So if I consistently spend the same amount of time on something each week, it will have a consistent flow rate, but when other work causes me the adjust how much time I spend on something
• Flow rate slows when the wait time in between working on something increases. If instead of one hour a week for fours, I do one hour a fortnight, the flow rate drops to 1.3%.
• It’s ok for some types of work to have low flow rate because it’s the kind of work that progress slowly but regularly, things like risk management meetings that will never be “done”.

I did:

Consequences

You know that game where players take turns contributing sentences to a story without knowing what each other wrote and is then read out, usually with hilarious results? Sometimes product management feels like that.

• Did some consequence mapping to try to explain the implications of the decisions we’ve made in a product.
• Used the Decision Stack for some product vision work, using the question, “What would have to be true about.. accessibility, security, user behaviour, etc, to achieve the vision.
• Presented my talk “Product strategy is easy and everyone should do it” at our product community of practice.
• Went to a day-long session on creating a career framework. It’s an interesting problem and gave me lots to think about.
• Monthly Business Review as part of our new reporting framework.
• Talked about introducing an AI analysis tool for optimising campaigns. If we can send communications at times that work better for people we can make sure they get the right information when they need it.

I read:

Cultivating communities of practice

Interesting book by Wenger, McDermott and Snyder. My takeaway is that communities of practice rely on people who care about a common domain of knowledge and share practices that they are developing to be effective in their domain, but the most important thing is a communities aliveness.

Work is weird

The ‘what AI is doing/will do to work’ debate is really interesting to me because, as Charley Johnson says, work is such a weird thing, which makes it hard to analyse because we end up talking at cross-purposes about the definition instead of the thing itself. At this stage, I still think AI is more likely to have the scale of impact that email had rather than the scale of impact that electricity had on work.

Managers doing leadership: The extra-ordinarization of the mundane

Alvesson and Sveningsson did a study that shows how important listening and dialogue is for leadership. I still maintain there is no better leading indicator for organisational change than the number of conversations leaders have with people below their pay-grade and outside their reporting line.

I thought:

Why there’s no such thing as a product map

Even though there is such a thing as a service map, there is no such thing as a product map.

A map is an abstract representation of an environment that displays signs, symbols, and spatial relationships. To make sense, everything on the map needs to be the same kind of thing. A map of a city has roads and buildings because they are both physical objects in the territory the map represents. That map doesn’t have the colour of the socks worn by people in the buildings or how long the road has existed because these are completely different types of things, which means they wouldn’t make sense on a map of a city.

Mapping works for a service because there is a commonality of signs, symbols and relationships. You can’t get to that commonality for a product, and so you can’t abstract it in the same way. There is no way to represent governance as the same type of thing as budget or user interface. All of the different things that make up a product mean there is no way to map a product.

Changing my mind about frameworks

I used to be anti-frameworks. Now I realise I was actually anti- generic, context-free frameworks. Recently I’ve noticed my thought pattern of quickly building throwaway frameworks to do a very specific job (it’s true what they say, if you want to learn something, try teaching it). It proved useful for an analysis exercise for my MBA. I was the only one in the class who got answer right, not because I know more, but because I could come up with a framework that structured the analysis and made the answer obvious.

I did:

Short-term vs long-term

The impossible dilemma reared its ugly head a few times this week. Choosing (and its always a choice) between short-term and long-term value. Didn’t find any answers so I did this stuff instead:

• Got back into Google analytics and Looker Studio. It’s been a while.
• Wrote my talk on product strategy for our community of practice.
• Presented at a show and tell (well, I say presented but really all I did was talk a bit).
• Chatted about user research and repositories for research insights.
• Ranted about solutionism (again).
• Lots of stakeholder management.
• Thought more about a framework for product responsibilities, and dare I say it, rethinking the idea of the CEO of the product (yeah, I know the source is problematic).
• Got a bit overly-protective of one of the product managers.

Yay! 500 weeknotes

500 weeks ago I was struggling to get stakeholders attention and so starting sending them a weekly email about what the team was doing. It later became my reflections on each week on my blog and I just never stopped. I think having a reflective practice (like writing weeknotes but many other ways are also available) is really helpful for anyone who works in a fast-changing area like digital and product.

I read:

The Future of (Public Sector) Product Management in a Vibe Coded World

Very cool.

Beyond technical debt unravelling organisational debt concept

I got really interested in the idea of organisational debt and this paper does a good job of explaining it. It also suggests agile principles are good for reducing organisational debt.

The Best Interface Is Invisible: Rethinking UX and Design for Agentic Ai

“Agentic Ai systems now challenge the deepest assumptions embedded in interface-centric thinking, and not because interfaces disappear entirely, but because interaction itself changes character. People are no longer necessarily operating a tool step-by-step. Increasingly, we are expressing intent, delegating outcomes, and collaborating with semi-autonomous systems capable of interpretation and action.”

There is no product

Really interesting post about what GenAI does to the economics of products.

Distributed leadership

Distributed leadership theory helps us understand how leadership works in empowered autonomous teams. It still considers leadership as a status, but gives that status to everyone on the team, meaning everyone is involved in leadership activities such as dividing and allocating tasks. One of the limitations of distributed leadership is that people are given leadership status regardless of whether they have the skills to perform the leadership activities well. That’s why a coaching approach from managers outside the team is so important for making empowered autonomous teams effective.

Supply and demand

Saeed Khan says vibe-coding is not product management. Can’t believe it even has to be said, but there you go. What’s far more interesting is how Saeed defines product management as being about supply and demand. A product manager’s job is to understand demand and then provide something that meets the demand. I broadly agree, even if the traditional economics that underpin it are increasingly questionable. The trifecta of business functions of ‘new product development’, ‘supply chain’ and ‘customer relationships’ provide a useful framing for product operating models. The POM that is usually talked about involves product managers operating in all three areas. But that’s not appropriate for every type of organisation. In some, product management doesn’t operate in ‘new product development’, it operates in ‘supply chain’, with the Internet as the means of supplying information goods.

Transforming health and delivering the NHS 10-year plan

Richard Pope’s talk about the NHS 10-year plan, including:

1. Digital ways of working, not just digital technology.
2. Apply platform thinking to clinical functions and understand local needs.
3. Convert the public from consumers to co-producers.
4. Proactively shape the software environment the NHS operates in.

And a big YES! to the NHS thinking and operating like a big tech company.

I thought:

Competing forces

An organisation is a system like any other with competing forces to maintain stability and to change. These competing forces affect each other, reconcile for a short time, get out of balance again. This is constantly happening. The teleological idea of a perfect end state where everything will be alright, all the conflict resolved, everyone aligned, a well-oiled machine that just gets on with it is a myth. It seems like the myth of the end-state causes lots of problems, even though everyone knows we’ll never get there.

Strategies to avoid

There must be loads, but so far on my list of strategies to avoid is Mcdonaldization and Marginal gains. Mcdonaldization is standardisation to the point where there is no differentiation. Marginal gains is about optimising for efficiency which run out. Both are bad strategies.

Responsibility vs responsibilising

Responsibility is taken, it’s intentional, the scope and consequences are known. Responsibilising is giving responsibility with or without someone knowing, with or without the scope and consequences being known. There’s a big difference.

I did:

Compounding interest

Building on what’s gone before, establishing basecamps for the next climb, compounding interest over time… I don’t know what I’m saying about the past but good products do these things for the future. And I did this stuff too:

• Ran a workshop on how to create a product vision (see below for why vision matters). Key points were it’s an ongoing process of asking what would have to be true to make the vision a reality and checking you’re making things more true.
• Discussed a new way of working for a team that should help them collaborate and learn from each other better. It’s a bit more ‘the team in the unit of delivery’.
• Talked about user testing with prototypes and figuring out your research questions first. Prototypes aren’t for proving yourself right, they’re for validating assumptions.
• Collected evidence for our beta-to-live assessment in a few weeks. We’ve got twenty criteria to meet but I’m really keen on us holding ourselves to account.
• Started batting ideas around for a talk I might do at our product community of practice.
• Chatted about a little peer-to-peer mentoring idea I’ve got.
• Started a list of ‘things to think about’ for product managers taking over a product which covers things like budget, resourcing, stakeholders, etc., as product management is always so much more than shipping software.
• Got volunteered to run another retro.

I read:

Time utilization

“For most office jobs, tasks arrives at random time and the size of each task varies.” Apart from being cool just because of the maths, it’s particularly interesting to me because I think our product strategy is based on the concept of time utilisation. My hypothesis is that our competitive advantage comes from helping students manage their time better and reduce the time spent on admin tasks so they have more time to study, which leads to greater academic success.

Fast is a Moat

It’s an interesting question. Does speed create a defensible competitive advantage? Maybe some of what Hardik says isn’t about speed, it’s about momentum, but still… how does speed create an advantage? The old Schumpeterian assumption used to be that speed meant you could get to market ahead of competitors and achieve a first-mover advantage, and be the only one to get the customers. But that idea hasn’t really panned out and there are lots of example of late movers actually getting the advantage because getting to market first isn’t the only thing that leads to success. And maybe that’s the answer. Speed alone doesn’t create a defensible competitive advantage, but along with lots of other things, maybe it helps.

Are you delivering impact as a product team?

How AI Destroys Institutions

Yeah but no. AI doesn’t destroy institutions, humans using AI destroy institutions.

Post-digital

After a chat about trends in digital, multichannel, customer experience, etc., I remembered this from five years ago about , so I read a bit more about post-digital and what it means for universities going through digitisation.

• Meet the new schtick by Russell Davies
• What is Post Digital? by Adam Tinworth
• What is Post Digital? by Florian Cramer
• Postdigital science and education by Petar Jandrić, Jeremy Knox, Tina Besley, Thomas Ryberg, Juha Suoranta &Sarah Hayes

I thought:

Why do product managers make such a big deal about vision and strategy?

Product vision and strategy, along with other conceptual tools like Outcomes and OKRs, help us navigate uncertainty and ambiguity. If things were certain and in our control we wouldn’t need those tools, we’d just make a plan and follow it. But because the world is an unpredictable place, markets are constantly changing, and what affects user behaviour is uncertain, we need tools that reflect this reality.

Metaphors

I’ve mentioned before how metaphors like steering the ship don’t fit our modern pluralistic understanding of organisations so I’ve been wondering what metaphors might fit. Here’s my first try… Organisations are like plants. Small start-ups are flowers, they can point in one direction at a time, towards the sun (the sun is the market) to collect it’s resources, and they change direction as the sun moves. Large organisations take a different approach. They are more like trees with lots of leaves pointing in all different directions. As the sun moves, different leaves collect it’s resources, but the tree doesn’t move. Metaphorically, it suggests leader’s job is to grow the right leaves on their branch so the org can get sunlight from lots of directions at the same time.

What’s needed for an org to move from reactive to proactive?

Nia asked this question in her weeknotes. My answer is, for orgs to be less reactive they would need their world/ecosystem to change less often and more slowly. So maybe orgs need to get better at reacting, rather than trying doing less of it. I get the implication of ‘being reactive’ suggesting not enough forethought, planning, strategy, etc., and I agree those things are important when used in the right way. Long-term investment shouldn’t be in making a plan everyone can stick to for the next ten years, it should be in building the capabilities to adapt quickly.

Workaholism

I’ve been study business ethics as part of my MBA, and one of the topics is workaholism, so I did a survey and scored top marks for being a workaholic. Yeah, no surprise there, but it made me wonder what drives that in me (and yes, I fully recognise it as a long-standing personality trait not an organisational environment thing). One of the anxieties I definitely feel is ‘things going in the wrong direction and building up path dependency before I can change them’. I’m not worried about things going wrong, that seems like a natural thing and easy enough to fix and learn from. But things going in (what I think is) the wrong direction seems like a particularly product-y concern.

I did:

Product people in-person

Spent three days on campus this week, which means my productivity dropped to 70%. Among other things, this stuff happened…

• Talked about the idea of ‘productising products’ and how much more there is to creating products than shipping software.
• Chatted about finding things people care about as the basis for behaviour change.
• Went to a workshop about defining products and services. Yes, I had opinions 😉
• Took part in a retro (rather than running it) and it was really helpful to hear how people are feeling.
• Had another ops team shadowing session. It’s helpful to see what the team do but the really good thing is getting to meet people with such specialist knowledge and dedication for helping our students.
• Went to a quarterly planning day.
• Started working on the assessment for a product that goes live soon.
• Let down one of my product people. I will do better in the future.

I read:

Leadership health metrics

Interesting thoughts on how we might measure the health of leadership in an organisation (which is different to measuring leaders). The centre for creative leadership defines leadership as, “a social process that enables individuals to work together to achieve results that they could never achieve working alone”, which can be seen by the outcomes it achieves of direction, alignment, and commitment, which lead to business results. I’m not entirely convinced by the leadership narrative around singular direction and alignment, I think leadership is far more pluralistic and involves accepting and reconciling moving in different directions at the same time (which is why metaphors like steering the ship are unhelpful because ships can only go in one direction, leadership is more like steering ships and fish and seagulls). If we don’t challenge those kinds of assumptions then we might measure the wrong things and reach the wrong conclusions.

Agentic AI stands ready to transform customer experience and operational efficiency

These two articles from Smashing magazine about agent AI.

• Beyond Generative: The Rise Of Agentic AI And User-Centric Design
• Designing For Agentic AI: Practical UX Patterns For Control, Consent, And Accountability

I like the initiative vs interaction matrix, it mirror the process of human-only, machine-in-the-loop, human-in-the-loop, machine-only.

I thought:

Product evaluation

One of these days I’m going to figure out a proper product evaluation methodology. I really believe you can only properly evaluate a product by getting a comprehensive data set on technical performance, team health, work progress, costs, user interaction and business results. And by having a robust theory of change that explains where you’re trying to get to and how you’ll get there.

I did:

Commonly-held truth

This week had lots of thinking and talking about how to get to an agreed understanding about complex, uncertain, and changeable things. It’s where the really interesting product management work happens. Lots of other stuff too:

• Did a quarterly business review.
• Went to our community of practice and realised I don’t talk to enough product people.
• Chatted about the tension of simplicity and variability in business models. You can’t have both.
• Met a new product manager.
• Shadowed an operational team to understand some processes and how they affect the student experience.
• Did some work on defining business readiness and release planning.
• Discussed moving to outcome-focused goals and how they are better for dealing with uncertainty and ambiguity.
• Did some forward-thinking for where a product I’m working on might go in the future and what kind of investment it might take to get there.
• Talked about how most product management questions come down to dialectics (synthesising opposing perspectives through dialogue, AKA communication and stakeholders management) and logical reasoning (deductive, inductive, and abductive thinking, AKA analysis and evidence-based decision-making).
• Developed a proposal for a common approach to platform product management.

I read:

Team stability

I’ve been trying to figure out how much team stability affects team performance, so I read these:

• Team performance between change and stability
• Antecedents and consequences of team stability on new product development performance
• Team roles and team performance: is there ‘really’ a link?
• On teams, teamwork, and team performance: Discoveries and developments
• A Meta-Analytic Review of Relationships Between Team Design Features and Team Performance

My sense is that there is a sweet spot between too much change and not enough change that is where teams perform at their best. A team that hasn’t spent much time together, doesn’t know each other very well, doesn’t have established roles, has different degrees of experience, etc., etc., isn’t going to be high performing. And a team that has become stuck , isn’t going to be high-performing

The long nose and the long tail

Another insightful and well-grounded piece from Matt Ballantine, this time about how quickly or not technological change is happening.

Bridging silos and overcoming collaboration antipatterns in multidisciplinary organisations

Lots of interesting ideas to dig into from Emily Webber and Ben Linders. I particularly like the ‘collaboration antipattern’ of an X-led organisation and how cross-functional leadership can tackle it.

Being less wrong

I’ll be doing some work on measurement over the next couple of weeks, so I’ve been reminding myself about Bayes theorem and thinking about how to use it to measure uncertain outcomes.

I thought:

Outcomes and objectives

What’s the difference

Both describe a desired future state we want to get to, but provide very different focus for how to get there. Outcomes focus on what’s going on outside the organisation (the clue is in the name), objectives are inside the organisation.

How to use them together

Using outcomes on their own or objectives on their own is fine, but they work better together because they provide different perspectives on how to get to the desired end state and know when you’re there.

When we use OKR formats like ‘who does what by how much’, we are intentionally mixing outcomes and objectives. ‘Who does what’ describes the change in user behaviour, that’s the outcome. ‘By how much’ is the objective.

Eat carrots

If you want to create organisational change, tell me how you’d get everyone to eat carrots. How would you buy enough carrots, where from, when would they be delivered, how would you tell people, would you have a stick for those that don’t eat their carrots, who would use. If you can’t get people to eat carrots, you can’t create change.

How to choose metrics

It’s easy, just pick whichever metric intuitively seems important, but before you do that…

• Critically evaluate your organisational beliefs to identify the ontology and epistemology that best fits.
• Define what decisions you want to be able to make from the analysis.
• Carefully select what phenomena you want to observe.
• Understand your theory of change; where the thing you’re measuring is right now, where you want to get it to, and how you believe you can get there.
• Document the evaluation methodology you intend to use, including its limitations.
• Check you have the data available, check it’s quality and that it really is about what you think it’s about.
• Be sure the collection method has consistency and longevity so you know more of that data will be available in the future.
• Make sure you have the pipeline set up to refresh the data on your chosen frequency.
• Establish what kind of analysis and interpretations you want done on the data.
• Decide what data visualization tool you’re going to use.
• Check someone has the skills to query the data, perform the analysis, and update the dashboard. And check they have enough time to do it as often as you’re asking.
• Figure out who needs to know about the dashboard and how your going to tell them about it.
• Check they have the knowledge and skills to interpret the dashboard correctly so they don’t make too many wrong assumptions.
• And many, many more things.