Product managers should straddle utopia and reality

This post was inspired by a conversation I had recently with Amir Hajizamani – thanks for the creative energy, man!

Product management is a hard job. Some of the reasons for this are mundane: long hours, lots of responsibility, isolation. But one big reason for why the job is difficult is not related to the execution factors (i.e. what you might call work/life balance), but rather the fundamental nature of the job itself: the need to live in two worlds simultaneously.

What are these two worlds? Simply put: reality, and utopia. Reality is the messy, suboptimal world of today, and utopia is the beautiful dream of the future – nirvana, heaven, the promised land. PMs must straddle these two worlds because someone needs to, in order to get the right things done.

This applies to many different aspects of the job. At the most obvious level, it is how you ship good products: having the vision to see the amazing experience you want to offer users, but then returning to earth to plot out the next step to get there from the swamp you currently inhabit. And repeating.

And this is tough! It's fun to dream and imagine a beautiful world, and it's fun in a different way to live in the present and get your hands dirty with the work needed to move things forward right now. But switching between these two states is jarring and mentally draining.

To contrast, let's look at how the PM straddle compares to some other roles in the team.

Developers live squarely in the messy world of the present. They might pop their heads over the fence occasionally to participate in some story mapping or put together an architectural vision, but the vast majority of their time is spent working with the current situation, making incremental changes that are immediately visible. You can see this in the workflow of a modern software team: they will make small commits that only change as little of the code as possible, in order to minimise risk. Yes, there might be a cathedral at the end of the process, but a developer is concerned about whether the single stone he has just pushed to master is sitting right.

Designers, on the other hand, live mostly in the world of the dream. They spent most of their time giving form to the vision, illuminating the way forward. Some of their work is in the messy present, understanding what about the current world is not working for users, but always with a view to how it affects the end goal.

To be clear, these are not complaints! It is necessary and good that developers and designers behave like this. My point is to identify one aspect of why the PM's job is difficult.

Time allocation

PMs also need to straddle utopia and reality when deciding how to allocate their time. This is best illustrated by first considering the two failure states that occur when they don't pull off this straddle.

One failure state is for the PM role to become what a friend of mine calls "defined by the negative spaces". That is, the PM takes on whatever tasks aren't being done. If the team has no user researcher, they'll do the research. No QA, they'll test and write bug reports. No designers, they'll create wireframes and mockups. Etc.

And this is not a failure in itself. One of the values of the PM role is in being the bard of the party – the second best X for all X. The danger comes when there is nothing beyond this, when the PM doesn't have any sense of what their role should be. Because ultimately, if a team lacks a QA person and finds that testing is important to their outcomes, they should hire one. Ditto if they lack a designer, user researcher, delivery/scrum master, etc. The PM can fill the gap if needed, but filling gaps is not why you have a PM on the team.

This is the failure state that happens when the PM lives solely in reality, with no foot in utopia.

The second failure state is the opposite: PMs who live entirely in utopia and don't deign to descend to the mortal plane.

Apologies to the person who wrote the original tweet, but it was such a good example I had to include it

These PMs will write stirring strategic memos, beautifully-crafted PRDs, and spend their days connecting with stakeholders about how to fit their product vision into that of the company... but not notice when output is stalled due to missing details about a specific feature. Or that the developers are spinning their wheels because the designs are late. Or that you have a buggy product because testing is too thin. Or or or.

The right pattern, again, is a PM with a foot in both camps. Someone who lives amongst the team, solves problems as they arise, and fills whatever gaps there are, but who also knows that the larger value they can create is on the strategic side. Someone who has a clear idea about how the PM role should be, and who is willing to work in the messy reality for now while taking steps towards the ideal.

In practice, this involves advocating for the creation of new roles to take tasks off your plate that aren't really part of your core responsibilities or expertise. And this is hard to do, since if you are filling those gaps in order to help the team create value, then the need to hire won't be obvious.

All of which is to say: your team is also a product you are working on. Just like with your actual product, you need to know where you want to reach and deal with where you really are today.

Key takeaway: as a PM, you are a child of two worlds. Celebrate and embrace this, but be aware of the toll it will take. Other PMs will understand – seek council and support from your peers. Good luck!