Category: Weeknotes

I did:

So many opportunities, so little time

Lots going on this week about where to focus next and how to validate options. And this stuff too…

• Presented my opportunity mapping to the leadership team to get initial feedback on where our communications product could go in the future. It takes our team’s responsibility from being for a product to being for a domain. It brings a lot more complexity, but that’s the point, we abstract the complexity way from those who shouldn’t have to deal with it.
• Chatted about how our north star metric can be used, including by teams to prioritise their strategic work and to measure against business cases. I’m so impressed with how accepting people have been about using outcome metrics.
• Discussed how to analyse opportunities for prioritisation when there’s no common criteria.
• Did some shortlisting for interviews. It always takes me ages to do this kind of thing because I feel like I’m making decisions that affect other people’s lives.
• Watched in admiration how our delivery manager is knocking it out of the park at the moment. Despite plenty of challenges she’s got the team focused and engaged.
• Joined some sessions on how AI is being used across the university.

The numbers

• Minutes spent in meetings: 870 (Thursday was a particularly interesting game of meeting Tetris).
• Tasks completed: 46.

Optimising meetings

Wrote up a method I’ve used to analyse and improve how a team uses its time.

More feeds

Added more newsletters and blogs to my feed.

I read/watched:

Loops over lists

This is a great piece of my a to do list isn’t a strategy. “Not a plan to follow, but a cycle to run; faster, cleaner, and more honestly than your competition.”

Generative interfaces

It seems so obvious once you’ve heard it, but using GenAI to generate interfaces on-the-fly based on how a user is interacting with GenAI is pretty cool.

Conversational design

Started reading Erika Hall’s Conversational design as I might be doing some work on a chatbot.

Why Everyone Is Wrong About AI

Communication is the Problem. Communication is the Solution

Say It, Repeat It, Frame It. “Most leaders, it turns out, need to be better communicators. No one is universally bad, of course, and (mostly) not badly intentioned. But making life harder for themselves and their teams, and underachieving as leaders because they haven’t built some core leadership communication habits.”

I thought:

Opportunities to outcomes

This little diagram has been hanging around in my head for a while. It tries to highlight the product parts of the process rather than the software development parts. It shows the two main focuses for product managers; opportunities and outcomes, how these are fundamentally outside the walls of the organisation and that they are connected in a loop by software delivery and measuring user behaviour.

Most product frameworks are really delivery frameworks. This is a problem because it reinforces product managers working as project managers. It sets the expectation that product work is mostly about building a solution. There’s no product framework or methodology or process for what product management is really about; finding worthwhile problems.

Fundamental questions

Product managers should always be asking, “Are we tackling the right problems?”

Delivery managers should always be asking, “Are we getting better at solving problems?”

Tech people should always be asking, “Are we building the solution right?”

Strategy brief

I like to figure out the wraparound of things before the things themselves. I think, if you can’t say who this thing is for, how they’re going to use it, what effect or results they’re expecting, etc., then you’re wasting your time. Writing a product strategy is no different. So writing a kind of brief for a product strategy is a great way to clarify your understanding of what is expected before you write the strategy. A strategy brief should answer:

• Who’s the audience?
• What are their expectations?
  • Format
  • Scope
• How will you tell them about it?
• What will they do with it?
• How will you know if they don’t use it?
• What changes or results do you expect?
• What are the implications of not getting changes or results?

Value proposition for ODEL

I read the IDCE’s report on student success in open, distance and e-learning, and was interested in the idea of success or failure being in the overlap of “the strengths and weaknesses of the students who study in these programmes, and strengths and weaknesses of ODEL modes of study themselves”. That means when the students weaknesses coincide with the weaknesses of the products, then there’s a higher likelihood of failure. So products should focus on strengths that counter students weaknesses, so the two weaknesses don’t overlap and more students succeed. But how to make that part of a value proposition?

Markov decisions

Did a bit more thinking on how teams could use Markov decision policies to optimise delivery times. Each step in the delivery process is uncertain. We can’t say for sure that it’ll get us where we want to be because there’s a chance the person we need for approval is on leave or we don’t have the right information or other work comes up. If we can figure out the probability of the possible next steps, then we could use that to predict the time things will take. So much more to figure out here.

I did:

Jumped between delivery work in the now (yeah, ok, it was kinda fun) and big vague possible future stuff quite a lot this week. Also…

• Stopped more work coming our way that we really weren’t the best team to handle. Chalk up another success for being clear about purpose.
• Talked about delivery metrics, the calculations behind them, and how we use them to make improvements.
• Did some opportunity mapping which gives us about a hundred years of work.
• Reflected on how I completely missed that a piece of work had gone astray.
• Registered for an MBA. I’m really looking forward to being a student again.

I read:

Secret product skills

I agree about these skills being essential for a product manager but I like to add a layer of ‘how’ to the mix. I think product managers are at their strongest in using skills like negotiation when they approach it dialectically, bringing together opposing ideas through reasoned argument. It’s the philosophy that underpins being data-driven, evidence-backed, etc.

It changes things from being about defending a position to being about finding the best option. Of course product managers need to have a position on things, but they should be open to changing it based on new information and not be swayed by opinion. And they should be encouraging others to think dialectically too.

Design and AI

Also Design methods in the age of AI and Prompting Is A Design Act: How To Brief, Guide And Iterate With AI

I’ve definitely seen a shift in how AI is being talked about. Seems like people are sharing more real lessons rather than being on the extremes of for or against AI.

Who’s copying who?

While reading about LoRA (Low-rank adaption), I noticed that IBM and Cloudflare have extremely similar explanations. I wonder how that happened. Did they both use GenAI to write content for their website and not check that no one else had done the same? How does that kind of duplication affect search rankings (especially given Google uses GenAI to generate summaries of web pages)? Who owns the copyright? Does any of this matter?

Anyway, this is the original paper that introduced the concept of low-rank adaption of large language models.

This is how to make change happen

Katie Andrews is my hero. A manager who prioritises spending time with people, mentoring and coaching them. Plus extra cool points for dining alone.

I thought:

What product managers care about

Because a product is fundamentally a way to exchange value between an organisation and a user, product managers are concerned with maximising and balancing the value exchanged.

Maximising means making sure users get as much of the value they are looking for as possible, and the organisation gets as much of the value its looking for (these are almost always different things).

Balancing means making sure the value exchange is worth it for users and the organisation so that neither is giving more value than they receive.

To achieve this, product managers need to care about three things:

• Opportunities – potential to exchange unrealised value.
• Outcomes – changing user behaviour in ways that get business results so the value exchange happens.
• ROI – cost and benefits realisation. The economics of the product, how much does it cost to run the product, do those costs scale linearly with the number of users and increased usage, etc., so that it’s worth having the value exchange.

Build-run-own-adopt

Should platform teams and internal product teams be responsible for the adoption of their platform/product?

As always, it depends on what problem you’re trying to solve. If there’s loads of demand for it, if other teams are banging on the platform team’s door asking for it, then there’s no reason for them to responsibility for adoption. If other teams don’t know about their platform/product, don’t see the value, don’t understand the wider benefits to the organisation from teams adopting a common platform, then the platform/product team really does need to have full build-run-own-adopt responsibility.

Alex’s ownership trio is a really interesting idea. It says a team needs knowledge, mandate and responsibility in order to own their platform/product. I guess they’d need the same for an adoption trio.

A value proposition for a product operating model for distance learning

“The student experience of the products is so good that they are a marketable differentiator, helping them choose one university over another.” Or something snappier, but you get the point.

Following on from thinking about what products are in universities, I’d love to see products positioned inside universities as needing to be so good that they affect student’s choices. Wouldn’t that be an ultimate outcome for product teams!

AI-assisted essay writing

The academic debate about whether students should use GenAI in writing essays continues.

The counter-logic test to banning GenAI is that banning any new tech would have included ballpoint pens and laptops, and so students would still be writing essays using quill and parchment. Does that seem reasonable? If not, then there’s no logic to banning the new tech of GenAI.

As a product person the answer is obvious. Build a tool that helps students write essays using GenAI. The tool would take them through good practice for essay structure, suggest text for each part, encourage them to question the assumptions in the text, test their knowledge, etc. It could be the only way to submit an assignment (with the usual alternatives universities love) which would ensure adoption and reduce the use of other GenAI, and it would be auditable by the university so there would be clarity about how much input there was from students. The grading would be a combination of the quality of thinking expressed in the essay and the advanced use of the tool.

This week I did:

Line of sight

If there’s a theme for this week then its probably something to do with being able to connect things I’m doing now with what I’m trying to achieve in the future, which included:

• By focusing on validating problems rather than jumping to solutions we brought 27 pieces of work down to only two where there is a worthwhile problem to solve.
• Delivered another product strategy workshop and wrote up what I learned. I really enjoy workshops and always learn a lot, especially when I’m lucky enough to work with such great teams.
• Talked a lot about work management tools, processes and rituals, and how they all fit together to support a team to be high-performing. Made me think about what I’d want from a product management tool.
• Chatted some more about our north star metric and how product managers might use it.
• Thought about how we might do some opportunity space mapping to get an idea of where some of our products might go in the future.
• Did an impromptu survey with the team to try to understand how much of work management we hold in our heads and how much we rely on work management tools. The answer was that we keep a lot in our heads, which wasn’t unexpected. The majority of knowledge is tacit and uncodifiable. Mustn’t forget that.

Topology of university products

I’ve been thinking for a while about Saul Couzens, statement at UKEduCamp, “Products are the things the university provides, not the things provided to the university by IT teams”. So I tried to map a few of those products that universities provide.

The numbers

Tasks completed: 36.

Minutes spent in meetings: 850.

I read/listened to:

Impact-first

Matt Lemay on Lenny’s podcast.

I particularly like the point Matt makes about teams that getting everything done and still not having impact. It’s so easy for product teams to focus on perfect technique for things like OKRs and completely miss the point.

Strategy for Organizations Without Competition

Playing to Win When There is No One to Beat.

Roger Martin talks about strategy that creates the most value for the beneficiaries. “If you aren’t creating the maximum possible value with the tools at your disposal, you aren’t winning”, he says.

And I thought about:

Fastest route for delivery

Played around with Markov chains for optimising delivery plans. There’s definitely something good there but I haven’t found a way to heuristic-ise it yet to make it easier to use. The idea is that by understanding the probabilities of different routes being fast or slow, delivery managers would be able to plan probabilistically rather than falsely deterministically.

Explore/exploit

How do you choose between a solution you already know and spending time exploring new possible solutions? How much time is it worth spending for that possibility? When do you decide to stop exploring and go back to exploiting a solution you know will work?

This week I did:

One ring

I’ve never seen lord of the rings but I get the meme of ‘one ring to rule them all’ and how it represents the desire to make complicated things seem simple by ‘having everything in one place’. It’s a false sense of simplicity, but I get it. The opposite is ‘right tool for the job’ and abstracting a layer so that the browser is that one place, which I tend to argue for. Other stuff:

• Did another workshop, this time on product strategy, north star metric and OKRs. I really like how those three things fit together.
• Discussed new ways of working, how they align with measuring progress and how we’ll use our tools. It’s interesting to think about how to design a system of work where team rituals and practices, processes and tools work together.
• Started a new piece of work using some of those new practices, processes and tools, and paying attention to how long it takes us to do things. Early indication is that we’re faster because we’re being clearer about things like what problems we’re trying to solve, so our shared understanding coalesces sooner.
• Got excited about the idea of creating a perfect abstract mirror of our product in our work management tool, and then had my hopes and dreams dashed on the rocks of pragmatism.
• Talked more about our emerging north star metric to stress-test it and see what appetite there is for it. Want to know how I found our north star? I listened to lots of people talk about what’s important to them and looked for themes. Ya know, user research.

I read/watched/listened to:

Law of complexity

Following on from last week’s thought on complexity, I watched this video which includes a description of how and why complex things are complex. The law of functional information attempts to explain the naturally occurring process of how systems evolve to become more complex. It counters the idea of entropy, which explains why systems breakdown, but there’s no force acting on systems to simplify them. It just doesn’t happen. Systems get more complex, or they break down, but they never get simpler.

Teresa Torres’ Step-by-Step Guide to AI Product Discovery

Brilliant podcast from the brilliant Teresa Torres about discovery and AI, including the how to interview users to understand their problems and how to structure discovery for AI features.

Agentic AI

I wasted a few minutes of my life reading PwC’s executive playbook on agentic AI. Of course it’s all sales pitch about the possible future not the reality today, but when it gets to the “real world success stories”, they are mostly about machine learning, not GenAI and certainly not agentic AI.

Conflating established, proven technologies with emerging, unproven ones makes for a pretty poor sales pitch in my book. It even has a section laughingly called, ‘avoiding the GenAI hype’.

It also reminded me of something said on the Practical AI, that when most people ask for AI what they really want is workflow automation. It’s one big product management lesson on the difference between what users say they want and what users need.

Ambiguity in behavioural design

This paper explores how ambiguity in motivation, capabilities, and opportunities leads to unexpected outcomes. It talks about what every product person knows; outcomes are unpredictable. We can never be sure we’re going to change user behaviour in ways that get business results until after it’s happened, and we never know how long it’ll be until the behaviour changes away from our business result. It’s the ambiguity which makes it fun.

And I thought:

University products

I’ve been thinking about something Saul Couzens said at UKEduCamp; “Products are the things the university provides, not the things provided to the university by IT teams”. That resonated with me because I’m really against the idea that a piece of tech is ‘the product’. The products are things like admissions, support, funding, complaints & appeals, and libraries. So I started mapping out some of the products universities provide and might turn it into a blog post.

Marginal gains

Small improvements, compounded over time, lead to big results. That’s the promise of marginal gains.

A focus on this kind of optimisation has a big drawback. Over time, the results get less and less from the same amount of effort. Then we have a choice, increase our efforts to get the same return, or accept that the gains run out.

Marginal gains works, until it doesn’t.

So, a product strategy based on achieving marginal gains might look good in the short-term but it’s going to fail over the long-term as it isn’t going to create a lasting competitive advantage.

RANCID

Make your stakeholder engagement RANCID.

• Responsible
• Accountable
• Not involved
• Consulted
• Informed
• Decider

This week I did:

Moments of truth

The first moment of truth is when a user ‘gets’ a product. Getting to users to the point where things make sense is why user research and good design (not to mention product management) is so important. I think the same applies to anything new, be it a new strategy, a new document template, a new approach to reporting. The important thing is figuring out how to get people to that moment of truth. That’s what I’ve been trying, sometimes successfully sometimes not, to do this week. I did other stuff too.

• Saw a really good example of four teams working collaboratively around a problem.
• Ran some strategy prep sessions with product teams to help them get ready for our strategy workshop next week.
• Wrote more for the workshop, mostly about OKRs. I get quite cantankerous when people misuse them.
• Chatted about how product managers can improve user interview skills.
• Set up a demo dashboard for tracking a north star metric across all our products and services. Was surprised how well accepted my first presentation was (see above about creating moments of truth). Better nail my pitch for next week.
• Did a bit of product owner work investigating how systems work.
• Had my request to join a forum declined. Harsh.

I read:

Persuasive technology

This brilliant book by B.J. Fogg hits me in my happy place. It talks about captology (that’s Computers As Persuasive Technology -ology), the overlap of technology and behaviour change, which is a big part of my stance on the role of product management. It’s going on my recommendations list for product managers.

The product complexity conundrum

I have a funny relationship with complexity. I don’t think it’s a bad thing (complexity that is, not my relationship with it), and in most cases I like it. I often find myself pushing against calls to make things simple. I don’t think you can make complex things simple, all you can do is choose how to handle the complexity.

And I thought:

The culture and capabilities of being product-led

Culture and capabilities go hand-in-hand for things like being product-led. Having the capabilities, e.g., product instrumentation and data analysis, is useless without a culture of using the data to look for user problems, prioritise, and solve them.

Or, another way to look at it is, all organisational change needs people, process and technology change. You can’t change one without changing the others.

What product managers need

According to McKinsey, of the various aspects of a product and platform operating model, product management practices has the greatest impact on business performance. So, what do product managers need from an effective product operating model so they can have the right practices? Well, to start with:

• Research (user, market, competitor, industry, etc.).
• Product instrumentation and data analysis.
• Experimentation and hypothesis validation.
• Organisational demand for worthwhile problems.

Looooong before anyone has to worry about building anything.

The strength of weak ties

A while ago I wrote about organisational structure based on sociologist Mark Granovetter’s concept of the strength of weak ties. I thought more about that this week as I got to know more people, got connected to others through them, and connected them to people I know.

In an organisation that structures itself purely by hierarchy, any individual is only connected to a few colleagues in their team and their manager. I’ve worked in places like that and it’s hard to know who to speak to and even harder to get people from different teams to talk to each other.

But, right now, I’m part a team, a profession (and it’s community of practice), and a group. That means, from an organisational structure point-of-view, I’m only one step away from almost a hundred people.

Remember when Dunbar’s number was all the rage? It said humans naturally form groups up to 150 people because that’s about how many names and faces we can remember. It was often used as a limit, but what if we used it as a target? If we create organisational structures that proactively connect people via weak ties then we enable better information flow because we know who to talk to, better shared understanding because lots of people talk to each other, and ultimately a more effective organisation.

2055

Remember how the Internet was in the nineties? Slow, expensive, ugly, of questionable use. What if that’s what the AI of now is like? What might it be like thirty years from now?

I did:

Happy new year

The 1st of August marks the start of the new academic year. Nothing changes but everything changes. All those things we said were for next quarter are now the things to be getting on with.

Also did this stuff:

• Wrote and talked about how to create a product strategy.
• Talked through stakeholder feedback with one of the product managers. It’s good to see that everyone shares the same opinion about how fantastic they are.
• Discussed ways of coordinating cross-team work. It’s one of those bottleneck patterns of having to start from scratch every time because each situation is different.
• Led an in-person workshop with technology leaders to turn a complicated technology strategy into action briefs. It was a lot of fun, but it meant wearing socks.

The numbers

• Minutes in meetings: 915
• Tasks completed: 27

Product strategy workshop

Got around to actually writing up my approach to a workshop for creating and deploying a product strategy.

How I think about epics, features and user stories

Basically, they are different things that exist in a network not a hierarchy.

I read:

The Great Distractor

Interesting essay about the attention economy. Especially important for product managers to understand the history of products like Instagram and how they maintain engagement. I bought B.J. Fogg’s book to learn more.

Increasing luck

In this piece, Cate Hall writes about how to increase our surface area of luck. It resonates with me because I’m interested in luck and skill at the moment, and because I’ve noticed what she describes fits the change in my life over the past few years. More caring responsibilities equals less time and energy for doing the kinds of things that make me lucky. Years ago I was involved in more online communities, doing product advising, side-projects (perhaps the decline of social media played a part there too). Luckily for me, Doug’s Thought Shrapnel is in my feed so I find things like Cate’s newsletter.

AI Ethics Literacy

Some really useful links from the Markkula Center for Applied Ethics about AI ethics, which product managers should be learning about even if they aren’t building products with AI.

I thought:

Product teams change behaviour

Product teams change user’s behaviour. That’s my overarching definition of the difference between a product team or a project team. If you aren’t trying to change the behaviour of your users in a way that benefits the organisation (you know, outcomes) then you aren’t a product team. There’s nothing wrong with being a project team, I just like having a definition of a product team that is nothing to do with implementing technology.

It is inevitable

Matrix management has reared its ugly head again recently, which always baffles me given that it’s been well demonstrated since the late eighties that it’s a bad idea. But it took me down me a Tom Peters rabbit hole and the eight themes for successful organisations he developed with Robert Waterman.

1. A bias for action, active decision making – ‘getting on with it’.
2. Close to the customer – learning from the people served by the business.
3. Autonomy and entrepreneurship – fostering innovation and nurturing ‘champions’.
4. Productivity through people – treating rank and file employees as a source of quality.
5. Hands-on, value-driven – management philosophy that guides everyday practice – management showing its commitment.
6. Stick to the knitting – stay with the business that you know.
7. Simple form, lean staff – some of the best companies have minimal HQ staff.
8. Simultaneous loose-tight properties – autonomy in shop-floor activities plus centralised values.

Asking unanswerable questions

I pondered the asking of unanswerable questions this week. Why we do it, are we really asking that question or trying to express some deeper unknowns? And how to turn them into answerable questions that move things forward. Asking good questions is a real skill.

I did:

Mo’ problems

This week seemed to be mostly about asking, “What kind of problem is this?” Is it a product problem (getting consensus with stakeholders), a procurement problem (comparing supplier options), a process problem (are things happening in the right order). And this stuff happened:

• Wrote a product strategy workshop for product teams, and an accompanying presentation for leaders. The main point being how having a product strategy helps teams achieve high alignment and high autonomy.
• Did more scenario mapping to look at the effect decisions will have in the future.
• Saw a quick demo of a user story writing chatbot.
• Used copilot to write some prompts for copilot for an upcoming workshop.
• Had an interesting chat with a product manager who is bringing together a bunch of organisational functions to productise them.
• Talked about progress reporting and how the best reporting enables teams to improve, and how that requires a whole load of enabling work to make successful.
• Started designing a metrics tree.
• Had a few different conversations with different leaders generally around the theme of data being a vital asset that creates a competitive advantage. I remember trying to have conversations like that with charity leaders who just didn’t get it. It’s so good to work with people who do.

The numbers

Another three-day week, but:

• 40 tasks completed.
• 520 minutes in meetings.

I read:

Balanced metrics

I like balance. I like the idea of making sure one metric isn’t over-optimised by measuring things that might be seen as competing, e.g., speed and quality. Troy’s metrics are:

• Do the right stuff (valuable)
• Do it right (quality)
• Do it fast (speed)
• Do it predictably (consistency)
• Do it lots (quantity)
• Keep doing it (resilience)

AI and assessment reform options: A look at the scoreboard

Jason is right, educational assessment definitely requires a rethink. “Knowing stuff” changes significantly if you have a book in front of you, it changes significantly again when you have lots of books via the Internet, and again when you have AI to summarise all those books. Assessing for retained information is becoming increasingly out of date. Maybe don’t assess knowing stuff, assess applying knowledge wherever it came from.

I thought:

The promise of product

Organisations invest in products, product managers and product thinking because of the promise they make. That promise is greater growth and value, at lower cost, at scale. Agile showed us better ways of building software. DevOps showed us better ways of releasing and maintaining software. It’s product’s job to make that software valuable (but of course product is more than just software).

Definition changed

We’re in the post-digital era where technology and the Internet are a ubiquitous part of life. The expectations aren’t raised anymore, they are mundane. Unfortunately, most organisations haven’t caught up yet.

More capitalism

I saw someone’s post on LinkedIn about their model for organisational culture change that leads to higher performance and more business value. It got me thinking, is culture change all about working harder and being good little capitalists? Surely there’s more to it? Can’t we change culture to be more humane, more fair and equal, healthier, just because it’s morally the right thing to do?

OKRs aren’t about goals

OKRs do one thing really well, they tell you if your strategy is working.

They are feedback loops to tell you if what you decided to do is actually achieving what you wanted, they don’t help you decide what to do (that’s what strategy is for).

Objectives express the goal you decided, and Key Results provide the signals that tell you whether your goal has been achieved, but nothing about OKRs helps you decide what your goals should be. You have to do that work before writing OKRs.

Choice or luck

The more I think in bets, the more I see ‘choice and luck’ everywhere. Recruiting? You need to figure out how much of a candidates achievement were luck and how much were because of choices they made. Product strategy? You need to figure out which factors are within your control so you can make choices about them and which are outside of your control and are just luck.

Change

I never used to believe that leaders had that much power to shape change in an organisation, I always thought change happens bottom-up, but I’m starting to change my mind. Recently I’ve thought that the number of conversations leaders have with people below their pay grade and outside their reporting line is a leading indicator of culture change, but not that leaders could actually change the culture.

More recently, I’ve started to believe more and more that how much an org changes depends on how much leaders change. If leaders maintain the status quo power dynamic of ‘leaders do the thinking and make the decisions, teams do the work’, then it doesn’t matter how much restructuring of teams happens, nothing much is actually going to change.

I did:

A one-day week so super focused:

• Updated a workshop plan and wrote comms for it.
• Talked about how we match the right teams to different kinds of work.
• Chatted to another product manager about how much thinking about the future we should do.
• Wrote a quick one-pager on updating our architecture vision and target state to give the team clearer direction on how our tech stack should evolve in the coming years.
• Went to a session on using AI in the student user journey.
• Chatted about what a good product strategy looks like (forces focus, balances alignment and autonomy, easy to remember, adapts to change… that kind of thing).

Lessons learned

Started trying to write down some of the things I’ve learned about product management over the years. It should be an easier side project over the next few months while I don’t have much time.

I read:

Designing for behaviour change

Lots of hints for how to design products that are actually trying to change user’s behaviours (and you can’t say you are outcome-focused if you aren’t trying to change user’s behaviours). I like “Commit to begin – Secure an early ‘yes’ that carries them through the hard middle” and “Set the standard – Show the benchmark up-front and keep reminding people where they are”. I can see these these could be built into user interactions to change behaviour, not just complete actions.

Product operating model

Nice article trying to explain some of the differences between a project and product operating model.

Would have been better if it was more critical and evaluated the downsides of the product operating model. I did a quick search for any research comparing the project and product operating models but couldn’t find anything. I think it’s important to talk about product operating models as hypotheses in an uncertain and ambiguous space, rather than as ‘the answer’ to the downsides of the project operating model.

The product-led organization

Started reading Todd Olsen’s the product-led organization.

I thought about:

Thinking in bets

I was looking back over my notes from Annie Duke’s Thinking in bets and the quote, “I had to learn to focus on the things I could control, let go of the things I couldn’t, and work to be able to accurately tell the difference between the two.” This is an essential product skill in the Measurement space, which makes it really interesting to me because I’m particularly interested in the opposite ends of the product development process; opportunities and measurement.

Simplest possible outcomes

I like the idea of getting changes in user behaviour down to a single verb. It makes them easier to remember and talk about. So in our comms product that’s Open, Read, Click. Three user behaviours, that are within our ability to affect, and which lead to business results.

AI interaction modes

I think there are only four ways for AI to be involved in how users and organisations interact with each other.

1. User to Org AI. E.g., person uses a chatbot to interact with an organisation.
2. User to Org system with hidden AI. E.g., person receives emails from an organisation and doesn’t know AI wrote it or selected them.
3. User AI to Org system. E.g., person uses AI to provide information or complete a task by interacting with an organisation’s website.
4. User AI to Org AI. E.g., person uses their AI agent to interact with organisation’s AI agents to complete tasks.

AI replacement cycle

I think replacing humans with AI in organisations cycles through three steps:

1. Unbundling to the smallest explainable unit, e.g., a task like writing a business case.
2. Move the task from being completed entirely by a human, to machine-in-the-loop (like asking ChatGPT for suggestions), to human-in-the-loop (checking automated outputs), and finally all machine (human no longer needed for the task to be completed).
3. Rebundle multiple tasks into a role (replacing the human entirely), rebundle roles to replace teams/functions. Rebundling requires thinking about how tasks, roles and functions should be grouped as wouldn’t make sense to do it the same way as it was done with humans.

Capability and capacity

Capability is being able to do a certain thing that an organisation needs to operate. It is made up of people, processes and tools.

Capacity is the rate work flows through the capability. It isn’t the number of people on a team, even though that’s often how it’s used.

Neither of these is fixed. And planning against them as if they are fixed leads to unrealistic plans. The more complex or novel a problem is, the less flow, because the team has lots of figuring out which involves false starts and changes in direction. The more familiar and predictable a problem is, the more flow because the team knows what they are doing.

Cross-functional teams create the illusion of fixed capability and fixed capacity with consistent output. But it’s not true. Output is always constrained by the biggest bottleneck, and more often than not, that’s outside the team. Large teams face the same bottlenecks as small teams, so adding more people to a team doesn’t increase capacity if the bottleneck is outside.

Which led to thinking about…

Bottleneck patterns

Bottleneck patterns might be:

• Unclear responsibilities. Teams aren’t sure who should be doing certain things.
• Insufficient knowledge and skills in the team. Cross-functional teams don’t always have everything they need to deliver value.
• Poor collaboration across teams. Teams don’t always know who to talk to or how to get them to take notice.
• Misaligned priorities. What is super important for one team is not important for another team.
• Poor communication from and with stakeholders. Teams don’t always understand what stakeholders want or how to give it to them.

There must be a lot more but the meta-pattern here is having to figure things out from scratch every time a team starts a new piece of work. That’s a huge bottleneck to flow.

I did:

Turned out nice again

Only worked three days this week but I achieved everything I planned, and it’s always nice when that happens.

• Planned a workshop for a leadership team to help them operationalise a complicated strategy. There are lots of different perspectives on the strategy, just like the blind men touching an elephant.
• Wrote a discussion paper to try to help with setting the long-term (5 to 10 years) direction of a product.
• Talked about how to manage dependencies between teams, and that the answer is always better conversations.
• Found some opportunities to encourage a few people to use copilot to get some stuff done more quickly.
• Tried out a product tool to see if I could set it up for actual product work rather than project delivery.
• Chatted about personal objectives a bit. You know what I think about them but I’m keeping an open mind to see if there’s a way they can be useful.
• Started working my way through the process to assign new work to another team. We definitely need to get better figuring what work isn’t for us.
• One of our team won an award. So proud.

Calm social feed

Added lots more to my feeds. I’d much rather spend time reading what’s going on with people I’m actually interested in than scrolling through nonsense on social media.

Gave blood

The whole experience of giving blood gets better each time. I used the app to book an appointment for the next day, received helpful text messages, and had a smooth donation. A year ago that wouldn’t have happened, so well done to the team working on this.

I read:

Solving for Value – A Journey of Ambition and Stupidity

Started reading this book because I wanted to give scrum another chance and validate my thoughts on cadence vs continuous approaches. But it’s really badly written so I don’t know if I’ll finish it.

It is Time to Reclaim What Product Managers Are Here For

“Your team doesn’t need a product manager writing stories in Jira. They need someone making sense of uncertainty and pushing decisions forward.”

The problem with problems

“How do we build organisational muscle for problem discovery that’s as sophisticated as our solution discovery? How do we create space for people to step back and ask not just “how might we solve this better?” but “what if this isn’t the right problem at all?””

The evolution of delivery

“The best delivery teams I’ve seen recently aren’t obsessing over governance, RAG statuses or waterfall vs agile anymore. They’re asking a much simpler question: “Where’s the friction, and how do we unblock it?” That’s it. That’s the work”

Finding out if you’re right

John is right, OKRs don’t solve all problems but they tackle one problem really well; connecting inside an organisation (strategy, hypotheses, experiments, etc.) with outside (user behaviour) to see if you’re right.

Problem-solving speed

“…the winners are distinguished by one thing: their ability to identify and solve problems at high velocity.” This changes the long-standing talk of competitive advantage being achieved by being first to market, from shipping fast to solving problems fast. It also fits the shift in product management from project output to uncovering worthwhile problems. Things are moving in the right direction.

I thought about:

How AI changes product management

Most of what I read about AI product management seems to basically say do product management right, regardless of the AI. So I’ve been thinking about whether having AI in products actually changes product management or not. AI changes things like the company ethos and ethics, regulations, pricing models, time to market, return-on-investment time horizons, but those are all things product managers should be considering anyway. So, does AI change product management? If it does, the effects are much smaller than other factors like the economy.

How far ahead

One of the elements that I think makes product management different to lots of other disciplines is how far ahead we think. The future is uncertain and ambiguous (just like the market) so product skills are perfect for dealing with it.

Maybe the time span a product manager considers is a useful signal for the quality of product management too. If product managers are only thinking about this quarter, they are probably too involved in delivery. If they spend more time thinking about how things might be in five years then they’re more likely to be doing good product work. I’m interested in how we might develop this skill in product managers.

Up and down

Thought some unfinished thoughts about how work flows through an organisation. The traditional and dominant way is mapped to the hierarchical org chart. Those at the top think of the big things they want the organisation to do, tell those the next level down, who interpret it and tell the next level down, and so on until the work is broken down into small enough chunks. We created cross-functional teams because we recognise the information loss from handing-off work between teams. Maybe we need a similar solution to handle information exchange up and down organisations.

I did:

Took the week off but some good stuff still happened:

• Some work that seemed not to deliver much value was stopped. Yay for considering value and not doing work just because it’s on the plan.
• Chatted about quarterly planning and what problems it’s really trying to solve (predict delivery, reduce dependencies, drive outcomes, optics of management, etc.).
• Wrote up some notes on the implications of our shift to a more continuous way of working (because cadence-based ways of working are flow killers).
• Considered what kind of tracking data we’d need to support a north star metric.

I read:

When Cross-Functional Teams Still Need Too Much Coordination

A cross-functional team might “own the UI for checkout and maybe some business logic. But every meaningful change requires coordinating with five other teams. This happens because team boundaries were drawn around what seemed like logical business domains, but without understanding the actual system dependencies. The boundaries look clean on the org chart, but create coordination hell in practice.”

“Most coordination problems arise when companies attempt to standardize their teams’ work processes, rather than acknowledging that different types of teams require distinct interaction patterns.”

“The solution isn’t better coordination, it’s better boundaries.”

Transformation Happens At The Speed Of Trust

Successful digital transformation needs these eleven types of trust.

Important, then, to question organisational behaviours that signal a lack of trust or erode and undermine trust. For me, heavy management process do exactly that. They suggest that teams aren’t trusted and that managers haven’t been given the space or skills to help teams build trust with each other. The obvious go-to solution is to implement a control-focused process that demands teams report more. The better approach would be for managers to coach teams in how to build trust in themselves, with other teams, and for stakeholders.

Pulp friction

My personal experience of the NHS is also, as Ralph describes, one of friction, poor coordination, opaque decision-making, and all underpinned by an attitude of patients being an inconvenience. It feels to me like the natural result of large organisations that are heavy on process (which enforces learned helplessness) and implicit about culture (in this case that doctors know everything, patients know nothing).

I thought about:

Probability of achieving outcomes

How might we figure out the probability of achieving an outcome?

Most probability analysis seems to rely on having historic data or knowing the range of possible results, which isn’t easy with outcomes. But maybe we could look back at previous work and ask questions like, “Have we been able to change this user group’s behaviour in the past?”, “What type of behaviours have we and haven’t we been able to affect?” and “How much have we been able to change behaviours, at what scale and for how long?” Maybe getting a sense of how successful we’ve been at changing similar behaviours for similar users to a similar degree could be used to predict how successful we’ll be next time.

And then looking outside, I think there’s also something about understanding the nature of the behaviours we’re seeking to change that affects how likely we are to change them. Behaviours that are part of a deep-rooted belief will be really hard to change, whereas behaviours that are more mundane should be easier. Considering the systems and environmental context might also be important for understanding how likely users are to change.

So, maybe by understanding user’s propensity for change plus our ability to cause change, we can come up with a probability of achieving an outcome.

Another little experiment I’ve been doing is to start with the assumption we’ve got a 50% chance of achieving the outcome, and every time a challenge gets in the way I take a few percent off, and every time we overcome a challenge I add a few percent. It keeps a (very subjective) running total of how likely we are to achieve the outcome by considering factors that come up along the way instead of having historic data.

Supply and demand

I got a bit obsessed with supply and demand curves and trying to figure out if the economics models can be used to prioritise work, which is a kind of supply and demand problem. There’s always more demand for work than the team can supply, and that creates a shortage. In a normal competitive market this would cause the price of work to rise, but an internal market with no invisible hand goes straight to a market failure state of requiring ‘regulation’ to control the demand. That regulation is the prioritisation activities organisations do to try to balance supply and demand. Economics is cool.

Right-sizing

I’ve been wondering if it’s possible to use the same approach of right-sizing a feature to right-sizing a project, albeit loosely. We’d need data about completed projects, what the scope was, how long it took, how many people worked on it, how much it cost, etc., but then you’d be able to look at a potential new project and say it looks a bit like this project we did three years ago that took us four months. That means we think we can complete it in four to six months, but if you want it finished sooner, we could make it look like this other project we did a while ago that took one month.

Downside of long-lived teams

The old way was to treat work as if it was on a conveyor belt. It would come to a team, they’d do their bit, and the work would move onto the next team. We learned that with hand-offs between teams comes considerable knowledge drop and this leads to more failures and poorer quality products.

So the solution was to create long-lived, cross-functional teams that move with the work, maintain knowledge as they go, and create better products. That created another problem: professional development. Working with one team on one product for a long time means individuals don’t get the opportunity to improve their skills that come from doing things again and again. How can we expect product managers to be good at vision setting if they only do it every decade? How can we expect product managers to be good problem solvers if they don’t face all kinds of problems in all kinds of situations?

You can’t do OKRs without a strategy

I think OKRs are brilliant. They are so suited to product work which is all about changing behaviours. But they only work if they are being used to deploy a strategy. If you don’t have a strategy then OKRs aren’t going work, and it’s why they sometimes end up as a short-term to-do list.