Category: Weeknotes

I did:

• Wrote up last week’s workshop with the Delivery Manager’s community which focused on reporting and conflict resolution.
• Talked about vibe, and using it for workshops as a way of setting shared expectations. My go-to vibe is ‘rocket dog’, a happy jack russell riding a rocket. To me, it means we’re going to do this at pace, jump around a bit, and stay positive.
• Started planning a workshop to design team responsibilities, mandate level, interactions, etc.
• Met my new line manager. Was good to talk through the product vision and possible routes for getting there over the next few years.
• Did some more market analysis and theory of change work on a new opportunity, and lined up getting buy-in from senior stakeholders.
• Talked about how Profession and Community complement each other, with Profession providing the top-down ‘what’ and the Community creating the bottom-up ‘how’.
• Got my ticket for ProductCon next week.

The numbers

Tasks completed: 37

Minutes in meetings: 825

I read/listened:

The Impact of AI on Product Management: A Systematic Review and Future Trends

The integration of AI has greatly increased its functionality in product management across innovation and market development from the initial concept to the actual market share. AI tools have helped product managers to improve traditional processes as it is an advanced tool which can analyze a large dataset, identify the patterns and facilitates to generate efficient strategies. AI product managers are essential in driving the identification of business problems best solved with AI, defining the overall strategic plan, and guaranteeing that AI is implemented ethically, safely, and with transparency and reliability. The paper provides an idea of what is an AI product manager, how does AI influences more traditional marketing models (B2B and B2C). These advancements accentuate how AI holds promise for constant enhancement and sustaining competitiveness in a rapidly changing market environment.

The challenges of studying in the ‘platformised’ university

University life is now increasingly mediated by digital platforms. Joe Noteboom’s research looks at the everyday realities of studying through platforms, and how students’ dependence on these technologies can lead to a number of problems.

Remote-first team interactions

The tragedy of the anticommons

The ‘tragedy of the anticommons‘ occurs when a resource has many owners, all of whom have the ability to exclude others from using it, leading to the under-utilization of that resource. I wonder if/how this happens in organisations?

I thought about:

Looking back

Thought about how hard it is to see progress in the moment and how it only makes sense when we look back. Maybe this is why product histories are so important for helping teams see how far they’ve come.

AI for product managers

Few things going around this week about AI and product so I thought I’d try to get some of my thoughts down.

I see three interconnected layers of AI.

Starting at the bottom is what’s going on with AI even if you do nothing. This is about having a way of dealing with any emerging tech. It includes horizon-scanning, market analysis, trends, behaviours, etc. It also includes how AI effects you and your users, because it will.

The middle layer is using AI in how we do our jobs, which for now probably just means using Gen AI and Machine Learning, but which will probably include Agent AI in the near future. Understanding how to use AI is like understanding how to use a mobile phone or email. It’s another tool we’ll use to do our work regardless of whether we use it well (I’m looking at you, email). So, we might as well apply some of that critical thinking and figure out how to use it well (when is it worth it for the environmental impact, for example).

The top, and most interesting layer, is how we might use AI in the products we build. I’d suggest we won’t do this very well if we aren’t doing the other two layers because we won’t have wide and deep contextual knowledge about how people are using AI more generally. This layer of AI also includes machine learning, image recognition, data analysis and decision-making, and all the other kinds of AI that is used in products without the user necessarily knowing. But they are still part of the product so product managers need to understand how they fit.

I did:

It’s groundhog day… again

It actually was, that isn’t a metaphor. Although we did talk metaphors, including changing the wheels on the car while we’re driving and steering the ship without speaking to the engine room. Other stuff happened too:

• Ran a skills development workshop with the delivery managers community.
• Finished writing a guide to looking for opportunities, writing hypotheses, and evaluating benefits for product managers. Now over to our coach to use it.
• Learned a bit about the B2B part of the university.
• Wrote three Theories of Change to express my hypotheses for new opportunities.
• Discussed what problems we’re actually trying to solve with coaching, mentoring, training, community-building, etc.
• Was asked, “Why do you stay?” Answered, “Interesting problems.”
• Chatted about the rogue work I do, the stuff that doesn’t have permission or oversight, the stuff that just tries to make things better but has a high chance of failure (which is most of it, TBF).

The numbers

Minutes in meetings: 705.

Tasks completed: 25.

(Over 4 days as I was on leave one day this week.)

OKRs at the product leaders group

Attended Tom Dolan‘s presentation about how they do OKRs at Which? I think OKRs allow teams to jump over organisational hierarchy and connect directly to strategy, so I find it really interesting to see how different organisations do OKRs, and Tom’s a believer in working in the open so his presentation was really interesting.

I read:

7 D’s

I read Kent J Macdonald post on using his 7 D model to deliver internal products. I used a similar model in my dissertation about the product development processes charities use. Since then I’ve expanded it to: direct, define, discover, due diligence, design, develop, deliver, distribute. I’ve haven’t gotten around to writing it up yet but I don’t think of it as phases, it’s more of a checklist of things to think about.

Agents

I love a good whitepaper. This one goes into how it is a “combination of reasoning, logic, and access to external information that are all connected to a Generative AI model [that] invokes the concept of an agent, or a program that extends beyond the standalone capabilities of a Generative AI model.”

And Steve wrote about how Agentic AI needs UCD smarts.

Can I suggest no one names their agent ‘Smith’, just in case.

Anything can be thought about as a product

But I’m not sure that means anything can be a product (let’s not get into trying to define a product). Using product thinking to uncover worthwhile problems and hypotheses about how to solve them is definitely generally applicable.

Efficiency obsession

The shift from making sure everyone is working hard to maximising the flow of work is part of the transformation (along with the shift from outputs to outcomes, functional teams to cross-functional teams, etc., etc.) My pondering is; who’s job is it? Which role in a team is responsible for focusing on flow?

Love newsletters? You’re gonna love RSS

Andy Bell wrote about using an RSS reader to know when the people you want to read publish their posts and newsletters (which I read in my RSS reader).

Here’s the OPML file of all the newsletters, websites and blogs I’m currently following.

I thought about:

Conflict resolution, and other skills

After a conversation about skills like conflict resolution, I thought about how people might learn such highly technical (by which I mean need lots of expert knowledge), soft skills (by which I mean not easily quantifiable and measurable).

Empowered team leadership

There doesn’t seem to be enough written and talked about for how to lead empowered teams. I think that kind of leadership is rooted in a coaching approach, it that creates and holds space for the team, it doesn’t have the answers but tries to help the team ask the right questions.

Two types of product managers

I remembered a conversation with Michael Wilkinson from a while ago where he said that there are two types of journalists; those that are good at finding stories and whose that are good at writing stories. I was thinking something similar about product managers. Some are good at finding problems, some are good at solving problems.

In numerology, the number 444 represents clarity, stability and progress. So, we’ll go with that.

This week I did:

Horizons

It’s been a week of thinking in horizons, some near, many farther away, but doing the do included…

• Worked on some market research and business model options for a potential new product.
• Ran a workshop to help a team focus in on some measurable work.
• Went to a workshop about mapping capabilities and matching investment to where the competitive advantage is.
• Presented to our engineering director.
• Reviewed a theory of change so it’s ready to build an evaluation plan for a series of changes to a product.
• Chatted about show and tells, and shared boring magic’s post.

This week’s numbers

Number of minutes in meetings: 685.

Number of tasks completed: 35.

My new work tracking system is working pretty well. I still struggle with planning my week but that’s probably more to do with the uncertainty and pace of the environment rather than the system (although I guess you could say it’s not a very good system if it can’t handle the environment it operates in).

I read:

How to create a Real (Strategic) Roadmap

Saeed Khan published two articles on how to create a Real (Strategic) Roadmap:

Part 1 & Part 2

As always, I’m a bit torn. On one hand I agree with the product profession developing it’s practice and coming up with standard ways of doing great product work. But on the other hand, I’m not keen on the idea that there is only one way to do things like using a roadmap. I think organisations have such diverse situations and needs that flexibility in practices is a good thing. As I’ve said before: experiment → optimise → standardise.

Does the service standard work for local government

Phil’s answer is no. And he goes on to suggest some really useful improvements that could make it work. I think there’s a lot there for universities to learn from in using “a” service standard to assess products and services.

Architecture Modernization: Aligning Software, Strategy & Structure

Impact of Facilitation on Performance & Innovation

This looks like a cool site, especially for delivery manager.

I thought about:

Governance systems

I thought about governance and the system needed to govern well (because I’m cool like that).

ISO 37000, the standard for governance, is a good place to start to get a shared understanding of what governance systems need to do, things like accountability, value model, and viability and performance over time. It helps keep governance groups focused on their key outcomes of effective performance, responsible stewardship and ethical behaviour.

And on the systems side, I was thinking about Ashby’s Law of Requisite Variety and how it states that a system must be as complex or more complex than its environment to function effectively.

So, if a governance system “is to be able to deal successfully with the diversity of challenges that its environment produces, then it needs to have a repertoire of responses which is (at least) as nuanced as the problems thrown up by the environment. Or, to put it another way, a viable governance system is one that can handle the variability of its environment.” The more complex the environment, the more a governance system needs ways to monitor the environment, spot changes quickly, and have responses.

Given that most governance systems in organisations are slow, bureaucratic and generally have information flowing one way, I’m pretty sure they don’t adhere to Ashby’s Law. And that’s a problem.

Alignment practices

Thought about what we product people actually do to keep things aligned with teams and stakeholders, including:

• Using easy to remember and repeat statements and slogans.
• Writing follow-up notes after meetings and drop them into chat or email.
• Listening out for misunderstanding.
• Arranging and offering check-ins to create space for people to uncover misunderstandings they might not have realised they have (and so you aren’t telling all the time).

The medium is the message

The format we use to share information matters. In my head, its more important if it’s in an email rather than a chat message, a slide deck tells me you want me to listen to what you want to tell me, and a document suggests you want comments and to work on something together.

I did:

Diagnosis

Seemed like this week was about diagnosing some of the challenges we’re facing, which reminded me of Janice Fraser’s idea of product management as differential diagnosis. And I…

• Took part in some technology strategy workshops.
• Talked about how we manage risks and wrote a proposal for how to improve it.
• Said goodbye to the awesome Kate Ivey-Williams.
• Chatted to the delivery management community about delivery managing delivery management.
• And to our product coach about product managing product coaching.
• Met our new Group Product Lead.
• Prepared for a prioritisation workshop based on theory of constraints.

The numbers

Spent 1260 minutes in meetings.

Completed 39 tasks.

Bluesky

Finally got around to verifying my domain name as my Bluesky handle.

I read:

Decarbonising user journeys

James Chudley wrote a presentation about why we need to urgently decarbonise the internet, the thinking behind his approach and explains how you can start to decarbonise your own user journeys.

What Makes a Good Team?

Cate wrote a list of what makes a good team.

Taking a platform approach to help people interact with Royal Greenwich online

Ste Shine and Alex Sturtivant wrote about creating a platform that consists of reusable capabilities.

I thought about:

Adjacent possible and path dependency

Adjacent possible and path dependency seem like two important ideas for organisational change. The next step in any change is defined by the adjacent possible. If that step is too big or radical, it’ll fail. And as a few of those steps are taken they create a path dependency that is difficult to turn away from. Both of these tell me that organisational change might be better done continuously rather transformationally.

I did:

Circles of control, influence and concern

• Talked about team health.
• Discussed other ways for us to manage risks and figure out what is actually a risk and what is just the situation we find ourselves in.
• Did another product manager’s development session about defining and measuring product success. We talked about identifying user outcomes and assessing against standards.
• Started working on a presentation about the value of delivery management.
• Had an intro chat with our new product coach.
• Started thinking about how we might approach setting a platform strategy.

The numbers:

• Spent 855 minutes in meetings.
• Completed 29 tasks.
• Averaged 6 tasks a day (remember when it used to be over 10? Crazy times.)

Learning product

I spent a bit of time adding and removing stuff from productmanagement.zone, and some time thinking about the value proposition. I’m kinda of the opinion that product management is too big, vague and varied to be taught in a course, and also that agency and being able to identify what you need to learn are important for product managers. So, it would be nice to have a collection of learning resources where product managers could say ‘I only need a cursory knowledge of the Cynefin framework so I’m only going to watch a video’ or ‘I need more in-depth knowledge about measuring product success so I’m going to read those five articles and that book’. Of course, if I was a good product manager I’d be validating the need before I build anything, but I find creating and organising collections quite peaceful so maybe I am the user.

I read:

Organizations without any middle management?

This article explores how organisations can function without middle management layers. It distinguishes between structure and hierarchy, arguing that autonomous, self-managing teams empowered to make all the necessary decisions related to their own work don’t need hierarchy but do need good structure. It’s interesting to me, given my thoughts on how Professions attempt to fill the gaps created by cross-functional teams.

Cost of delay

Read a couple of posts about what is the cost of delay and estimating the cost of delay.

Continuous discovery habits

I started rereading Teresa Torres Continuous discovery habits (don’t ask me why, it’s not like I don’t have enough new books to read).

I thought about:

Team adjectives

If a successful product is valuable, viable, usable and feasible, then what is the successful team that creates that product? Maybe they are:

• Productive & Empowered (thanks to Debbie for those two)
• Happy, Productive & Aligned (thanks to Ian for those)

And from the literature, they’re definitely:

• Skilled – They have all the expertise they need to tackle the problem they’re working on.
• Integrated – No team is an island, they are part of an organisation and need information to flow in and out to be effective.

And maybe they’re also

• Informed.
• Committed.
• Decisive.
• Curious.
• Inclusive.
• Focused.

From authority to responsibility

If you want to shift the focus of the work from outputs to outcomes, you need to shift the focus of how people work from authority to responsibility.

Had a couple conversations this week about how organisations are struggling with the legacy of having ‘done lots of stuff because someone requested it without understanding what problems they were trying to solve or thinking about the effects on the coherence of the whole system’. The examples are always about technology but really it’s about power relationships. This kind of org-debt comes about when those with more power feel like their role is to tell people what to do and those with less power feel like their role is to do as they’re told.

The shift then, is moving that relationship to one of responsibility where those with more power provide the context for the problem they need to tackle and how we’ll know it’s been solved, and those with less power take on the responsibility for tackling the problem or saying no. Authority is given, responsibility is taken. And taking responsibility becomes a moral duty to do the right thing, to question why, to see where things fit in the big picture.

On developing a strong position

I’ve been thinking about how important it is for product managers to develop a strong position from which to argue for their products. Yes, stakeholder management, communication, relationship building, etc., are important, but without a strong position a product manager is likely to get swayed by stakeholder opinions. To develop a strong position, they need good critical thinking skills, solid data analysis, an understanding of product concepts and frameworks (and yes, I’ve previously been somewhat against product managers relying on frameworks), etc., etc.

What’s the difference between user and stakeholder?

Here’s my definition of the difference: users use a product to create value for themselves, stakeholders use a product to create value for the business. And to join them up, stakeholders use a product to create value for a business by making a product available to users for them to get value from it.

I did:

Convergence

Quite a lot of this week was about bringing things together, narrowing down and converging on a single direction. I also:

• Wrote up how product managers look for opportunities, come up with a hypothesis for turning it into something valuable, and then reporting on the benefits it delivers.
• Added more info to our product handbook (and promised myself that in future I will keep it up to date as we go long).
• Chatted about shaping the future phases of the product.
• Went to a talk about diversity, equality and inclusion in tech.
• Helped plan a retro.

Updated tracker

Although the data set isn’t complete yet, the latest version of my work tracker has some dashboards for how things look week-by-week.

Objectives by week

Number of meetings and tasks by week

Time (minutes) spent in meetings by week

I read:

Cross-Functional Teams: Good Concept, Poor Implementation!

This study (from 1993 and about manufacturing physical products) suggests that firms realize four primary benefits through the use of cross-functional teams:

• The shortcomings of hierarchical structures are overcome by the team’s ability to cut across traditional vertical lines of authority.
• Decision-making is decentralized.
• Hierarchical information overload is reduced at higher levels.
• Higher quality decisions can have a significantly greater potential of occurring than with individual decisions.

The authors say that no single firm has implemented the team concept to the fullest extent, but here are some of the characteristics of successful teams:

• Has functional representation, with all the areas that, at one time or another, are involved in the design, engineering, manufacturing, and marketing of the product for which they are responsible.
• Works as an open system, interacting with the organization it serves. The effectiveness of this interaction can make or break the success of the team concept within a firm.
• Shares information, so that other teams can benefit from their learning.
• Owns the decisions, and the decision-making processes.
• Have positive interpersonal relations, to help the team members work smoothly together.
• Effective leadership, where the leader can generate appropriate and sustained involvement of all necessary parties, eliminate unnecessary and unproductive digressions, maintain high standards for the decisions being made, manage conflict constructively, and, in general, achieve continuous levels of satisfactory group output without excessive burnout or rancor.

Product managers beware

Using AI tools reduces critical thinking. But of course, we should consider this critically and be intentional about how we use any of the tools available to us.

I thought about:

Principles or heuristics

What’s the difference? Principles can be chosen ahead of time, heuristics have to be learned, they are based on experience, they tease out tacit knowledge. Principles are fundamental truth that serves as the foundation for a belief or behaviour, whereas heuristics are more like rules of thumb.

So, do we need both? Do heuristics make principles actionable? For example, the scientific method is a first principle for product management, but in practice we have heuristics like cost-of-delay to help us in the analysis step.

Feedback loops

I started getting deep into feedback loops this week.

Turns out, the industrial revolution could not have happened without the invention of automatic control systems using feedback. Early steam engines were regulated by hand, making them less suited to industrial use, so it fair to say that the Industrial Revolution did not really start until the invention of improved engines and automatic control systems to regulate them.

Feedback loops have become increasingly essential since then and are a vital part of modern products.

One of the insights I found interesting is that for feedback loops to work effectively, the feedback has to be orders of magnitude faster than the situation being controlled. So, if we’re shipping fortnightly, then the feedback would have to be hourly in order for us to have any sense of what effect we’re having. In practice, it’s usually the other way round and feedback is much slower than the situation.

I did:

Handbook

Only two days of work this week, and hardly any meetings so I spent the time updating our product handbook, including:

• Introduction
• Vision & mission
• Strategy
• Objectives
• Roadmap
• Challenges
• Governance
• Research & insights
• Performance
• Communication & engagement
• Policies & principles
• Team & stakeholders
• Technology
• Workflow

2024 review

Reviewed what I got up to last year. Made me realise I should probably try to write up my thoughts as properly researched blog posts like I used to. There’s some topics emerging such as ‘The history and future of empowered teams’ and ‘How to work: choosing between project and product approaches’.

I read:

Predictions for Delivery Management in 2025

Fantastic post from Chris and Holly on where delivery management might go this year. I’m a big believer in good delivery management as an essential function within an organisation and nodded along to pretty much everything they said, including “shifting from coordinators to strategic leaders”, “Delivery managers are uniquely positioned to bridge the gap between strategy and execution. Their role in coaching teams, driving continuous improvement, and maintaining focus on value makes them indispensable—especially in times of economic pressure.”, and “Delivery is the “oxygen” of a successful team—you only notice it’s missing when everything starts to falter. In the words of a delivery expert, “If it’s working, you shouldn’t even notice it.” That’s a testament to the quiet yet critical role delivery managers play in creating high-performing teams.”

Agile project management

This paper talks about Agile project management as a blend of deterministic project management and adaptive agile software development, which I think leads to the worst of both worlds. I think Agile project management could provide a different way to manage projects – a probabilistic approach.

With modern project management software systems using machine learning it becomes more possible to express the state of a project as a probability of success. It could show the probability of meeting deadlines, being on budget, achieving outcomes, etc., and what might happen in different scenarios, e.g., if the budget was increased or work descoped. In that way, agile project management could bring together deterministic and adaptive thinking as it could show project management’s iron triangle of time, cost, scope and agile’s iterative progress and feedback loops.

As Chris & Holly said, “prioritising value is essential [but we] cannot completely deprioritise budgets or timelines. Striking a balance between the two remains critical”. Maybe a probabilistic agile project management approach could be part of that.

Most people don’t care about quality

Interesting reflection on the trend of user expectation and user experience from Terence Eden. I see the parallel in my discussions from a few weeks ago about Duolingo’s approach to learning, and how it prioritises engagement over learning. I wonder how much it applies to higher education (and when it’ll be undeniable). Do most people care about pedagogy? When will hour long lectures no longer be the best format, when will users expect three minute videos?

Product Waste and The ROI of Discovery

Product waste is building the wrong thing.

I thought about:

Mimetic isomorphism

Mimetic isomorphism is when organisations try copy what other organisations have done. Adopting the Spotify Model if you’re not Spotify, that’s memetic isomorphism. It’s an interesting idea because when it’s called out like that the reasoning and the flaws become painfully obvious.

Isomorphism also works within organisations, but we tend towards horizontal than vertical. This means that each team at the same level has the same structure. All governance works the same way because it’s at the same level in an organisation. The management layer works in the same way across all disciplines.

We don’t often see vertical isomorphism where management and governance structures match team level structures. This might mean cross-functional roles, objectives, priorities, influences, etc., mirrored and matched at all levels.

Explore-exploit trade off

The explore-exploit trade off is a decision-making concept product managers should understand. When faced with making a decision with incomplete information, do you make the best possible choice with the information available (exploit) or do you go looking for more information (explore)? This is the ‘how much research is enough’ question. Ideally, it should be answered on an ongoing basis whenever a question comes up as part of continuous discovery rather than all upfront or as a stop/start.

Standards

Another possible addition to the Decision Stack. Standards would go below Principles and express well-established, non-negotiable decisions such as security, data protection and accessible criteria.

I did:

No work

…but lots of thinking about work, including:

• How product managers might get practice opportunities to do product-y things they aren’t doing in their day-to-day work.
• What the steps to truly cross-functional teams that can influence all six aspects of the socio-technical organisation (goals, people, processes, structures, technology and products/services) might be.
• How Daniel Pink’s work on motivation (autonomy, mastery, purpose) could form the basis for a framework for delivery management.

Timeline

Added to the timeline of digital work. I’m being a bit haphazard at the moment and adding things as I think of them (books, regulations, etc.), but eventually I’d like to be able to follow threads of ideas to show how thinking changed over time. An example might be ‘how teams work’ which include Andy Grove’s work on OKR’s in the 1970’s, the adoption of open plan offices in the 1960’s, and the Tavistock Institute’s research in the 1950’s.

Introduction to Responsible AI

Signed up for BABL’s Introduction to Responsible AI course.

I read:

Signals to the system

Ben Holliday wrote about small bets for digital transformation, and how they can be “smaller experiments and pockets of innovation to create momentum and progress… Then you can distribute, share and scale what works”.

I’m a big believer in using experiments to validate learning. As I may have mentioned before, ‘expertiment, then optimise, and only then standardise’.

Bets

Started reading Thinking in bets by Annie Duke. Within the first few pages she blew my mind by separating good and bad decisions from good and bad outcomes, so I think I’m really going to enjoy it.

Why probability probably doesn’t exist (but it’s useful to act like it does)

This is a thought-provoking article that calls into question what we think we know about how to predict the future (which is what product management is kind of about).

Bill Campbell’s guide for bringing out the best in others and coaching teams

When looking for influential people for my timeline of digital work, I came across Bill Campbell who is referred to as “the coach of Silicon Valley” because he coached many start-up founders. He never wrote a book but some of his coachees did to try to capture some of his wisdom.

I thought about:

Moral philosophy knows why your agile transformation failed

You can’t be utilitarian with your principles, and deontological with your practices. It has to be the other way round.

This is my current conclusion about how organisations use principles and frameworks and why that fails to deliver much real change.

Organisations are flexible about principles. But it’s too easy for principles to be so vague as to be meaningless and so optional as be nothing more than nice ideas. Deontologically speaking, principles provide hard and fast boundaries that are universally applicable. Thou shall not kill is a principle. If don’t adhere to the principle, you have to suffer the consequences.

So, can you have optional principles? Probably not if you want them to be anything more than just talk. You only actually have principles if they change people’s behaviour.

At the other end of the scale, organisations tend to enforce the use of certain frameworks. But instead, they should apply a utilitarianist approach where the ends justify the means, or to put it another way, the right framework and practices are chosen for the right situation.

This gives the people doing the work empowerment in the right places. It gives them opportunities to try different ways of working or stick to what they know.

Obviously, agile and other types of transformation fail for lots of complicated reasons, but enforcing principles and being flexible about frameworks might be a useful step for helping them succeed.

This week I:

Work wrapped

Last working week of the year so spent it mostly writing up stuff I’ve learned from the last eight months.

• Chatted about the existential crisis facing universities. I think the problem is that the world has changed so much in the last five years (pandemic, cost of living crisis, climate change, politics) and no one knows how higher education needs to respond to be successful in this new world.
• Posted Lenny’s interview with Jackson Shuttleworth from Duolingo in our product community of practice. There are some interesting thoughts about educational pedagogy versus product engagement.
• Attended a talk about how Sport England used the Team Onion.
• Listened to one of our directors talk about Audree Fletcher’s organisational self-sabotage.
• Talked about Definition of Ready and how it’s useful if work is standardised, but how creating a shared understanding is better for teams doing varied, novel work.
• Used the North star metrics framework to map out how different products contribute to the benefits we want to deliver.
• Updated the product wiki and roadmap to get things tidy ready for next year.

Four mental models for defining product

Wrote a quick blog post about ways to define what a product is based on the mental model people have in the organisation.

Delivery chat

Had a really nice chat with Holly from Torchbox. We talked about how under-valued delivery management is in lots of organisations, especially if people have never seen really good delivery management.

I read/listened to:

Make it

Because behavioural science matters for product management, here’s a shortcut that helps you anticipate problems, identify opportunity points, and design a solution based on what people are actually likely to do.

Does ChatGPT enhance student learning?

This systematic review and meta-analysis of experimental studies of the use of ChatGPT in education shows that ChatGPT’s have the potential to transform learning experiences and reinforce educational outcomes by improving academic performance, affective-motivational states, and higher-order thinking propensities.

It’s fairly easy to imagine what AI-powered education might look like; lecture videos generated for each student, detailed feedback on assignments, proactive prompting to engage with learning materials. But that’s just about how we use AI to do what we already do better, it isn’t a new vision for education. And maybe that’s because AI isn’t a good basis for doing that, maybe it is, at it’s best, just an efficiency gain on the existing.

Streaks

Surf social

“Combine people and posts from to create an awesome custom feed for whatever you want.”

Hoping this might be a better solution than RSS feeds in Slack for keeping up with what people are writing.

I thought about:

Optimisation before standardisation

Not only should standards only be applied where interoperability is required, they should only be developed once the solutions to the problems are well known. If there is still unknowns and uncertainties, figure these out before trying to standardise. Don’t standardise too early. Experiment, then optimise, only then standardise.

Product thinking for organisational change

I’ve previously thought that product thinking isn’t a good fit for organisational change because in product changes are intentional and they can’t change back unintentionally. But when changing an org culture, change is hard to control and is best tackled as emergent. People’s natural response to the uncertainty of change is to go back to what they know, which usually means hierarchical control and focusing on outputs, which creates an enormous drag factor to successful change.

However, where product thinking does apply is in how to approach the change. Rather than building the thing first, do the discovery work to understand the problems and figure out how to get adoption. If you can’t figure that stuff out, there’s no point building the thing.

My little guide to better discussion

I try to read twice as much as I write, and write twice as much as I talk.

In practice, this means taking some time to research a topic, refresh my understanding, think critically about it, and write down my opinions. If this can help me have more informed conversations that provide more well rounded answers, then hopefully I can be more helpful to others.

I did:

Challenges

This week has involved recognising the challenges of the past year and the challenges to come next year. It’s important to do that. Challenges have to solved together, which only happens if we can all understand them. Other stuff happened too:

• Had a really nice team meeting with everyone sharing some of their challenges, in particular the barriers to change that we face. I still firmly believe that the only way change happens is by people talking to people. PowerPoint never changed anything.
• Thought about different approaches for managing technology and how it depends on what you’re optimising for. It’s like the old sales thing of “Fast, good or cheap; pick two but you can’t have all three.”
• Chatted about product discovery practices and responding to user feedback, and saw a great example. I love finding things like this. It’s so much more effective than big programmes to introduce things like user research.
• Helped shape some work for next year.
• Went to a visioning workshop for platform products. What I love about things like this isn’t getting to answers, it’s seeing all the different perspectives people bring.
• Started moving my task tracking into Notion (which I’ve previously only used for notes) and trying out dashboards. I haven’t yet figured out how to show more than one chart on a page but it looks like it could replace Google Sheets.

Prioritise problems, sequence solutions

Wrote up a few thoughts on the difference between prioritising and sequencing, and whether they might fit in problem and solution spaces.

I read:

Bring skills, energy and love

Matthew Moran, with probably the greatest opening line of any blog post, “What we’re seeing right now is the prolonged demise of the post-WW2 world and its institutions.”

Clever girl

I looked through lots of Janice Fraser’s slides. They’re great. Maybe more people should make more slides. Not for presentations (we’ve all seen too many already) but as thought-provoking provocations. Because the thing about slides is, you never know exactly what point the author is making, which means you have to think a bit more and fill in some gaps with your own thoughts. I particularly like this slide about how product management is about differential diagnosis rather than process implementation. It makes me think.

Transformation is generational

Agile, lean start-up, OKRs, etc., are tools for change. I never used to think this but now I do. Christina is right, organisations do have to change for these new mindsets to be effective, but it’s also true that these things can bring about the change. The thing is, that change will take decades. The next plateau of change all these transformations across all these organisations will reach is when everyone in the workforce has only ever known this way of working. It took an entire generational replacement to make the most of electricity, it’ll take the same with the Internet. So if you’re pushing your org to be more agile or user-focused or have greater transparency, then know that you are doing good work but it takes as long as it takes, you aren’t failing because the change hasn’t happened yet.

Oh also, most organisational transformations aren’t nearly ambitious enough!

Make the state “more like a start up”

Pat McFadden’s speech about the need for government teams to use a “test and learn culture” pioneered by digital companies to tackle some of public sector’s biggest challenges created a lot of chatter. Matt Jukes said this, James Plunkett said that, Public Digital blogged about it. And lots more people said lots too.

There are lots of angles and agendas, and I’m not particularly interested in government departments, but I am interested in organisational self-image and how much it affects what’s possible. So, if the people involved think of government departments as bureaucratic, slow, risk-averse, etc., then maybe it makes sense that their perspective is that government departments can’t operate like a start-up (with the important word being ‘like’, not ‘the same as’). But if you believe it is possible for the people in an organisation to think differently about it, and that how they think about it changes how it operates, then maybe a government department operate more like a start-up (with the important word being ‘like’, not ‘the same as’). Speeches are great, funding is great, changing beliefs is greater.

I thought about:

The problem with professions

Back in the day, in functional teams, where everyone had broadly the same skill set, things like career progression, pastoral care, etc., were handled within the team. Everyone was only ever part of one team, which meant all the work happened in the same place as the line-management, and they was only one team culture. Functional teams aren’t perfect, they create inter-team and organisational problems, but for the people in them, they had a lot of coherence.

As we moved to cross-functional teams, that was lost. Cross-functional teams aren’t perfect either, but they bring a lot of benefits. The work the team does can be more effective when the team has all the skills it needs and can work independently of other teams. But the team doesn’t have a way to handle skill development or career progression or coaching and management support, which is also important. Unfortunately, hardly any organisations want to go far enough with creating properly autonomous cross-functional teams that do include these things, so instead they looked for a way to fit cross-functional teams into a hierarchical org structure.

What they came up with was ‘professions’. Professions are a way to bring together people of similar disciplines and provide some of the aspects that are important to individuals but are missing from cross-functional teams. Professions is an inadequate solution to the problem cross-functional teams creates. It makes the problem worse. A person now has three, potentially competing, team cultures to contend with. They have the culture from their original functional team, with all the historic incentives, motivations, relationship dynamics, and the culture of the cross-functional team, with new ways of working, priorities, inter-functional understanding, and the culture of their profession with pressures to mature their discipline, achieve personal objectives, support their colleagues (and this doesn’t include informal groups, communities of practice, etc., all of which also have their own cultures).

There is no overarching organisational mechanism to align and coalesce these different cultures. Individuals have to figure this out for themselves. Now, working life has far less coherence and far more confusion. I don’t know what the solution is, but it should probably consider Larman’s Law.

Variability

It used to be that the way to get efficiency at scale was to design things to be standardised, replicable and easily replaceable. Utterback and Abernathy wrote about how a dominant design emerges, that’s why most cars look basically the same. Team and org design also takes this approach. But it doesn’t have to.

One of the ideas that Internet-era and digital (whatever that means to you) thinking brought up is ‘variability’. We can create things that are unique and personalised (on-demand printing) and create things that deal with lots of difference (website that works on lots of device and browser combinations).

Applying that digital mindset to org and team design still has some way to go. The approach there is still very much about creating standard patterns. A digital-first org design might start with identifying specific ‘problems’ the org has to deal with and organise roles and teams around them. So, rather than a HR team, there would be a Hiring team, and an Onboarding team, and so on. Those teams would have roles specific to that problem. The Hiring team might have an expert in advertising or social media and developer for the application tracking system, whereas the Onboarding team has a service designer and training expert.

In this way, every team would be different. There would be no standardisation across teams, they would be all about variability to tackle the problems they are designed around.

Product management in the permacrisis

More thoughts on the future of product management, given the permacrisis we’re all living through and we can’t carry on as if nothing has changed. Moving from internal socio-technical interactions to external eco-socio-technical interventions in broken systems. Moving from revenue and endless growth to Elkington’s triple bottom line of people, planet and profit (within the org and for user success) and Raworth’s donut economics of planetary and social boundaries. One day I’ll make some sense of all this and write about it more coherently.