Category: Weeknotes

I did:

Cohesive collectives

Some of the groups I’m part of are well-formed and others are less so, and I noticed that more intentionally this week. I think groups work better when they have something to coalese around so I need to think more about what those things are beyond organisational structures. Anyway, I also did this other stuff…

• Had an interesting session with our new team members and others that work on the same product in different ways. It wasn’t nearly long enough because there’s so much to know, but it was the first time I thought of all nine of us as a single collective.
• One of our product managers wrote some amazing outcome-focused objectives and key results. I need to up my game.
• Talked about product management and product managers developing a USP.
• Had a business review meeting, which I really enjoyed, and think it’s going to be the driver for product managers joining up their thinking so we can present more cohesively and being more about outcome-focused.
• Took part in a show and tell. I really want to make our show and tells less progress update and more agile governance, but I’ve already got lots to do.
• Met our new director of product strategy and talked about product’s relationship with other things in the university.
• Talked about the nature of product development and how you can’t be delayed if you don’t have a deadline.
• Started researching how to make course credit machine-readable (because of digital transformation).
• Started designing a methodology for metrics and reporting for complex change across the university, so no pressure.

I read/listened to:

Guides slow learning

Actually, guides that feel complete can slow learning. That’s the point Harry Bailey makes, which is an interesting challenge outside agency project management. How much information is too much? How much space for figuring things out is just enough? My go-to thinking for this is, where is this thing in the ‘experiment-optimise-standardise’ process? If you’re doing something completely new, then don’t follow a guide, experiment and share what you learn for others to optimise. If you’re doing something that has been done lots of times before, then follow the guide, use standardised patterns because it’s more efficient.

Invisible work

Invisible work is an interesting idea. Rian van der Merwe talks about the shadow backlog as a symptom of a roadmap that doesn’t reflect reality.

It got me thinking, what does it mean to make work visible? It’s a principle I believe in but have never really questioned. Why should work be visible, which work, and visible to who?

Often it’s the meta-work that is invisible and seen as non-productive (see glue and grease below), but the more complex an organisation becomes the higher the ratio of meta-work to work (if you don’t believe me just count how many people in your organisation do productive work and how many managers there are).

Taking that idea of all work being visible to the extreme, imagine an organisation where every activity has to be agreed and planned in advance. It would be a coordination nightmare. No one could do anything without permission. No creativity. No spontaneity. We don’t want that, so celebrate the meta-work, the invisible work, the glue and the grease work.

How to lead without authority

Sean Flaherty talking about behavioural science on the product experience podcast. Although I don’t agree with everything he says, it’s nice to hear more people talking about behavioural science in product management. We really need to figure out how to apply behaviour change techniques more consciously to our products.

I thought:

I blame Total Quality Management

The concept of ‘internal customers’ is one of the worst ideas in business. I’m all for customer-focus, although it has it’s issues, but when it treats colleagues as customers it creates a dysfunctional relationship with an unhealthy power dynamic.

Deadlines

A few different conversations got me thinking about deadlines and theory x theory y management. Deadlines, as we usually thinking about them, are an extrinsic motivators from theory x. Understanding the context and impact of certain dates is an intrinsic motivator from theory y. But the thing is, in most cases for most teams, neither of those make any difference because the factors that affect whether they deliver on time are outside the team.

Glue people and grease people

I was thinking about glue people and what that means when serendipity sent me Duncan Stephen’s blog post in which he says that glue people are “superconnectors”. Glue people connect other people, they are all about relationships. They join-up ideas and stick things together. They are important and necessary people to have in organisations.

And then there are grease people. They move things along. They are bothered about progress and momentum, about getting stuff done. They are important and necessary people to have in organisations too.

You need both (and all the other types of people).

I did:

Explainability

This week seemed to be a lot about what we can explain and how and why it matters. And I did this too:

• Adapted my product topology to be more acceptable to our current understanding of products (sometimes I’m just too visionary :D) and added the capabilities each product needs. Still more to do but it’s a useful exercise to see which journeys collect data, which send emails, etc.
• Worked on product metrics a bit. It’s one of those topics that just goes deeper and deeper the more you look into it.
• Talked about how Trigger’s broom explains what a product is. You can change the parts (tech, UI, etc.) but the whole remains.
• Set up an evaluation model for one of the products I’m working on. It’ll help us understand the finances and see what effect changes have.
• Talked about the puzzle of why university’s professional services departments aren’t ahead of the curve in modern business practices when they have first-hand access to academics and researchers that are creating the curve.
• Started a product decision review, which is where I look back at decisions we previously made and ask if they we’d make different decisions knowing what we know now. The answer is almost always, ‘yes’. It’s a great learning exercise. Maybe one day I’ll turn it into a little workshop.
• Someone asked me what the most important product management skill is. The answer is easy; critical thinking. Without that product managers can’t really do product work.

The numbers

Minutes spent in meetings: 995.

Number of tasks completed: 61.

Passed 2,000 items (tasks and meetings) in my tracking tool, which gives me a pretty good data set to analyse my productivity.

I read:

What should product managers learn?

Another brilliant post by Seyifunmi that really got me thinking. My answer is to create a method for learning in verticals that you can apply to any topic. So, for example, if you want to learn about stakeholder communication you can start at the top with tactics about communication channels (yeah, I still make the mistake of emailing people even though I know only 40% of them will read it), then you get into principles of good communication like working in the open, and maybe you branch off a little into psychology but then you go deeper into communication theories, and right at the bottom you learn about dialectics. Think of it a bit like ‘5 whys’, each time digging deeper into you get to the real learning.

Has Your Product Management Role Quietly Turned Into Project Management?

“…to be a successful Product Manager, you must be an excellent project manager. The ability to coordinate, track, and execute is a foundational superpower.” That explains it then. I’m a rubbish project manager. You wouldn’t want me project managing anything more important than putting the bins out on the right day. But to offer an alternative perspective…

Project management is a highly-skilled profession in it’s own, and product managers shouldn’t be trying to be second-rate project managers. If you’re a project manager, you have my admiration. I’ve worked with some amazing project managers who blew my mind with their ability to coordinate things. If you’re a product manager, and if you’re lucky enough to work in a context where this is possible, focus on coherence, not coordination. Your users will thank you when the product makes sense and helps them solve problems. They won’t thank you because you met a deadline.

Project management excels where there is more certainty, and product management where there is uncertainty. So, when Seyifunmi says, “…product management is about what and why. Project management is about how and when.”, she is expressing this distinction. There is a certainty to ‘when’ that comes from human beings having systemised time into a calendar. There is lots of uncertainty about ‘why’ an organisation is doing what it’s doing in which markets for which audiences. These questions often remain unanswered, and that’s fine because it isn’t a product manager’s job to answer them. A product manager’s job is to create some coherence amongst all this chaos.

A Radically Good Product Framework

I love a good framework as much as the next person but in my experience product teams don’t have a problem asking the right questions, they have lots of problems getting to answers that make sense, that remain unchanged for long enough to guide progress and that continue to make sense retrospectively. Show me a framework for doing that.

Inside-out and the outside-in orientations

“The inside-out and the outside-in perspectives point to different sources of competitive advantage for firms (Roquebert et al., 1996). Even though both perspectives consider both internal and external elements, they vary in terms of the relative emphasis they place on these elements (Paladino, 2009). While the inside-out orientation primarily considers organizational resources, rather than competitors and customers (implicitly), the outside-in orientation appears to reverse the order by first examining customers and competitors and only then the degree to which the firm responds to them, so organizational resources are implicitly addressed (Paladino, 2007).”

How do I lead change when people agree in public but resist in private?

Really interesting post on change. As product managers, our job is to change user’s behaviour in ways that achieves their outcomes and business results. For most product manager, the really important word there is ‘user’. They are only responsible for changing users behaviours, not colleagues behaviours. But the more senior a product manager becomes, the more they have to be able to change colleague’s and leader’s behaviours to create the space for doing the work to change users behaviour. In most organisations, that’s most of the product work.

I thought:

Evaluation drives efficiency

If something has to be able to be evaluated then it has to become standardised so that the outputs are comparable. It’s the old, “What gets measured, gets managed” nonsense, where ‘getting managed’ means being controlled, standardised, analysed. I’ve talked before about where standardisation is appropriate, but it really is key to good evaluation. When the same word means different things to different people, understanding has not been standardised. When a number can be interpreted to mean different things, insight has not been standardised.

The interaction theory of the firm

Thought about how to explain organisations as being about people interacting with other people. Whether its employees interacting with employees, employees with customers, or customers with customers, the reason organisations exist is to keep people associated with the org (HR for employee retention, marketing for customer retention), aligned with its purpose, and interacting with each other. If the theory holds, the better an organisation is at making those interactions happen, the more successful it will be. Employee communication, collaboration, alignment, customer service, branding, all exist to improve the nature of the interactions.

I did:

Because

The word “because” is used before giving a short reason or explanation, especially when you think the reason or explanation is obvious. We don’t use “because” enough. Maybe because we think the reason is obvious, but we should remember it isn’t always. Us product managers need to know our because. And we need to use it more to get people to the right focus, not just on what we did but why we did it. That is my reflection this week, and I did this stuff too:

• Retro analysis and recommendations.
• Talked about the work behind the work behind the work (because you can always be more meta).
• Listed (because not everything needs mapping) the big things we want to change within a service.
• Talked about business impact being athe focus for product managers.
• Thought about a new product I’d love to work on that connects alumni together to provide mentoring, networking and career connections.
• Lots of interviews (a third of my scheduled working hours, in fact) with some interesting and unexpected results.

I read:

The power of intentional incompleteness

Rachel shared this fantastic post with me about the power of intentional completeness. It talks about one of the bias we have for wanting to complete incomplete things. It’s a useful bias when designing products because we can use it to help people finish things. I really need to get on with writing about behaviour change for product managers. Given our job is literally about changing user behaviour, psychology and behaviour change methods are so lacking in our body of knowledge.

Ballantine’s Hedge

Wonderful thinking from Matt Ballantine on how to consider organisational change and six principles to remember. 4, new hedges planted in uncleared ground struggle, and 6, the soil determines what grows, are the ones that stuck with me.

Bring Clarity to Complex Services (Without Service Mapping)

I haven’t quite figured out why but there’s something that bugs me about always expressing services as linear, sequential steps, so finding other ways to represent and understand them is exactly what we all need. I really like simple dashboard -type views so I’m definitely going to build on what I’ve done so far with these examples.

Re-wiring risk & control

Led by the amazing Ann Gambles, this discussion about risk and control talks about the motivations for having green dashboards that don’t reflect reality.

I thought:

Why focus and alignment is the wrong approach

A lot of the day-to-day management and thought-leadership around how to be an effective organisation/team/product manager follows a narrative that says if we can just get everyone aligned on the same goal, get everyone to focus on the most important thing, then performance will magically emerge as a result. It’s an attractive and simple narrative but it’s wrong, and it’s wrong in two ways. Firstly, that singular focus is the right state to aim for, and secondly, the assumption that singular focus results in higher performance.

Why circles of influence is nonsense

Because you’re not meant to do things on your own. You’re meant to team up, join forces, work with others until together you have all the influence you need.

The power of content people

It seems like a consistent pattern in organisations that produce and manage lots of content, that content people are widely distributed across other teams and subordinate to functions like design. I think it’s a quirk of historical organisational design that means all forms of content aren’t considered specialist enough to be together in the hierarchical structure. I wonder if changing that would make any difference to anything.

Measuring silos

If conversation is the unit of culture change and you can measure it by counting how many conversations leaders have with people outside their reporting line and below their pay grade, then what is the unit of analysis for breaking down silos and how would you measure that? Maybe the first part of breaking silos is making work visible, so the metric is it the number of people outside the team that are aware of the work (because we’re outcome-focused, the measure is always about people’s behaviour and not output measures like number of emails sent). Needs more thinking, but it’s probably worth it.

More ways RACI can be improved

And by improved, I mean scrapped completely.

From…

Accountable	One person
Consulted	A few people who don’t really want to be involved
Informed	A few more people who’d rather keep their distance

To…

Objective 1	Whole bunch of people who need to work together to achieve it
Objective 2	Whole bunch of people who need to work together to achieve it
Objective 3	Whole bunch of people who need to work together to achieve it

I did:

The Zeigarnik effect

The Zeigarnik effect is our tendency to remember unfinished or interrupted tasks better than completed ones. So, given it was a one day work week (why did no one think of this before!), I focused on new things rather than finishing things from last year. Go figure.

• Fed back on the product development section for our new delivery playbook.
• Did some research into the leaky bucket problem and a sense of belonging to help with a new product strategy. They are surprisingly connected concepts.
• Added a strategic hypothesis and future projections to a new business review dashboard.

2025 review

Wrote about things I’ve thought about and written in 2025, just like previous years.

Resource library

Started moving my product resources library to Notion. It’s not really the right tool but I use it for lots of other things so at least it’s easier for me to add new stuff to. Maybe one day I’ll actually do something with it. Maybe I’ll build a product that helps product managers learn about

I read:

Top 10 AI PM mistakes of 2025

What ~2k hours training and engaging ~1k PMs revealed about AI hype, bad product thinking, getting vibe-fired, and 2025’s biggest AIPM mistakes.

Head Up, Feet Moving. Complexity isn’t a spectator sport

Study complexity science. Learn the concepts, read the papers. But at some point, if you want to work effectively in complex systems, you have to engage with the system as it actually plays out.

Arrive. Pommel. Leave.

Really nice essay about being a specialist and focusing on your strengths. Of course, it’s not the only strategy to career progression, and you should always consider your context.

Imperfect, impermanent, and incomplete

Another nice essay from Steve Kamb, this time about, “finding beauty in the understanding that everything is imperfect, impermanent, and incomplete. To embrace Wabi Sabi requires the ability to reflect on the fact that change is the only constant, nothing lasts forever, and perfection is unattainable.”

I thought:

Reflections on line management

• It’s not like it used to be. Although we still use the term ‘line manager’, we don’t manage production lines anymore. Cross-functional teams and matrix organisational structures mean managers and managees are often not working on the same things. This means line-management can’t be directly about the work, and line-managers can’t get direct feedback about a managee’s performance. So line-management has to be approached differently.
• As a line-manager, my goal is to give the people I support the skills and experience to get a better job and leave the organisation, and create the kind of environment that makes them want to stay. That way, whatever they decide is a win for me.
• Mostly, line-management involves switching between coaching, mentoring, advising, instructing, training.
• Career development opportunities are often the hardest part of line-management because most organisations are set on having people doing their current job, not get a new job. My approach goes like this:
  • Ask the managee to find a job ad for a role they might like in five years time. This grounds the discussion in real life skills and experience and measurable distance to cover.
  • Find opp.ortunities that help the managee develop their skills and experience to, one day, match the job description.

Business objectives

Just as there are really only three user outcomes (easier, cheaper, faster), there are only five business objectives (and Dave McClure nailed them years ago):

• Attract new users (acquisition / growth)
• Get users using (activation / conversion)
• Keep users using (retention)
• Get users to pay (revenue)
• Get users to tell others (referral)

Roadmaps

One of my realisations from last year was that no single roadmap works for the entire product development process from idea to decommission. Format aside, and whether roadmaps should show dates because we all know the answer to that, the problem is there is no single unit of analysis that can represent all the different work that takes place across the product lifecycle. This is an interesting problem that must have a solution, which probably looks like a definition of how roadmaps should change across the product lifecycle.

MVP does not mean

You can’t call something an MVP just because it’s:

• Unfinished
• Untested
• Unproven
• Unsupported
• Unmeasured
• Unclear
• Unfocused
• Underwhelming

I did:

Happy holidays

Two and a half day week with lots of people on leave, so time to finish off things.

• Took part in some product manager interviews.
• Finished another retro analysis.
• Talked about what I think a great onboarding experience looks like and how it’s mostly meeting expectations and expanding mental models.
• Finished development plans for two of our junior product managers.
• Talked about a development plan for another member of the team.
• Put together a dashboard for a business review meeting in January.
• Started thinking about how to build a recommendations engine.

Getting agile governance right

Wrote up some thoughts on what sometimes gets missed about why teams do show and tells and what else is needed to make agile governance work.

I read:

The Product Operating Model at Google

I read Itamar Gilad’s response to Marty Cagan and Elias Lieberich’s article about the product operating model at Google, so I thought I’d critique their concepts of a product operating model using neo-sociotechincal systems theory. Neo-STS evolved from traditional social-technical system theory, which was the basis for lots of ideas about modern work such as empowered teams, but it recognises that digital technologies have changed how organisations operate and so adds four components: multi-encapsulation, complex interrelation of socio-technical elements, multidirectional inheritance and continual negotiation.

SVPG’s and Gilad’s product operating model are limited by the same outdated thinking about how organisations are organised. For example, they show strategy as being done . Multi-encapsulation tells us that is ‘containerising’ of work is problematic and that strategy work is better done when it’s part of and affected multiple different socio-technical systems. Cagan splits discovery form delivery in the SVPG model, but the complex interrelation elements shows us how these kinds of activities are interrelated, redundant, competing, or conflicting at the same time. Gliad’s model shows goal and metrics in isolation to other parts of the model, but continual negotiation reflects how goals are simultaneously reinforcing work structures required to achieve goals and being changed by ongoing negotiation.

Their models suggest specific parts of the organisation are responsible for specific functions, they don’t show the relationship between the parts or how information flows, and have no sense of change over time. It’s a shame so many product people look at popularist thought leaders like this when there is far more robust thinking available.

Why Agile Teams Succeed – or Don’t

The agile mentors podcast about what makes teams succeed and some interesting stuff about the difference between task conflict and relationship conflict, and how adaptable people are when it comes to fitting into teams and work cultures.

Task conflict is good because people care enough to disagree and discuss how something should be done, but when conflict becomes about proving who’s right and who’s wrong, then it’s relationship conflict and that’s dysfunctional within teams.

The research shows, they say, that the blending of different personality traits and preferences isn’t really much a problem because human’s are social creature and are really good at adapting to fit into groups, and it’s how the group works as a whole that affects its performance, not the personalities of individuals.

I thought:

Product thinking skills

If product management is all about finding worthwhile problems, then two product thinking techniques for understanding problems are decomposition and abstraction. Decomposition, breaking big complex problems into smaller more easily manageable chunks, and abstraction, filtering out the factors in order to understand which affect the problem in what ways, are essential skills that are hard to learn but will make far more difference to a product manager’s practice than any prioritisation framework.

Understandable

Making things understandable is a super power. You can have the best metric in world but if no one understands it then it’ll be ignored. You can have the most impactful actions but if they aren’t themed together in a way that makes sense no one will get behind them.

Management feedback loops

You know how I feel about feedback loops, I go on about them all the time. I’m trying to build them into my practice as a line manager. As we’re product managers, it’s not about the activity but the results we get. So I don’t want to ask questions like, “Am I challenging you enough”, I want to ask, “Are you being challenged enough”. I need to figure out my system for collecting and responding to the answers, but I think the product managers I work with will do better if I get fast feedback loops in place.

I did:

Yerkes–Dodson law

Way back in 1908, psychologists Yerkes and Dodson came up with the idea that peak performance occurs when we challenged just the right amount. Figuring out what that looks like for myself and those I work with has been on my mind this week. This stuff happened too:

• Wrote up some options on different ways of organising teams. For comparison, I went with axes of flexibility and cognitive load/how easy it is to understand. Dynamic reteaming, for example is high flexibility and high cognitive load. Traditional functional teams are at the opposite end of the scale.
• Finished two retro analyses and ran another retro. Definitely more insight for my meta-analysis (which will never actually happen other than in my head).
• Chatted (ok, ranted) about agile governance, how it drives quality incrementally rather than occasional big chunks of approval, and how it depends on everyone understanding what they need to do.
• Went to a kick-off for a new piece of work where we tried to map the scenarios we’ll have to deal with over the next few months.
• Worked with another product manager to do a lot of stakeholder engagement.
• Started onboarding for our new recruits.
• Talked about mission & vision and north star metrics for our product group.

I read:

In Matt’s Honest Opinion

One of the good things about using feeds for content discovery is looking back over someone’s feed and finding stuff you didn’t know they had written. Which is what happened with Matt Jukes’ IMHO series:

• The Art of Effective Agile
• Roles, responsibilities and relationships in digital delivery
• Agile Planning – Roadmaps and Releases
• Okay OKRs and unproblematic prioritisation

Year of the Distribution Shock

Christian Lazopoulos describes the year as, “Search moved from winning clicks to earning inclusion in answers. Creators moved from content supply to distribution infrastructure. Commerce moved from conversion as an outcome to conversion as the environment”. I like the point it makes about understanding and responding to the ‘rules of distribution’.

I’ve been thinking about distribution a lot recently because it’s the background context for all our products. Our direct distribution strategy means students can only get our courses by coming to us. Our products are our only route to market, which means everything rides on them being rock solid.

What is so wicked about wicked problems?

Interesting dig into wicked problems. Policy and planning is often seen as the discipline for tackling wicked problems, and three years after I wrote this, whether product management can meaningfully tackle wicked problems is still an unanswered question for me. Maybe it’s because we think too small. Product management is about changing user behaviour to affect user outcomes and business objectives, not changing user behaviour to affect hugely complex social problems (although we do).

Marketing Management

Kotler and Keller’s marketing text book is on the references list for the marketing module of my MBA so I’m speed reading my way through it to understand brand architecture, marketing strategies, etc., etc. I studied marketing years ago so it’s not completely new concepts, but it’s made me think about the different concepts we use in product management and how baffling they must be to people who aren’t familiar.

I thought:

Maturity models are really distribution models

Better to think of maturity as shifting the distribution from where the majority are doing one thing and a few outliers are doing another, to where the majority is doing what the outliers are doing.

What is a product?

A coherent collection of choices about channels, journeys, policies, processes, teams, technologies and transactions that try to affect business objectives and user outcomes.

The product manager’s role in this definition is focused on coherence. It isn’t about coordinating the parts, it’s about making sure they make sense together and don’t conflict with each other.

Classical product management

“Classical” is a term used to refer to the first significant period of an area of study and the concepts and theories that informed it.

The classical period of product management starts in the post-world war 2 era with the Great Depression, Neil H. McElroy’s concept of Brand Men, the start of the information age/third industrial revolution/digital revolution in 1947 with the invention of the transistor, and against the backdrop of globalisation with it’s international trade. Product management was characterised by responsibility for a product-line, representing the customer, and being closely tied with sales and marketing. This was product management’s classical era.

Contemporary or modern product management, the era we find ourselves emerging into now, is shaped by the fourth industrial revolution and world events such as the 2008 global financial crisis, the climate crisis, the concentration of wealth, and global trade relationships. This kind of product management is built on very different concepts to classical product management. It is focused on data and technology because technology is more ubiquitous in society, which means concepts like networks and scale are important and the economics shift from production to distribution.

If I ever write a book it’ll probably be about this transition, about the big forces that are shaping product management, and what that means for how we do product management now.

I did:

Practicing acceptance

Lots of conversations this week about change, managing it and accepting it. Is circles of control a useful framing given how it places responsibility on individuals? Does systems change thinking help with its focus on finding levers? Who knows. Anyway, did this stuff too…

• Met another new junior product manager. We talked about opportunity assessment and all the work product managers do to understand if problems are worthwhile before they get to teams.
• Worked on my product topology. I added journeys (moving users from one state to another) and transactions (the value exchange mechanism). It’s looking a lot less static than epics and features and feels more suited to being service-led.
• Helped to think through a new piece of work that has lots of unknowns but bringing people with different perspectives and information made it a bit clearer.
• Tried out a different format for a roadmap for a complex product. It’s kind of dual-track times three so it shows operational, strategic and transformational layers.
• Started putting together a development plan for our junior product managers. I started with the SFIA framework but it didn’t really fit so made up my own.
• From my reflection from last week about designing structures that make it easier for people to behave the way you want them to, I started designing a way of describing responsibilities to encourage collaboration by having lots of overlap. Might write a blog post about it one day.

First assignment

Completed the first assignment for my MBA on schedule.

I read:

Visibility and communication is the job

“Proactive visibility and communication are how you build trust with your partners and leaders.” Yep, talking about the work is part of the work. And being good at the meta-work is as important as being good at doing the work.

Meta-work overdose

Aaron says, the “best way to describe meta-work is to define work term first”. I disagree. I think you should define and design the supporting system for the work before you do the work. I don’t always follow this myself, sometimes I’ll jump into writing up an idea before I think about how I’ll communicate it, who to, why they should care, etc., etc. What usually happens then is the idea stays in my notes because I don’t know what to do with it. Systematising the meta-work is next level.

Inside the playbook of companies winning with AI

This article basically says, the more you invest in something, the more successful it will be. It suggests companies using AI successful have Chief AI Officers, have robust governance in place, and have partnerships with expert organisations. It says a lot about how emotional and irrational companies are when the way to get traction for a new technology is to create hype. No one is hiring Chief Telephone Officers, that’s all I’m saying.

Conceptualizing 21st century sociotechnical work

Fascinating work on neo-sociotechnical systems theory that talks about how we need to understand work differently than we current do. We think of ‘the work’ as the outputs from with the containers (physical containers like buildings and conceptual containers like teams), but maybe a different way of thinking about work is as the interactions between individuals, technology systems, and organisations.

I thought:

Prioritisation

Prioritisation is comparative analysis. Which means there is a robust body of knowledge about different methodologies that product managers can learn from to get better at prioritisation.

Reza Azarian looks at the potentials and limitations of comparative methods including, “challenges with variable control, ensuring conceptual consistency, avoiding cultural bias, the difficulty of establishing clear cause-effect links in complex systems, time-consuming data collection, and the problem of having too few cases for complex theories (Too Few Cases, Too Many Variables).”

I like this guide to comparative analysis in writing from Harvard because it describes three types of comparison that product managers should know:

• Coordinate (A ↔ B): Considering two or more pieces of work using the same criteria for all to choose between them. This is how we usually think of prioritisation. It’s what common frameworks like RICE are based on, which is why it’s important for product managers to understand the theory behind the frameworks and the limitations.
• Subordinate (A → B, C, etc): Considering two or more pieces of work using the different criteria for each to choose which best meets a goal, fits a strategy, etc. This approach is particularly useful if a product manager wants to, for example, improve user satisfaction scores as then they will only compare work that might do that.
• Hybrid [A → (B ↔ C)]: Considering two or more pieces of work using the different criteria for each to choose which best meets a goal, fits a strategy, etc., and then considering the work using the same criteria for all to choose between them. This way works like an initial filter to ensure the right work gets compared and helps to explain why the work should be done.

As with most things, the more you look the more you see.

No menu

Maybe the test of good online journey design is that users can get to where they need to be without using the website menu. I’d love to split test an entire website designs, one with a traditional menu based on the idea that users should be able to get to every page, and the other with focused journeys that only present what the user should see at each step of the journey.

I did:

The multi-inheritance problem

This has been on my mind this week: “Multi-inheritance raises questions about which goals, values, and standards are taken into account and introduces the possibility of systems changing the goals, purposes, or standards of the organization. Under these premises facilitating the creation and improvement of sociotechnical systems is not a matter of optimization and resolution, but of supporting the ongoing negotiation of goals and actions.” (Winters, et al. 2014). And I did this stuff too:

• Had a great intro chat with one of our junior product managers. We talked about product manager behaviours such as planning ahead and taking initiative.
• Went a feedback session on our new strategy.
• More interviews.
• Facilitated another retro, doing another two next week. I’m pretty much Mr. Retro at this point.
• Chatted about the difference between working in the organisation and working on the organisation, and who’s responsible for which.
• Started talking about the idea of a ‘principles and practices group’ of cross-functional experts who can coach teams on agile, stakeholder engagement, analytics and evidence-backed decision-making, etc.
• Venkat Iyer talked at our community product of practice. He’s brilliant!

The numbers

Number of minutes in meetings: 1640. Beats my previous record of 1590.

Number of tasks completed: 51. Back up to an average of 10 a day.

I read:

Digital transformation is about making organisations machine-readable

I really like Adrian Ortega’s definition of digital:

“Digital as the condition in which the world is rendered into discrete, transmissible units of information, enabling systems — human, organisational, and technical — to sense, interpret, and act across distance and time. (…) As a working definition, this means organising our work, services, and systems around information that can be sensed, shared, and adapted in real time. (…)

Digital transformation then means reshaping how an organisation learns, decides, and delivers by using data, design, and technology to respond to real needs. It’s about replacing static, hierarchical processes with adaptive systems that sense what’s happening, make sense of it, and act quickly to improve services and outcomes.”

It fits nicely with definition of digital transformation: converting organisational structures and business logic into a machine-readable format.

What Sam Altman just taught us about OKRs without meaning to

“OKRs are what you push. Health Metrics are what you protect. Knowing the difference might save your company.”

Small acts of maintenance

“I’ve been thinking about the things we fail to maintain, because maintenance is slow, boring work that’s easy to put off. We’re drawn to new projects, new strategies, new tools — things that promise progress. Meanwhile, the things our teams and organisations rely on age and decay, becoming harder to use or understand.”

I thought about:

I’ve been working on the first assignment for my MBA this week so most of my thoughts are about analysing organisational culture.

Structures and behaviours

If we want people to show behaviours like collaboration, but we structure teams in ways that keep people apart and use things like RACI to tell people they are singularly responsible for something, we shouldn’t be surprised when the structure beats the behaviours. I wonder how we might redesign RACI to bring people together rather than push them apart.

Insights from retros

I’ve done a lot of retros lately, and one day I’ll do some kind of meta-analysis on them, but my initial observations are that things go wrong when we treat wicked learning environments as kind learning environments. That means, when we expect things to be predictable and controllable, and fail to realise that things are actually uncertain, ambiguous and constantly changing, then we aren’t going to be able to respond effectively.

I did:

People time

Someone once said that a lead product manager’s job is more about people than products. This I agree with. And it guides how I approach my work. Of my 2,400 working minutes this week I spent 1,110 of them with people (46.25%). Some of those minutes were spent on this stuff:

• Lots of interviews. And lots more to go.
• Ran the second part of a workshop to help figure out what product managers and delivery managers do.
• Talked to some stakeholders about planning a retro.
• Did some planning for stakeholder engagement over the next few months.
• Started working on a presentation about one of our products as part of improving how we communicate with stakeholders.
• Started working on some ideas for training, which made me think about Carse’s thing about training is ‘being prepared against surprise’ and education is ‘being to prepared for surprise’.
• Talked about incident management for product teams with build-run-own responsibility.

I read:

Think big, act small

I’m a big believer in the sentiment behind the phrase, “Think big, start small, learn fast”, but I wanted to know where it came from to better understand how applicable the ideas are now. The best source of thinking I can find is Jason Jenning’s book Thing big, act small: How America’s Best Performing Companies Keep The Start-up Spirit Alive.

Jenning and his team analysed companies which had grown revenues and profits by ten percent or more, for at least ten consecutive years, not counting acquisitions. Then they met with the CEOs, leaders, managers, workers, customers, vendors and suppliers of each company to try and identify what they were doing right that almost every other company was not. From that, they created a list of the ten building blocks of think big, act small business management:

1. Always be humble and down to earth.
2. Keep getting your hands dirty on the details of your business.
3. Set short-term goals but have a long-term horizon.
4. Let go of obsolete products, services and processes.
5. Have everyone thinking and acting like an owner.
6. Invent and reinvent your business as often as required.
7. Be committed to the creation of win-win customer solutions
8. Deliberately choose the competitors you go up against.
9. Build and grow your community of workers, customers & fans.
10. Rely on homegrown leadership rather than miracle-workers.

This is my analysis of the four combinations of thinking and acting:

Think big	This is the realm of massive scale waterfall projects. It has it’s place if you’re building a railway or a bridge, but too often orgs that aren’t doing that kind of work think and act as if they are.	This is where large orgs should want to be. They have the scale and scope to aim for significant impact, but to make progress towards that they use methods for acting small which brings other potential benefits such as increasing the pace of learning.
Think small	This is where large & complex orgs usually end up. The focus is on marginal gains but achieving anything is difficult because of so many interconnected and dependent teams, systems, goals and processes. It’s an STS nightmare that needs decoupling to move towards thinking big and acting small.	This is the right place for small orgs but for large orgs its really inefficient because of the admin overhead and really ineffective because those small acts done in isolation never achieve compounding benefits.
	Act big	Act small

Taking Jaggedness Seriously

Because the way AI works is nothing like how humans learn and think.

I thought about:

On-demand work

I’m wondering how much the on-demand economy is affecting how we think about managing work and people within organisations.

Frenken et al. (2015) define as the on-demand economy as 1) temporary access to underutilised assets between consumers, 2) conducting an auction or a contest in order to receive a service, and 3) a business-to-consumer relationship.

If we apply this definition to how people are assigned work within an organisation we might see:

• Temporary access to underutilised assets (I’ll leave you to decide whether you’re underutilised… or an asset) describes how someone from one team who isn’t already too busy, goes to work on a project. This is basically the process of forming cross-functional teams from functional areas for a given period of time, knowing that team will disband in the future and the people join other teams.
• Conducting an auction or a contest describes how which people are chosen for which teams and projects. If team member’s experience and reputation is used to make decisions about what they work on, and leaders make these choices by negotiating with other leaders, then they are essentially auctioning a team member to the highest bidder, but rather than bidding money they are bidding with organisational priorities.
• A business-to-consumer relationship is easy to explain in this context because the worker’s contractual and financial relationship is with the organisation, not with any individual within it. Even though a worker might be

So, on-demand economy practices are already happening in organisations, they just aren’t formalised into an economic model or technology platform. But it’s coming. Given that we know how awful matrix management is, we might think applying the logic of the on-demand economy is a better way of managing the assignment of work to cross-functional teams. But we also know that many on-demand business models are horribly exploitative, so if organisations head in this direction even more (and I think they will), they should think carefully about how such a model and it’s economics can be designed ethically.

Team undysfunction

The more time a group of people spends together, the less dysfunctional they become. Any group of people trying to achieve something who don’t spend time together will become more dysfunctional over time as their individual agendas drift away from the group agenda.

This is why people miss the point about meetings. Meetings aren’t about making effective decisions, they are social events that build relationships and reduce team dysfunction.

Why be a product manager

I think all product management happens in wicked learning environments, which makes it really interesting, but social impact product management tackles wicked problems in wicked learning environments. So if you’re looking for a challenge, this is where it’s at.

I did:

Triolity

My realisation this week is about how much easier it is to move forwards when the options available are greater than two and less than lots. Only two options, ideas, opinions, gets into a win/lose argument that doesn’t seem to happen as much when there are three options.

• Got feedback on some big bets I’ve been thinking about but not the feedback I was looking for, which helped me reflect on my expectations.
• Worked on how we assess opportunities, align them with our strategy, check the assumptions it’s based on, etc.
• Went to a DevSecOps workshop, which was mostly about the developer practices side but gave me plenty to think about on how the principles apply to all roles and look for opportunities for product managers to support it.
• Wrote my analysis and recommendations from a retro. It still amazes me how applicable good practices like retros and stand ups are to any level in an organisation, from individuals to teams to leadership of large cross-functional initiatives.
• Chatted about solutionism and how problemism is almost never the right response.
• Talked about the different perspectives product managers and delivery managers bring, which when joined by a tech perspective create the right kind of space for discussion. It has to be three people because two tend to get into arguing two sides.
• Said goodbye to a couple of colleague, one who I’ve worked with for a year and another who’s been with us for an amazing twenty one years. They’ll be missed.

I read:

A Very Short, Fairly Interesting and Reasonably Cheap Book about Qualitative Research

Some stuff we should all know about qualitative research

Every organisation has some madness

They certainly do. And I analysed Kathrine’s blog post for my assignment on the future of work and how Bauman’s idea of liquid modernity underpins digital transformation, saying that work is becoming increasingly continuous because there is no end state to reach.

Beyond the organizational ‘container’: Conceptualizing 21st century sociotechnical work

I’ve long had a problem with organisations drawing boxes around things (teams, groups, products, etc.) and this paper helps me understand why. The old idea of work happening in containers (physical containers like offices and conceptual containers like teams, groups, products) needs to be replaced with conceptualizing work as a practice, especially based on modern information systems and networks. The boxes we draw become meaningless when anyone can talk to anyone, information is available in an instant, and work happens virtually.

Time to put MVP to rest

MVP, PoC, pilot… all terms that have lost their meaning. Versioning is a much better approach. It’s much easier to explain what is included in a version and what’s changed since the last version.

Product Tank Leeds

Excellent write-up from Simon Wilson on the November Product Tank Leeds meet-up. Lots of really good insights and takeaways.

Everything I Got Wrong About Product (So You Don’t Have To)

Too late, already made many of these mistakes myself.

“Value is unknowable upfront” – Yep, that’s why business cases and return on investment should be treated as hypotheses not promises. As product managers we can try to change user behaviour in ways that benefits the organisation, but we can’t force people so we can never predict that the changes we make will lead to value.

“The biggest risk isn’t slow delivery, it’s being wrong at scale” – Whenever anyone uses the word ‘risk’ I always ask myself, risk to what? In this case, I think the risk is to the amount of value exchanged between user and organisation. Deliver slower and that value exchange is reduced. Solve the wrong problem and the value exchange is non-existent. So, more often than not the speed of delivery is mistaken for the greater risk, and usually because of human bias rather than intentional misfocus, because the speed of delivery is now and value exchange is someone else’s problem in the future.

“Behaviour tells the truth; everything else is noise” – User behaviour is the only thing that tells us if we solved the right problems and made value knowable.

From industrial to internet mindset

This was quite a timely read from Ben Holliday because I’ve been thinking about ‘the shift’. I don’t really like the product to service framing because it’s a bigger, wider and deeper change than just that (plus power and politics); it’s the fourth industrial revolution, that’s what’s going on here. So, building on some ideas from last year about what the shift looks like for teams, here’s my thought what it looks like at an organisational level.

	Industrial era	Internet era
Social political driver for change	The Great Depression (1930’s)	Global Financial Collapse (2007-8).
Organisational approach to change	Think of working practices and processes as definable and fixed, e.g., the production line where every task is known and performed in the same standardised way.	Think of working practices and processes as unfixed, fluid and adaptable (after Tsoukas and Chia, 2002).
Organisational approach to management	Traditional management is rational and unitarist. It is about prescriptively controlling tasks.	Contemporary management is progressive and pluralist. It is a relational, reflexive and ethical activity.
Management methods	Managing what people do with their hands. Defining and measuring the work of individuals, and punishing variance. Management by objectives is the main control mechanism.	Managing what people do with their minds. Coaching and supporting people to promote individualism and entrepreneurialism. Enabling greater autonomy and removing the manager as a decision-making bottleneck. Self-regulation (Foucault) is the desired control mechanism.
Conceptualisation of work	Traditionally, organisations were conceptualised as contained spaces in which people went to work, such as factories or offices – metaphorically, work was thought of as needing to be done in containers (Winter et al., 2014). We still see this thinking in how leaders ‘draw boxes’ around types of work, teams, functions, etc, to define the organisation.	Contemporary organisation (or organising) is increasingly understood to be something that is done – a practice, rather than a contained space (Winter et al., 2014). Such flexible and mobile ways of organising arguably fit better with a new and different metaphor: fluidity.
Arrangement of organisational functions	Functional silos driven by the need to group similar types of work together.	Cross-functional teams, enabled by modern communication and networking technologies.
Systems worldview	Deterministic	Emergent

I thought:

Build better systems

I used to own the domain name buildbetter.systems because I like the phrase but never knew what to do with it.

Recently, I’ve started using “build better systems” to refer to the systems teams use to organise themselves and their work, and designing them more intentionally. I’ve also called this, ‘Every team needs…’ …somewhere to store information, …to meet regularly, …to communicate, etc., etc. Build better systems takes these needs and provides ways of meeting them. It means a team intentionally figuring out how everyone on the team communicates, what are the expectations and rituals, which channels are used, how often should communication happen, what gets communicated formally or informally, etc.

This is going on my ‘if I ever have time’ list as it could be a pretty cool website.

Pluralistic strategy

I used to be pretty certain that you could tell a good strategy by looking for contradictions and conflicts within. My go-to example is a friend who invested lots in a new kitchen for his cafe and then put vending machines in. He thought he was giving his customers choice but in fact he was taking them away from the high value cooked food. There’s a contradiction in that strategy.

Now, I’m not so sure. I’m wondering how much tension should be built into a product strategy to allow it to respond to changing circumstances. In the café example, what if the chef is off ill? At least customers can still purchase from the vending machine.

Compound interest

Small habits repeated regularly build over time into something amazing in a way that big things done once don’t.

Be more cow

I once knew a diary farmer. He told me that a cow will always run just fast enough to not get caught. The faster you run, the faster the cow runs. If you slow down, the cow slows down but only by enough that it’s still ahead of you. There’s an interesting strategy analogy there.

• Stand still. The market will leave you behind but it’s an option.
• Run slowly and get left behind eventually. This is unfortunately what some organisations unknowingly choose. They put in just enough effort to look like they are trying but nothing moves the needle.
• Run just fast enough to keep up with the market. This is a resource-efficient strategy as you can speed up or slow down as the market changes.
• Run ahead, wait for the market to catch up. Risky because the market might go a different way.

So, given the economic times we live, probably be more cow.