I’m coming up on two years since my role switch to Product Manager, and this second year is when I feel like I’ve finally settled into it and have a sense of how to do it properly.

When I was starting to transition to this role, I did a lot of trying to read through product management books to connect the dots between Everything I Did Before and What I Should Be Doing Now and it… did not go well. These books are full of case studies from very large companies, with established product organizations and multiple engineering teams.

That is not the kind of company I work for. Nexcess didn’t have a defined product function at all before it was acquired by Liquid Web, and the Liquid Web product organization hadn’t been operating in a way that looked anything like those case studies. We also don’t organize into multiple development teams that can be moved between initiatives.

None of that is a complaint, to be clear. It just means the commonly-recommended literature wasn’t all that helpful to me.

The deeper I get into this role, and more professional literature I read about it, the more it feels like the only way to describe Product Management is through metaphor: “PM is the tip of the spear!” “PM is the adult in the room!” “PM seals up the cracks in an organization!”

All of those things are true, but that is not the same thing as being helpful.

So I wanted to try to write some things down while I am experienced enough to say something (hopefully) useful but still new enough to remember what I needed to hear.

What would you say you do here, Tiff?

Probably the easiest way to sum up my job is that I decide what we do next.

Broadly, my job is to collect inputs from all around the business: senior leadership, support, development and engineering, sales, market data, sales data, my own years of experience in the space, and whatever other inputs are available, and while holding all that in my brain, distill all those competing perspectives and concerns down to decisions about how to make our product valuable to customers, but also to the business.

As part of that work, I do a lot of identifying and filling gaps: gaps in our data that hide the real story about how a product is performing, gaps in our processes for getting an initiative launched, gaps in our customer-facing and internal documentation.

And finally, and possibly most importantly, I prioritize. The questions I use to evaluate every project, every feature request, every bit of feedback I get, go something like this:

• Given that I have finite development resources, in what order should we tackle this list of projects so that our customers get what they need and the business achieves its goals?
• How narrowly can I scope each of these items so that they remain viable but are small enough that we can do more of them?
• What should I deprioritize so that we can address this new thing that just came up?
• Should I say no to this exciting new thing because the other things we’re tackling are just more important, even if they’re less exciting?

I often joke that my two most important skills are:

1. Smiling real big while saying, “And how are we going to move that forward? Is there a plan to move that forward? What’s the next step in moving that forward?”
2. Stack-ranking.

Okay, but what does that mean? What do you do all day?

Well, I’m in a lot of meetings. 😅

I meet regularly with our support leadership to hear about what they’re noticing; sometimes it’s customers consistently having the same problem with a feature, or sometimes it’s an internal alert that’s causing a lot of noise without a lot of value. I meet weekly with a cross-functional team that’s addressing a bunch of related projects of varying sizes. I attend a daily standup. I have a regular meeting with our senior development leadership to make sure we’re aligned on priorities and processes. I have a few bi-weekly sync-up meetings designed to make sure the different parts of the organization maintain an ambient level of knowledge of what’s happening and what’s upcoming in other areas of the business. Anytime there’s a new initiative from senior leadership, product is represented and I’ll go to those when it’s my products being impacted.

In between meetings, I do a lot of writing. I write requirements documents: we have a standard format and every project I do starts with one so we can all agree on what we’re trying to achieve and how we’re going to get there. I write briefs and bulletins for our sales and support folks so they know how to talk about new products and changes to existing ones. I answer questions from those same teams via Slack to make sure people know what they need to in order to help customers and close sales.

I also spend a lot of time in JIRA, responding on tickets where Product has been asked to weigh in on requests from other teams, or stack ranking tickets where the urgency is not clear, or clarifying requirements.

On our Product team, we have a Product Marketing colleague who maintains the roadmap (by which I mean the actual file that people will refer to when they want to know what’s on the roadmap), so I coordinate with him regularly to help ensure it’s up to date and accurate.

In some ways, a lot of my job is just to know things and have strong opinions about those things.

Wow, so you just walked in and started doing all that?

Haaaaah, no. Because our Product org wasn’t owning the prioritization process, all of that prioritization and decision-making was happening elsewhere in the company. I had to identify how those decisions were being made, by whom, and how I could get those processes moved back into the Product organization where they properly belong.

In order to do that, I spent a lot of time early on building trust: learning the product, learning how the different parts of the company interact, building relationships with the leaders in each department, building a reputation for reliability by trying to demonstrate curiosity and thoughtfulness and helpfulness.

One of the most important things I read during this time (and I can’t remember where I read it, sorry) was the idea that Product Managers must “lead without authority.” I think about this phrase at least 3 times a day, and how if you want to lead, you have to convince people you’re worth following. That can take a lot of time: In general, people want to do a good job, and good managers want to protect their teams, so if Product isn’t acting as that strong, trustworthy hand steering the ship, the leaders of the other teams are quite logically going to figure out their own prioritization processes and their own processes for protecting their own teams’ interests.

In practice, that means that when the organization is trying to move forward with an initiative, and Engineering wants to make a change that Sales objects to, or Support is so buried that they are reflexively suspicious of anything that sounds like it might increase ticket volume, it gets hard to get anything done because there’s no one refereeing between all those competing concerns.

if you want to lead, you have to convince people you’re worth following

Overcoming that means convincing those leaders that you understand, are considering, and most importantly, care about those concerns. Sometimes you have to overrule someone’s objections, and when that happens, it goes a lot better if your thought process and decision-making is as transparent as possible. I’ve also had projects that I had to let proceed at a far slower pace than I would have preferred in order to demonstrate that a team’s concerns about it, while understandable, were overblown. In the end, the investment of time was worth it for the trust and relationship gains of the process, and the next time I need to get that team on board with something, it will be easier.

Okay, that’s a lot of words. Boil it down for me.

• Communicate clearly and frequently. No one should have to wonder where things are.
• Recruit others to your cause. Even if the relationship with Product was adversarial before you walked in the door. Especially if so.
• Understand all the impacts as well as the inputs. Impact is usually business-y metrics like revenue and new customers and support interactions, but the hidden impacts are things like “Did the head of Support feel like you solved a problem for their team?”
• Cultivate a reputation for hearing everyone out, making your through process transparent, and then being firm in your decision.
• Prioritize ruthlessly. Because if you don’t, someone else will.

And a bonus one, from my 1:1 with my boss last week, that I’m still mulling over:

“We’re wrong more often than we’re right. Everyone is. In Product, we have to be brave enough to be wrong until we get to be right.”