Category: Weeknotes

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.

I did:

Unassailable good

This week has involved a lot of challenging assumptions about whether something is really a good thing to do and what unintended consequences might arise, and also I…

• Learned more about how product, insights and finance can work together, especially around high-quality hypotheses and crunching the numbers to understand the benefits our work delivers. I’m going to write it up for other product managers to use.
• Went a talk about what is product management by Pippa Peasland, head of product at Vypr. It was really good, and everyone I spoke to afterwards thought so too.
• Presented our approach to reporting the financial benefits we expect to achieve to our steering group.
• Led another product manager development session where we talked about how product managers can create a balanced definition of product success.
• Talked (too much) about delivery management, what problems in solves in an organisation, and why it’s essential when teams are tackling complicated problems.
• Went to our product communities of practice session. It was really good to get so many product people together. I know from my chats with people that we have so much product knowledge, experience and expertise, but it’s spread out and hard to share and learn from.
• Looked at future (like, twenty years future, not next six months) opportunities for our product to grow and provide more value. I have to keep my critical thinking hat on and stop myself from assuming things like centralising a function, having a single source of reporting data, and building capability around a single piece of tech are inherently good things.
• I learned that the proof is not in the pudding, it’s in the eating.

What’s the difference between delivery managers, project managers and scrum masters

I tried to organise some of my thoughts on the difference between delivery managers, project managers and scrum master roles. I think it’s probably my most read in the first week post ever with over a hundred views.

I read/watched:

Conceptualising the interrelation between individual and collaborative work

The insight I took from this study is that collaborative time is best used for shaping and creating a shared understanding about the work (what they call maturation), and individual time is used more for doing the work (what they call execution). It also talks about some of the problems that come up between these two types of work; not having enough time for individual work and that time being too fragmented, because individual time is often not actively planned for, and the hidden work of “unanticipated volumes of coordination and rework” from poorly facilitated collaborative sessions and how understanding complicated things relies on people taking the time to think and reflect to come up with questions. They conclude that “Teams need to reach common ground concerning when, where and how work gets done.”, which fits the team autonomy narrative but doesn’t recognise the need for an enabling environment.

Also, any product managers building calendar or collaborative working tools (Notion, Trello, Jira -type tools) should be considering how to differentiate between these different types of work.

A project with no meetings

I watched a webinar about how Atlassian ran a project without any meetings. They basically said everyone made videos instead. Personally, I think the talk I did ages ago for DigiScot was better.

I do not think it means what you think it means

Who could resist a Princess Bride themed article about team performance? “…if they did the things that actually drove and supported high performance, it wouldn’t be called a new performance initiative in the first place. It would be called good management.”

A timeline of Earth’s temperature

Earth Temperature Timeline

I thought about:

Service and product are the same thing

When someone in an organisation tries to define the difference between a product and service it almost always turns into a show of power with whoever is doing the defining making their thing the more important of the two. That’s why we should always question who is doing the defining and why those things need to be defined.

In days gone by, there was a clearer distinction between a service and a product, but nowadays they are the same thing. And so it’s useful for product managers and service designers to work together equally (not where one has more organisational power than the other) so that the different perspectives overlap and work together to create a better product/service.

Small world

A friend of mine mentioned that a friend of hers had worked on introducing some new software where I work on the same day that I was unknowingly talking to the person that manages that software for us. Maybe small world theory should inform how we build social networks in our organisations. Be more Kevin Bacon.

Having a voice

Some people and some teams have a louder voice within any organisation than others, that’s the nature of hierarchies and getting things done. But if you want a more egalitarian organisation, then how the quieter voices get heard matters.

Questions for leaders

This week, did you…

• Listen more than speak?
• Ask more than tell?
• Encourage more than correct?
• Connect more than divide?
• Give power more than hoard it?

And if you didn’t, are you going to create more opportunities for you to next week?