Month: September 2024

This week I did:

Processin’

If there’s a theme this week then it’s probably ‘process’. Where it’s helpful and where it isn’t, how it becomes the territory rather than the map, how it might help us reveal assumptions.

• Joined a big session on what the long-term direction of travel for our department looks like. The main message I took away (which I love, by the way) is that the future is not set, it’s emergent, there is no plan, we are changing the way we change.
• Had a really good session with some clever analysts about matching investment to income and only being responsible for the objectives you can directly affect. I’m in two minds. If everyone focuses on their little bit, who’s responsible for the big important stuff?
• Switched between being patient, and giving the processes time to work through things, to being proactive in finding ways around them. I’m always cautious about this because if everyone does it then there’s no process and all the chaos that ensues, but sometimes it’s the only way to make things happen.
• Thought about planning a lot. At two opposite ends of spectrum, I tried to list all the individual tasks it will take to complete a piece of work, and I started plotting big things on a long time line.
• Submitted our business case for a new piece of work. Actually, that makes it sound more grand than it is. We put together a one-pager for where we see some opportunities to start conversations with leadership. It’s so much cooler to be able to talk about things than process for process’ sake.
• Reviewed my task tracking data and could see the reduction in how focused I am on delivery, which is great because I don’t think that’s where I should be focused. I’d much rather be focused on future opportunities and the product scaling work.

Wrestling with WordPress

A butterfly broke my database. Well, there’s probably more to it than that. Last week’s weeknotes would have had a butterfly emoji but when I tried to publish the post it caused a database error. My host tried really hard to help but couldn’t figure it out. After slowly picking apart the problem I posted my weeknotes without a butterfly.

Blame culture isn’t what I used to think it is

Wrote a short blog post about blame culture and how the opposite isn’t a culture of accepting mistakes, it’s a culture of accepting responsibility.

MBAybe not

Looks like I submitted my application too late to start an MBA this autumn. I’ll try again in the spring. It’s made me think about what small courses I could do over the next few months instead.

I read/watched:

Shaped by demand: the power of fluid teams

This is a very cool way to work. I love the idea of stakeholders pitching teams about what to on. It’s a complete shift in power dynamic. I can just imagine all the organisational antibodies going into overdrive.

Assessing the impact of your bets

Daniel Schmidt posted about a metrics tree. It’s interesting to me because I’ve been thinking about the ontology behind product metrics. Last week I was thinking that understanding product performance might be better approached from a constructivist ontology where we accept that it’s impossible to get to an objective truth about the reality of the product. Instead, we want to understand how individuals construct their experience of the product.

Abandoning traditional appraisal process

This HBR article says, “But the biggest limitation of annual reviews—and, we have observed, the main reason more and more companies are dropping them—is this: With their heavy emphasis on financial rewards and punishments and their end-of-year structure, they hold people accountable for past behavior at the expense of improving current performance and grooming talent for the future, both of which are critical for organizations’ long-term survival. In contrast, regular conversations about performance and development change the focus to building the workforce your organization needs to be competitive both today and years from now.” And I think, the team is the best place for those conversations.

I thought:

Insidious scrum assumptions

Even if a team isn’t using scrum, the assumptions scrum has instilled in modern agile digital ways of working are always hanging around like a bad smell, and it bothers me. Product managers having a full backlog to keep developers busy is one of those smells. I can see where it comes from. The assumptions that coordination of work and people is the role of a single individual, that the team will sit around doing nothing if not told what to do, that important things will be forgotten. What if the team faces challenges where those assumptions are more harmful than helpful? What if the team is working on lots of different things (not the same thing as scrum assumes) that have different and changing priorities? Then, the idea of a single coordinator and a single source of truth for priorities becomes a blocker. Much better (I think) for the team to adopt self-organising behaviours of talking to each to check they’re working on the right things.

Impact

Decided I’m not overly keen on the word impact. It’s what you get when you smash things together. I’d like gentler term, one that implies considered and intentional effects, but I don’t want we have a single word for that.

This week I did:

Obstreperous

This week has been a lesson in influencing in emergent environments. Like the butterfly flapping it’s wings and causing a hurricane, you never know what your conversations are going to lead to. Be the butterfly.

• Kicked off four new pieces of work and handed over delivery. The team made a lot of progress in a week.
• Chatted about how the way we the define product management swings between the tech delivery focused product owner idea of a product manager and the business risk focused product manager idea, which can be confusing but also useful if you know how to leverage both roles.
• Talked about team health metrics and when they are and aren’t useful. Working with some great analysts on other things has changed my thinking on what’s usefully and reliably measurable.
• Pondered how to tackle one of those messy socio-technical problems that is an unclear mix of people, process, and technology.
• Started thinking about my personal objectives. You know how I feel about personal objectives, but sometimes you just gotta do what you gotta do.
• Realised I haven’t done a very good job of explaining what I do or how I do it as a product manager. I think a few people expect me work like a scrum product owner and spend my time on the backlog of features, when actually I’m more interested in uncovering and tackling the problems that will prevent us from scaling. So, I started playing with a few diagrams to try to help me explain.

I read:

Weeknoters

Benji Stanton – kinda on the theme of why being a generalist is a good thing.

Frankie Roberto – on the product metrics and dashboard questions.

Giles Turnbull – interesting to think about the role of translation in communication.

John Fitzgerald – good to see AI is still in the digital mix for charities.

Matt Ballantine – love the point about user needs of inanimate objects.

Oliver Hannan – I remember those pressures to get work lined up for developers. Agile, right?

Owen J – makes an interesting point about how the few can be at the leading edge of new knowledge whilst the majority still have old knowledge.

I thought about:

Ontology

I was wandering through the woods thinking about ontology and epistemology, as you do, and had a couple of realisations. First, I think user research uses a constructivist ontology, so rather than trying to reveal an objective reality, it seeks to show how people create and interpret their own reality. But I’ve never heard user researchers talk about this (except this guy) or cover an ontological position in a research report. Second, product attribution models usually take a positivist ontological stance, assuming there is a single objective truth to be revealed and show how this feature lead to that increase in metrics. But, given that product work is about affecting user behaviour, and an outcome is a change in user behaviour, wouldn’t a constructivist ontology make more sense?

FUVV

The question was posed of how our day-to-day work fits into tackling the four big risks of feasibility, usability, viability and value. It’s an interesting question. How should I go about answering it? Probably need a framework or at least a rational approach, right, after all I am a product manager. I could use an inductive reasoning approach and categorise all my daily tasks by the four big risks (luckily for me I’ve tracked all my tasks since day one) and see what percentage of activities I do for each risk. Or I could apply deductive reasoning to break down the four big risks into the kinds of things that fit and then put my daily tasks into those smaller buckets. As usual, figuring out the why and the how is most interesting than actually doing the thing. Maybe that’s the product-y insight.

Quit or continue

Thought a bit about how ‘quit or continue’ thresholds might be useful for OKR’s. On their own, Key Results only tell us what’s happening, not what to do about it. If x measure is increasing from y to z, should we continue to work on that objective or is that increase enough for us to stop, or has the increase been too slow? Maybe the Key Result needs to be something like, If x measure increases from y to z in 4 weeks continue, otherwise quit.