Product Managers are Band-Leaders

I’ve worked as Product Manager for a while now and in a variety of technology domains — and I wanted to start writing down some things I’ve noticed about the practice of Product Management. As such, I’m launching a blog space here to get some of these ideas organized and thought-through, since I find there’s a lot of confusion about a lot of areas relating to it — what’s the role; what is creativity; how do people best work together; etc.

To kick things off — in addition to having been a PM for a while now, in the past I also spent a lot of time in the world of music — as a Band-Leader for rock bands; a Musical Director for theatrical productions; a composer of music for advertising; and a host of other music direction-type roles. My conclusion from all this: there are huge areas of overlap between what the fundamentals of what Band-Leaders and Product Managers do.

On a high-level — both roles involve managing the tension between the push & pull of trying to create space for and celebrate the contributions and creativity of the members of the team while also essentially constraining the team so they remain focused on the goal they’ve come together to achieve.

In the spirit of over-simplifying things a bit for the purpose of highlighting some key points — both roles require:

1) Motivation: Organizing team members of differing skill-sets to ensure they’re “bought in” to care about working together collaboratively, functionally and creatively

In my experience, people by and large want to make meaningful contributions to whatever they’re working on — and the ring-leader’s job is to help nurture, respect and maintain this desire.

People who inhabit different functional roles contribute different things to a finished product — and so it makes sense that they would logically believe different elements of this final product to be of particularly critical importance. In my opinion, a key way to approach wrapping your head around this is to realize they’re more or less correct — their contributions really are critical, and as the hub of the creation flow the Band-Leader/Product Manager would be wise to show respect to their contributions on an ongoing basis.

As an example — to over-simplify it a bit, bassists connect to drummers in ways that tie the drums to the other rhythmic and the melodic elements of a song, which means the more fully engaged a bass player is, the more the song overall will have a grounded, “all the parts are coming together” kind of feel. Even if they don’t necessarily write their own part, they have to find a way to personally inhabit it when they’re playing it — which means bringing some part of themselves to the production process.

This applies to everyone in a band — all members contribute something that helps create the overall effect of the song. One of the Band-Leader’s jobs is to make sure each contribution is not only creating a desired impact, but that its contributor is also recognized for doing so. As with a Product Manager, a Band-Leader is not necessarily expected to match each band member’s expertise in their respective instrument or domain — that is, a bass player can probably be expected to know the most about the bass; a keyboardist should know the most about keyboards; and so on. Furthermore, an individual player may or may not be asked to write their own part; it all depends. However, the Band-Leader should be expected to recognize and celebrate the way each player contributes their personal efforts to the greater good.

I’ve been in many bands where we just ran through a song, and afterwards one member is excited about something new they just did in that run-through — but no one else noticed when it happened. That’s ok — everyone just pauses for a few moments to this person show what amazing thing they just did. Sometimes this new, amazing thing does make it into the final product; sometimes, it doesn’t — there should be good, well-considered reasons for whatever direction you end up going. However, it’s important to support this excitement and creativity. It’s a combination of personal and professional respect.

The notion that a team member’s contributions will be meaningfully considered is important –not as a manufactured technique in order to gain trust, but as a way of truly showing this team member can trust that the Band-Leader will mindfully be in the room with them when they’re being shown something that someone else really cares about and into which this person poured meaningful effort and attention.

To put it into the Product Manager context — developers, UX designers, data scientists, and the whole production team all believe (rightly) they are contributing critical elements to the process, and a Product Manager must not only understand and appreciate these contributions, but take time to celebrate the 1-to-1 connection between each individual’s contribution and the impact it has on the goal the team is trying to achieve. There are a lot of ways of doing this — for instance, not only bringing them in on key relevant decisions so they’ll feel their expertise is respected, but also getting out of the way and letting everyone do their domain-specific job when it’s time for them to do so.

This also means avoiding micromanagement. I recall many conversations with designers with whom I used to work who, after a big development push, expressed their appreciation that I essentially supporting their desire to meaningfully contribute to the work being done rather than making decisions about design and telling them what to churn out, as if they were a design mercenary rather than a, say, missionary, and be allowed to make personal and meaningful contributions to the work being done.

Some ideas will still end up on the proverbial cutting-room floor — some will be out of scope; some won’t fit the design; some don’t quite align with the goal we’re aiming for — lots of possibilities. The PM/Band-Leader will need to make these tough calls and make sure they do so for good reasons — which brings us to another thing that both Band-Leaders and Product Managers do:

2) Focus: Ensure everyone is aligned to achieve the same overarching goal.

With music, it’s usually pretty clear when the group isn’t all going in the same direction — things literally just sound off. In the general sense, every song is its own animal, with its own signature way of moving around, looking, sounding, and so on — and it’s the Band-Leader’s job to hold that overall feel/sound goal in mind and keep everyone aiming towards it, both in terms of the overall arrangement that gets put together, the parts that make up this arrangement, the recording of the song, performance of the song, and so on. The song/performance’s integrity is in their hands.

A technology product isn’t so different. It has specific goals it’s being created to achieve –for instance, to provide useful or meaningful functionality to a type of user/customer; to support other applications in a product line; etc. It’s the PM’s job to ensure everyone’s work stays aligned in the direction of supporting this goal and vision. Keeping eyes on the prize in both domains requires careful, daily assessing of what’s been done and prioritizing of what’s yet to be done to ensure it’s serving the eventual goal everyone is aiming for.

In either domain, this can be much trickier than it sounds. Often, new ideas come up that call into question the next few granular steps the team was planning to take. Whether it’s discovering a new, problematic edge case or the realization that a part of the song isn’t quite gelling the way you had imagined it would, you can rely on many things not quite working the way you’d envisioned as you move through the process.

Hence, Band-Leaders and Product Managers alike need to have a toolbox filled with problem-solving techniques that help them stay focused on the larger goal while they get down in the weeds to solve the seemingly never-ending litany of complexities that will invariably develop. We’re talking about delving extremely deeply into the minutiae of the trickiness, while also retaining the willingness to zoom back out and see multiple simultaneous levels of scale to try to develop solutions to any given problem.

I find it can be wise for Product Managers and Band-Leaders to think problems through on their own before bringing them to the team — I think you want to have a clear view of possible solutions that still support the overall goal you’re trying to achieve. That said, I think it’s also wise to have some possible solutions just to show examples of how the problem could be solved in order to get from point A to B — to spur conversation, in the hopes that the team might collaboratively come together to develop an even better solution. Which is to say — probably wise to not fall in love with your own solutions; collaboration is all about picking the best solution for a problem, not picking your solution since you are the decider. It’s the flip-side of asking people to care about what they’re doing — they’re also going to care about how problems are solved.

Conclusion, for now

Of course, this run-down assumes you’re collaboratively focused. I personally love collaborating with folks when I work, be it in a musical or technological context. To me, collaboration, appropriately applied, lets everyone learn from one another while bringing their own strengths to the surface, which not only makes things more fun, but it helps your team play a better song. As it were.

I recognize there’s a lot more that could be said here — I’m just scratching the surface, but hope to think through some more sides of this soon. What’s more, I’m interested in hearing your thoughts on the subject, so please feel free to leave comments if you are so inclined. Thanks for reading!