Note: Some quick background to this list. At Amplitude (my day job), we help teams build better products. I’ve been super impressed by the product chops of our account executives, sales engineers, and customer success managers. The team has experience helping all sorts of teams be more successful.

That said, we’re growing fast, which means that newly joined people need to get up to speed quickly. Product and product management can be confusing from the outside. So I put together this list of common PM challenges to help build empathy/understanding for PMs.

This post is meant to build empathy for product managers, and to understand their world just a bit better. I’ve focused on the hard stuff, so don’t expect too many feel-good stories. Don’t assume these are universal, but always be on the lookout for ways to connect more deeply with their challenges (and turn those challenges into opportunities for progress). Empathy goes a very long way.

Table of Contents

1. Their days are frenetic

It is common to go through the whole day as a PM, and get absolutely nothing done. Your calendar is stacked. The meetings are booked. There is a ton of talk, but nothing seems to have actually happened (outside of a bunch of new items for you to follow up on). Meanwhile your team is sitting there with important questions, you have two-hundred unanswered emails in your inbox, Slack is firing off notifications left and right, and you have a doctor’s appointment at 4:30pm you have to get to (because you’ve missed your appointment three times in a row). It is frenetic.

This can extend for weeks. You know you have to do the deep work — strategy, context building, unraveling insights — but somehow that all takes a back-seat to a mess of meetings, Google Docs, status reports, and generally getting caught up in the inertia of the organization.

2. They can be torn about their role

I speak with many PMs who privately admit that they both love product management, and also doubt that they are a good fit for product management. Some were drawn in by the entrepreneurialism, only to find out that they had to spend all day playing defense and executing another person’s bet. Some were drawn in by the prospect of actually bringing “new stuff” into the world, only to find that bringing anything successful into the world is super hard, and that most PM roles involve optimizing existing products (and spending a good chunk of the day in meetings saying No). Some wish they had tried UX or programming (or both) in order to be more hands-on. Don’t get me wrong…PMs also “love” their jobs, but there is a tension with the role that can be hard to describe.

3. They are at the center of a tornado

In a single week, even a “front-line” PM (think Senior PM) can have interactions with the CEO, customers, Sales leaders, front-line engineers, engineering leadership, customer success, marketing, support, users (if distinct from customers), and business partners. I’m almost certainly missing people in this list. This breadth is one of the joys of the job, but it can also be incredibly difficult to handle and master. Imagine having to switch context so often. Go high level, you’ll be asked for details. Give details, and someone will ask you for a 12 month roadmap. You’ll jump from one meeting with people openly debating company strategy, to another meeting where you are expected to be the shining, energetic face of “the product”.

For better (or worse, often) you are somehow perceived as the gatekeeper…the person who must be manipulated to get “anything done”. That entails being the subject/target of social engineering, and in seriously dysfunctional situations people just working around you. Meanwhile you have a team of passionate makers toiling away at things you happened to prioritize. Maker-pressure is fierce. If they think you’re going in the wrong direction they’ll let you know that — either explicitly or implicitly (see #12 for more on this).

4. They get thrown into the deep end

Many junior PMs (or folks transitioning to PM) are thrown into the deep end. They are “assigned” to a team, handed the old backlog, tasked with “coming up with a new roadmap”, and set loose. Until you do, people don’t trust you. But when you do, they doubt that too! Because everyone is so busy, and because PMs are expected to be resourceful, you will not see the level of support and care for onboarding that you might see from an engineering org. I’ve talked to leaders who think “sink-or-swim” is a valid way of “separating the wheat from the chaff”. The challenges here are immense. Imagine that the junior PM is paired with a group of experienced makers; they’ll get eaten alive. Or…if everyone on the team is junior; they’ll get no help from the team and will flounder. Either way, you have a problem.

This isn’t just relegated to less-experienced folks. Recently, I spoke with a Director of Product who was handed a huge challenge — “figuring out our platform strategy” — with almost no effort to help them build connections and relationships across the organization. It was sink-or-swim. Three months in they had discovered a huge gap in shared understanding across the org — a gap that needed to close to do his job — but the politics were too fierce to make headway.

5. They are expected to exude certainty

Even when things are uncertain, PMs are expected to be certain — certain about dates (“you know…ballpark”), about roadmaps, about problems, about outcomes, and about the exact details of the release notes. This is a problem, because so much of what we do as product developers — why there are opportunities to begin with, actually — relies on the fact that things aren’t “for sure”. If there was certainty, everyone would be doing it. You might as well become a project manager (lol).

This is most evident during fundraising. To raise money you typically need to show you have some vision for the future. What is that vision? If you have a persuasive story, it’ll help your fundraising efforts. So…senior product folk are asked to hastily frame that story, money is raised on that story, and the next 12–18 months (the time it takes to spend any raise) is spent juggling what existed on the ground prior to the raise, and this new story (a couple pages in a “deck”).

Day-to-day we see PMs pressured to “pitch” to teams, justify a direction, and even slip into a bit of success theater (“the feedback is great!”). It’s super hard. Most PMs know deep down what is going on and feel torn. Some get so caught up in the certainty theater that they start to believe their own Kool-Aid. “I don’t know” is a tough skill to master.

6. They have vastly different roles depending on the company

Take a group of 100 salespeople at a conference. Now, get them in a room and start asking questions about their role, their motivations, etc. There’s likely to be a good deal of homogeneity. Do the same thing with PMs and you’re likely to see a ton of diversity. There’s the “on-paper” PM job description that you might find online, and there is the reality. Why? PMs are smack dab in the middle of everything, and therefore their role is highly dependent on other structures, perspectives, and organizational forces. Additionally, software product management is still relatively new in the grand scheme of things, so you still see a ton of divergence. A great example: consider the role of “product managers” across Facebook, Amazon, Netflix, and Google. There are lots of differences. Part of that is a result of different business models, and part of that is different cultures (right back to the founders and early team).

As you see new generations/waves of PMs come into the workforce, you also have the challenge of the new PMs being highly influenced by more modern interpretations of the role, clashing up against less modern interpretations. So even with a single company you see vastly different definitions — even when everyone seems to agree on what product does.

7. They can’t make most decisions unilaterally

I’m going to use the frame of purchasing tools/products here, but you could slot in many types of decisions as examples. Take a new CMO, CIO, CTO or similar. They come in guns blazing expecting to shake things up. They’ve been given a budget for new tools, hires, and initiatives. In the first 90 days they’re expected to “have a plan”, and then will be given the next year or two to make that happen. Importantly (for these roles), many of these decisions can be made unilaterally. The CMO will have a list of tools they need to buy (either self generated, consultant generated, or “best practices”) and they will be able to write the check. They might even hire a person with experience to run the “operations” of said department. This is much rarer when it comes to a “product leaders”.

Product development is inherently cross-functional. Product management piggybacks many of its key purchasing decisions off of the decisions in other groups. The cliche is that product managers have influence, not authority. While this isn’t an absolute, it holds true in many settings. Example: Marketing controls the “website”. Marketing can basically do what it wants (and install whatever tools it wants). Try to do that with “the product” with a gang of opinionated and passionate engineers monitoring every change, and you’ll be in for a surprise (this is a good thing, by the way, just hard). Example… a CTO doesn’t ask permission to install a CI/CD tool provided it is in their budget. For “product” to do the same, they’ll need to “take it to the committee”.

8. They struggle with the pressure to “ship”

Even in evolved organizations, you’ll still find a strong pressure to just ship “new stuff”. New stuff is tangible. New features feel like progress. New stuff sells. Learning and experimentation is great, but it is not visible, and largely not understandable by non-product developers. “What do you mean a failed experiment was worthwhile?”

Even when they know a “better” approach is possible, you’ll find PMs get caught up in the feature factory. There’s an incredible pressure to be certain (see above), so pitches turn into prescriptive plans which turn into confirmation bias and delivering “to plan”. Experimentation and hypothesis driven development is viewed as something that “only happens in the movies” and a “nice to have”. Back in the “real world” you’re expect to “ship stuff”. This gives rise to being conflicted and a bit forlorn. You understand that there’s a next-level in your craft — and you want to get there — but the day-to-day is far from that reality.

9. They are the canary in the coalmine

For many of the reasons above, we find that product managers, and the pain they are experiencing, are an early indicator of organizational dysfunction. This tends to happen with “hub” roles that interact with (almost) everyone. It’s a different kind of response compared to, let’s say, Sales. Sales touches the customer, so they’ll have an early sense when the product/pricing/value proposition isn’t hitting the mark. This is vitally important (note to PMs, listen to Sales). Product feels that AND the pain that might be experienced with technical debt, difficulty supporting the product, difficulty adopting the product, and difficulty getting actual value of the product come renewal time.

Any tension/dysfunction among leadership transfers all the way to frontline PMs (to the extent that I can usually predict what is going on at the highest levels based on a quick chat with someone in the product development trenches). When things are going well, product feels it. When things aren’t going well (almost anywhere), product feels it. This can give rise to a number of coping mechanisms ranging from anger/defensiveness (“why can’t they ship anything” or “why does sales keep selling stuff we don’t do”) to a kind of low-level dejectedness and learned helplessness.

10. They often have to play project manager and facilitator

Product managers often find themselves playing project manager and facilitator. A pattern I have observed often is that the PM is more in-tune with engineer challenges/tensions than engineering leadership. They see the pain first hand vs. from afar, and feel a strong responsibility to facilitate and improve team health. They are also frequently asked to play “herder” — coordinating activities, picking software project management methodologies, getting deep into Jira, and “managing” rituals and activities. These hats are important — someone needs to wear them — but on top of an already hectic schedule it can usurp all available time (and tax the PMs skillset). Forget strategy. Forget gathering insights. The day-to-day is spent in the weeds herding. While this is common, it is not an absolute. “High performing” teams are healthier and need less help dotting “I”s and crossing “T”s. In theory, “how” the team delivers can be up to the team and the PM can be a participant in that decision (not the catalyst or “manager”).

11. They come from many different backgrounds

Product managers come from very different backgrounds including: engineering, design, marketing, support, customer success, business analyst, operations, management consulting, founder/entrepreneur, and areas of domain expertise (e.g. health care). It is very, very hard to typecast a PM, or make assumptions about what drives them as an individual. Some embrace the idea of collaborating with their team, while others see “their” team as a means-to-an-end to advance their individual goals. Some love the startup world and eventually want to start a company, others are super product-craft design nerds. Some love to be in the hotseat making decisions, others get primary joy out of facilitating great decisions from their team.

12. They are under a lot of pressure from their teams…

Imagine you are a designer or developer. You are about to spend the next 6–12 months marching in a certain direction. The source of that decision? The product manager. Now, the PM seems to waver a bit. They seem to be a bit lax in their resolve. They don’t lead with data, and aren’t transparent about their intentions (or, again, it seems that way). How do you act? What do you do? And what do you do if things don’t turn out great? You get resentful. You start to doubt your product management team member. You might even start to undermine their decisions.

The point here is that the relationship between product manager and engineer/designer is very, very interesting. There is different “skin in the game”. When the PM says “ok, we’re moving on, the MVP is good enough!” it might mean very different things for the PM and the team. The team that has toiled in the trenches has been asked to cut their good work short. The relationship can be tense and strained, or it can be based on “healthy tension” which — assuming it doesn’t just render mediocrity — can really benefit the product.

13. They are always juggling “theory” and real world practice

I alluded to this above, but it is worth exploring. Product managers are bombarded day in day out with content, books, and people telling them “how” product is supposed to be done. There is no shortage of information and learning. Take something like having an outcome in mind with each initiative. It makes perfect sense. Or the idea of the Google “Sprint”. Cool, sounds good. Now, try to do that in practice amidst the strong pressure to ship, be certain about things, and work through the dysfunctions of your team. It’s hard! I’ve spoken to so many senior product leaders at well known companies who want, in their hearts, to adopt some new ways of working, but simply can’t operationalize these ways in the real world. The aspiration is there. But the inertia is also there. I’ve had the fortune of talking to teams from some companies that are generally regarded is “best in class”. You know what? The problems are still the same. This is messy work.

14. They struggle with impossible expectations

I very regularly encounter senior product leaders who openly say something like “well, many of our PMs don’t cut it”. When I talk to those PMs, I discover an environment where getting anything done — let alone the “right” things — is extremely difficult AND they are getting limited guidance and training. The trouble is that these front-line PMs feel the doubt. They internalize it, and feel like they can never do a great job. It might even drive them to success theater and looking for big, visible “wins” at the expense of their teams and long-term business outcomes. Hiring based on an ability to navigate dysfunction doesn’t seem like a viable long-term approach (to me), but I know this is very common.

15. It’s hard. Super hard.

To summarize, it is super hard. You are in a vague role, expected to cherish the ambiguity. You are thrown into the heart of the organization, and expected to go 90mph (and be a servant leader, and be a shipper, and be a therapist). You make decisions for other humans, and they’re liable to start doubting you when things inevitably don’t pan out (because it is hard). You rely on your team, and they rely on you. And when things go wrong….