Am I an unProduct person?

Roger on 19/05/2024

Jukesie wrote The unProduct Person, which poses some interesting questions about the current state of product management and its focus on frameworks. It made me think a bit more deeply about what I think about some of those points.

I think the need for people to ‘professionalise’ the craft of product management, to make it a definable thing, to demonstrate how important it is and how ‘scientific’ it is has been to its detriment. 

The discipline/function/profession of product management is still very new/emerging, it doesn’t have regulations to pin it down like finance does, it has been at the forefront of the internet-era disruption/transformation (along with lots of other roles), and it works with intangible things in messy spaces. These four factors (along with many more, I’m sure) make for shaky ground to grow in. But I’m ok with that. I think the answer is to get better at dealing with uncertainty, not go looking for certainty. So, I think I agree about not needing to ‘professionalise’ (whatever that might mean) product management any time soon. More time for emergence required.

Personally, I definitely identify with using a certain way of thinking to approach certain types of problems more than I identify with the job title and ‘more professionalism’ isn’t going to change that.

To me, product management is fundamentally a scientific pursuit. It uses the scientific method in an organisational context. I think the future of product management is in using more systems-thinking approaches rooted in synthesis and how things connect in complex systems, but for now we are where we are, so the scientific method with it’s reductive analysis is good enough.

OKRs are one of the big faultlines for me. While I don’t intrinsically think they are a bad thing – and there is definitely evidence they have been successful and useful places – I just don’t believe the juice is worth the squeeze in the vast majority of cases

I agree that the OKR juice isn’t worth the squeeze. It’s easy to spend more time and effort aligning the OKRs than OKRs provide alignment for teams. This isn’t OKR’s fault – it’s bureaucracy and hierarchy’s fault.

The pursuit of excellence in and mastery of the growing number of frameworks and models for product people seems to have overwhelmed the more foundational principles of product practice.

Another thing I agree with. A focus on frameworks does get in the way of understanding and applying the foundations of product practice. I’ve seen it happen. But maybe you can only see it from Ri. If you’re at Shu, then you have to learn the rules before you can break them, and that means learning frameworks. So the best thing a person at Ri can do is help those at Shu to learn and practice and progress as quickly as possible. Get the reps in.

Being focused on delivering valuable outcomes, articulating and holding tight to a vision, owning the hard decisions/trade-offs in pursuit of that vision, being the ‘glue’ to help teams achieve…and doing all of this by influencing without authority. It is a facilitation and influencing role

This is a yes and no for me. Yes, because those things are what product managers have to do, no, because the only reason they have to do them is because of how organisations are set up, who has power, how information flows, etc. If organisations were different, product managers wouldn’t have to do those things. Product managers only have to do glue work because there are forces trying to pull people in different directions. Those things might not seem so foundational to the role if the organisation changed, which tells us they probably aren’t that foundational now.

I’d rather Product people learned more about policy and service design, data science, DevOps, programme management or data protection than attend another Product specific training course. I truly believe the path to making the most effective contribution possible is that of the path of the generalist. Breadth not depth. Empathy for many professions more than narrow expertise in one.

Definitely agree that product people should be generalists, and S-shaped too. Not only do they need a broad range of knowledge but they need to be curious and know how to learn quickly too.

So, there’s a lot I can agree with in Jukesie’s post, but does it make me an unProduct Person? I don’t think so. For me, “avoiding hierarchy and being flexible and open to new ideas and ways of operating” describes the Ri of product management (and I intentionally avoid using the word ‘maturity’ there because it’s infantalising and reinforces existing power structures). Ri is a good place to be. Hope I get there one day.

Weeknotes 407

Roger on 19/05/2024

This week I did:

Elucubrating

Some of the things I did at work:

  • Wrote up a quick primer on simple product strategies with three elements; a worthwhile problem to solve, a hypothesis about how to solve it, and a way know if the problem has been solved. I might turn it into a blog post one day.
  • Ran a team retro. I used the sailboat method to help the team clarify where they want to get to (the desert island), what’s dragging them back (the anchors) and what pushes them forward (the wind). I felt really proud of how the team owned the solutions they came up with to use what they’re good at (the wind) to overcome the things that make it hard for them (the anchors).
  • Spent some time trying to figure out the optimum meeting schedule so that everyone has enough understanding of the work and enough time to do the work. The scheduling I mapped would have a person spending 40% of their time in meetings, which is probably too much, even when the meetings are the work.
  • Met our marketing director and chatted about ambition and vision. I really appreciated the clarity around the team’s mission, and its scale and pace.
  • Chatted about how hard it is to find a fixed point to anchor a roadmap to and give the team some certainty when so much is in flux.
  • Presented our OKR’s. And got some feedback about ours being different to everyone else’s which I’m choosing to take as a positive.
  • Had an interesting discussion about whether understanding the language used in agile and user-centred design is a sign of digital maturity. My opinion is that there is nothing that can’t be explained in plain English that is better explained by jargon. Jargon isn’t a signal of maturity, it’s exclusionary, and we don’t have to leave anyone behind. I might be in the minority, but Einstein agrees. He said, “If you can’t explain it simply, you don’t understand it well enough.”

I sometimes don’t quite believe I get paid to do all this cool stuff, tackle complex problems and make things better for people.

Productivity

Completed 50 tasks.

Wrote 31 pages of notes.

Spoke to 37 people 83 times.

One of my annual goals is to speak to more people, and it’s going well. More by accident than design, but I don’t mind that. Looking forward to more chats with interesting people outside of work over the next few weeks.

The timeline of digital work

I’ve been adding influential management thinkers and their books to the timeline. It’s a bit annoying that I can’t find full dates for when the books were published so I have to set the dates as 1 Jan whatever the year. Obvious I guess for this kind of thing, but the hardest part is deciding what things to add from the past couple of years as we don’t know what affect they’ll have on modern work.

I read/listened/watched

Understanding continuous discovery

I’ve been listening to a few podcasts with Teresa Torres about continuous discovery, including this one from Aug 2021. More discovery to help product managers understanding worthwhile problems and get out of the project/delivery space is definitely on my mind for stuff we need to be doing so I want to start figuring out how it might work in our context sooner rather than later.

The microfoundations of lean leadership

This beautiful paper investigates the microfoundations of lean leadership using the Japanese philosophical concepts of Monozukuri (making things), Hitozukuri (developing people), and Kotozukuri (making things happen). It provides empirical evidence that lean should be seen as a human learning system and reinforces the Toyota perspective of ‘we make people before we make cars’. More of this type of leadership please.

Plan less, more often

“Planning, i.e. determining what to do, is useful – but this should be done with a strict focus on what is the simplest, useful thing that we could do next; or, what is the absolute minimum we should do next?”

How to show the ROI of your product work

And I thought:

Impact mapping

Thought a lot about impact mapping and measuring this week. Just happened to be wandering around Watford at midnight so could let my mind wander like in the good ol’ days. My thoughts went from systems thinking, fox and rabbits, measuring impact via indirect signals (e.g., an increase in the rabbit population might show a decrease in the fox population), to littering and how Keep Britain Tidy had to affect numerous systems (legal to make it against the law to drop litter, local authorities to get litter bins installed, social pressures and public perception to make it unacceptable to drop litter, etc.), to how system-shifting product managers might show impact as a contribution to big changes in society. Maybe one day this will all make sense.

Intelligent waiting

One of the hardest management lessons I had to learn (again and again) was not jumping in to provide answers. Before acting, pause to think about what you want to achieve, how you might best achieve it, what could go wrong, what’s the bigger picture, then act, or in many cases, don’t. It gets easier (and by that I mean more comfortable) with practice and by reminding myself that I’ve only learned the lessons I’ve learned because others didn’t jump in and give me the answers.

The purist and the pragmatist

Had a few conversations this week about tools and methods (OKRs, problem/solution tree, impact mapping) that have a purist perspective about how they should best be used, and a pragmatist perspective on how well they can actually be adopted. There’s a value equation there where getting a method adopted in a pragmatic way gives enough value without too much investment, and the extra investment to get to the purist state probably isn’t worth it. Product manager-y thing to say, I know, but it’s important to stay focused on what problem the method or tool is solving for you.