I enjoyed David Pereira’s breakdown of The Three Phases of Product Managers—and not just because he got me with his jazz reference. The third phase:

A Product Manager acting as a Jazz Player will set the context, and team members will build upon it. They relentlessly search for opportunities to create something innovative and outstanding. This scenario is more or less like the following:

• Context: Product Managers bring the proper context to the team. Goal, audience, value proposition, objectives, and strategy. The team can help sharpen the context, and that sets the playing field.
• Uncovering Opportunities: Everyone in the team has the same voice. They bring potential opportunities and evaluate whether it’s worth investing in them.
• Learning: Curiosity is what drives them. As in Jazz, the team isn’t afraid to try solutions as fast as possible. They improvise and don’t fear embarrassment, but they’re scared of not learning fast enough.

I also agree with David that the most difficult part about growing into a product leader is the shift from “Conductor” to “Jazz Player” (in the model he shares in the post). And among those attributes, context is the hardest, and remains something I am constantly trying to get better at.

Synthesizing information and providing the necessary context to our teams about projects or decisions take longer upfront, so many leaders skip that part because they have so many other things vying for their attention. But the problem is that if you don’t do that work upfront you’re only going to have to do it later—and in a more time-consuming way. The team will have questions, there will be lots of back-and-forth, and they will likely also be frustrated by the lack of clarity in their work. So don’t skip that part. Don’t just say “here’s what we’re doing”, say “here’s what we’re doing, here’s why we’re doing it, and here’s the data that supports why we’re doing it.”

Ben Balter puts it this way in his excellent article Leaders Show Their Work:

As the ones with that missing context, leaders sometimes naively or inadvertently assume that all that’s required for a change to take effect is to communicate the thing that’s changed, but humans are not servers. Unlike deploying a change to a codebase, a diff isn’t sufficient to truly realize what’s intended. Engaged humans rightfully seek to understand how and why the change came to be and often want to double check their leaders’ work to fully understand how it impacts their own.