Month: November 2024

I did:

Meta-work

This week felt pretty fast. Lots going on that needs to happen sequentially at pace to prevent other things from becoming blocked. And Christmas is getting closer.

• Chatted about our OKRs, how we set them and how they prioritise the team’s work, even if the team isn’t always aware of it. What gets internalised (and accepted as a given) and what gets externalised (and stated explicitly) is really interesting and connects to cognitive load, I think.
• Had a great coaching session. I was really impressed with their degree of connected thinking across different domains and appreciation of the implications from a change in one domain. It got me thinking about how tools like roadmaps are representations of product manager’s critical thinking.
• Was reminded that complex systems that work always evolve from simple systems that worked. It’s one of underlying principles of modern product teams that gives us prototyping, iteration and the like. Upfront design of the perfect end state is risky and costly.
• Talked a lot about simplifying things to reduce cognitive load, and tried to practice it by writing things clearly for people.
• Went to n levels of inception to do some glue work for those doing the glue work for those doing the work.

Championing user needs

Wrote about how product managers can approach championing user needs. Not my best work but at least it gets the ideas out of my head.

I read:

Design Thinking for Change

Samantha talks about Design Thinking as having a focus on discovery and definition and needing to work with other methodologies such as Agile and Lean which focus on delivery. I’m really interested in how we get different methods to work together coherently. I think that offers more value to teams than creating new methods and frameworks. We need to learn from what we know about the downsides of handovers between teams (information loss) and apply it to methodologies.

Centre of expertise

I read a paper about how organisations should be designed for optimising the expertise of knowledge workers. It’s a tough challenge but one I think creates a competitive advantage for organisations. For sure, there’s more to the answer than just writing more stuff done as we know most knowledge is tacit so can’t be written down and even when it is there’s a large percentage of information loss. It’s interesting to think about designing an organisation around knowledge management rather than thinking the solution is a tech system.

Middle-Out: Turning Strategy into Action with the Decision Stack

Jonny Schneider says, “The power of the Decision Stack isn’t in being comprehensive—it’s in being clear. While the top half (vision, strategy, objectives) typically remains stable over months or years, the bottom half (objectives, metrics, initiatives) evolves rapidly through learning and execution. This isn’t oversimplification. It’s about distilling complexity into actionable clarity. Teams still go deep in ways that suit them best, but the Decision Stack becomes the one artefact that consistently motivates aligned action.”

Not being sure

I like Debbie Blanchard’s definition of product management as being about taking on the uncertainty, listening to the experts, and placing the bets.

Mess mapping

I thought about:

Organisational self-image explains organisational culture

I have a theory about organisational culture counter to dominant idea that culture is made up of the collective behaviours of individuals. I think “organisational self-image” explains culture better. Self-image is a mental picture that is generally quite resistant to change.

If the organisation makes takeaway pizzas, the culture probably prizes speed and low-cost efficiency. If you work in a bank and regard banks as careful, reliable, and steady, that’s the kind of culture you’ll have. If you work in a university and assume universities last for a long time and that academic consensus arises dialectically, then you’ll have a culture with no urgency and lots of discussion. How everyone “sees” the organisation is how the organisational culture manifests.

So, if you want to change the culture, change the mental image people have of where they work.

Brooks’ Law

Brooks’ law is an observation about software project management that “Adding manpower to a late software project makes it later.” The reason is that more people requires more coordination which means each person spends an increasing percentage of their time not working. It’s often expressed with a diagram showing an increasing number of points and how the number of connecting lines between the dots increases exponentially, but gets misunderstood as communication, rather than coordination. Coordination doesn’t require the same amount of time for everyone, that’s why coordinating roles like project manager and organisational structures like hierarchies exist, to reduce the coordination effort for some people.

Now, I’m not saying Brooks was wrong, I’m pretty certain he was and still is correct. But I am saying that confusing communication and coordination also slows down teams. Both are necessary, but not always to the same degree for everyone at the same time. Being intentional about coordination, communication, collaboration, etc., makes a big difference to how people spend their time.

Talking is competitive advantage

The more people talk to each other, the more knowledge is shared. And in modern knowledge work, sharing knowledge is a competitive advantage.

Uncertain outcomes

When thinking about the outcomes and impact of product work, there are two boxes you can put the work: ‘Most likely won’t succeed, and ‘Might succeed’. There is no box called, ‘Will definitely succeed’.

I did:

You are not the user

But you do your best to represent them and do what you think is right for them. Sometimes (including this week) that can seem quite abstract and doesn’t always work out how you’d like. There was other stuff too:

• Reviewed the financial data for a new business case. Because it’s new and unvalidated it goes in the low confidence pile, so the next question is how to approach validating it to increase confidence in it’s value.
• Chatted to more product people from other teams. It’s so interesting finding out about what people do, what they think about things, how they got where they are. Everyone should do it.
• Argued with Information Security about phishing your colleagues being ineffective for improving security awareness and that induction training would be better.
• Attended our Digital Service’s all-staff meeting. Emma, our CDIO, talked about our priorities for the near future and how we’ll need to change policy, people, process, technology, etc., you know, product management stuff.
• Got some of the people and process stuff in place for a large piece of work we’re starting. My reflection is that I/we could have done better at coordinating what to do and by who to reduce the uncertainty.
• Wrote requirements. It was fun, like being a junior product manager again.

I read:

Everyone wins when product managers work in the open

Really nice post from Isabelle Andrews about working in the open as a product manager. I really like the point, “Putting information out there and being understood are quite different things.” And focusing on why we’re working in the open and not on the performance of it.

Is product management a profession or trade?

This interesting question was posed by John about futures, but it applies to product management too. John describes the difference between a profession and trade in terms of pacing layers and speed of change. “Professions are traditionally in the slower layers; governance, culture, etc., whereas ‘trades’ react to fashion and commerce signals and trends to constantly evolve.” I think this firmly places product management in the trades layer and maybe shows some of the confusion from trying to treat it as a profession.

Hi

Every so often, this nonsense about how people should use chat messages comes up on social media. Usually the justification is to not interrupt others, but this is the first time I’ve seen anxiety used as an excuse for telling people they should communicate in ways that meet your needs not theirs. I think people should feel comfortable to communicate however works for them. If it doesn’t work for you, talk to them about it.

How Complex Systems Fail

I’ve read Dr. Richard Cook’s work before but this is cool website presents his short treatise on the nature of failure. There’s lots to learn there, especially about how all complex systems are inherently hazardous but run a degraded mode. I’m interested in how/whether an organisation tips over from being a complicated system to being complex and how it affects the orgs ability to function effectively.

I thought about:

Small simple steps

Following on from last week and reading about how to lead in a VUCA world (do more planning more frequently to get better at responding to change), I’ve been experimenting with writing short, simple, step-by-step plans after meetings which:

• Say who is doing what by when.
• Have the next three to five steps.
• Are easy to let go of when something changes.

I guess the thing here is that although the work is novel for this group of people in this situation, which means it can’t be planned upfront, that doesn’t mean that planning is useless.

And so far, I’ve seen a few little glimmers of more clarity and alignment, so I’m going to carry on doing it.

Principles

More thinking about the decision stack (I should probably bring all these thoughts together into a single blog post). This week, how having principles in the stack places it in a deontological moral philosophy space. Whereas an outcome focus feels more utilitarian, that the ends justify the means, a principles focus is more about having guiding boundaries that you don’t cross.

The decision stack places principles at the bottom, almost like a foundation that everything above sits on, and it includes the ‘No’ zones either side of the other layers, both of which make it feel like it comes from a deontological standpoint. How product manager’s deal with the interplay of those utilitarian and deontological positions is part of the fun.

The future of product management

I’ve seen a few posts about the future of product management recently, and they all seem to be about whether product manager’s use AI or not. That is not the future of product management. The future of product management will have to be about redefining success beyond the assumptions of infinite growth. The current state of the global economy and global climate change are hard stops we can’t ignore. Our vision for the future of product management has to take these harsh realities into account. We can’t carry on basing our profession on the assumptions of Schumpeter and Friedman. It’s time to move on and create something better.