This article reflects only my own views, and not the views of any employers or companies with which I am associated.

“At our company, you get to be CEO of your own product. You’ll be the complete owner, and we’ll ultimately hold you accountable to delivering quality, on time.”

“If you join us, we expect you’ll be willing to be janitor for the team. You should handle all the things that your team can’t, or shouldn’t do. Don’t be afraid to roll up your sleeves and write some unit tests, or mock something up on Photoshop!”

“We’re looking for a jack-of-all-trades — know less about any single domain than your team member, but know more about all the other pieces of the system.”

There seem to be just as many ways to describe the product manager role as there are tasks a PM is expected to handle. I spent the first two years of my career inventing what the role meant for my own 7-person startup, the next year learning what the role entailed as a Yahoo Associate Product Manger, and this past year consolidating and repackaging what I think it all means.

“Product Manager” is, for me, an infuriatingly vague term. To my friends in other industries, it sounds pleasantly impressive. It sounds like I’ve worked my way into management. Au contraire — there’s not a soul who reports to me.

To my Silicon Valley colleagues, the title can be just as ambiguous. “Oh? That’s cool! So uh… what is it that you do on a daily basis?”

The varied responses I’ve heard for this question remind me of an old fable. A group of blind monks walk up to an elephant, each touching different parts of the elephant. Because they are exposed to such different aspects of it, they describe the object to one another completely differently, unable to agree on what it is they’ve found. One feels the tail and is convinced he’s discovered a rope. Another feels the broad side and describes a leathery wall. The third feels the ears and the trunk and is bewildered by what he’s found.

Similarly, every PM defines their role very differently. Within the same company, or even the same team, a PM will stretch and expand themselves to cover as much as is needed on that particular team.

“I feel a rope”

In one of my earlier roles, I had to help negotiate business contracts with large companies, voicing what information would be most valuable and what we would be willing to offer in exchange. For this particular role, I required knowledge of the flexibility of our financial coffers, technical know-how for difficulty and timeframe of the required engineering integration, and even opinions on design — would we be willing to feature the other company’s brand in our product? I went back and forth with internal team leads and the other company’s product liaison, settling on mutually agreeable terms.

“It’s flappy and smooth”

A year later, I moved on to a more technical-leaning PM role, providing input on when and how to invest in new algorithms, and how the pros and cons of new systems would weigh against the priorities of what the product needed. For example, while a new algorithm could provide a 15% improvement in accuracy, it could require 2 months work to re-organize the rest of the systems to work with the new model. In the meantime, the same teams involved could work on improving performance and speed by 25%. Which should we prioritize first? These were the hazy and vague tradeoffs I needed to make on a weekly basis, relying on both data and gut intuition to make a call one way or another.

“It feels like an endless, wrinkled wall”

Finally, I have another colleague who spends the majority of her time analyzing our processes and ensuring an ever-accelerating pace of progress. She understands the system as a whole and can drill down to work with individual teams to unblock them; but can also step back and evaluate the pace at which the larger team is moving and effect changes that allow us to move ever more nimbly. She constantly runs experiments and gathers feedback from the teams to evolve and improve the process.