I spend a lot of time making the case for product management as one of the most intellectually rewarding careers available. The autonomy, the variety, the direct connection between the quality of your thinking and the quality of what gets built: all of that is real, and I mean it when I say it.

But there is another side to this job that does not make it into the conference talks or the LinkedIn posts or the PM influencer content that celebrates the role as a kind of creative dream. It is the side that experienced PMs know intimately and rarely discuss, partly because admitting it feels like weakness, and partly because the problems are structural and not easily fixed, and talking about things you cannot fix is uncomfortable.

Today I want to talk about it anyway.

What follows is not a counsel of despair. Each of the eight realities below has a genuine way of being managed, and I will share what has worked for me and for the PMs I have worked alongside. But I want to be honest about the nature of the challenges first, because the sanitised version of this job does people a disservice.

If you are considering a move into product management, you should know what you are walking into. If you are already in the role and finding it harder than the job description suggested, I want you to know that is not a personal failing. Some of this is simply the territory.

Let us dive in.

This is the one that gets every PM eventually, including the ones who have been managing delivery for years and genuinely know what they are doing.

No framework eliminates schedule risk. Not Agile, not Waterfall, not SAFe, not any hybrid methodology that someone has branded and sold as the solution to software delivery uncertainty. The uncertainty is not in the process. It is in the nature of the work itself.

The reason is straightforward: software development is a creative and investigative activity, not a manufacturing process. When you build a car on a production line, you are repeating a sequence of known steps with known inputs and known outputs. When you build software, you are, to varying degrees, doing something that has not been done in exactly this way before. The problems you encounter are not fully predictable. The solutions take the time they take. The estimate was always a guess, even when it was an educated one.

What makes this harder is everything layered on top of the inherent uncertainty. One team member gets sick for a week at a critical point in the sprint. An API that a third-party vendor assured you was stable turns out to have undocumented limitations that your integration exposed. A dependency on another team slips because that team is dealing with their own pressures. Any one of these is manageable. The combination, experienced repeatedly over months and quarters, produces a constant background noise of schedule pressure that is exhausting even when each individual instance is minor.

The practical solution that I have seen work consistently is to plan for roughly 70 percent of the team's theoretical capacity and hold the remaining buffer without advertising its existence. Not because you are being deceptive, but because the buffer will be consumed, reliably, by the things you could not have predicted. A team running at 70 percent of nominal capacity and delivering consistently is more valuable, and more trusted, than a team that commits to 100 percent and delivers 75.

The deeper shift is accepting, genuinely and not just intellectually, that timeline uncertainty is a permanent feature of this work rather than a problem that better planning will eventually solve. The PM who has made that acceptance spends less energy being frustrated by the inevitable and more energy managing around it.

If timeline slippage were the only challenge, product management would be a considerably more manageable job. The problem is that timeline slippage is just one item in a category of difficulties that accumulates continuously and does not, in any sustainable PM's experience, diminish over time.

People leave. It is one of the most disruptive things that can happen to a product team mid-cycle, and it happens at a rate that nobody who has not managed through it fully anticipates. The engineer who held the context for a critical system component gives three weeks’ notice at the worst possible moment. The designer who was two weeks from finishing a project takes a role somewhere else. Each departure is, individually, a normal part of professional life. The cumulative effect on a team's capacity and continuity, experienced over a year of product development, is significant.

Then there is the technical reality. The simple one-day refactor that the architect estimated turns into a three-sprint odyssey because the system it touched was more coupled than anyone realised. The build breaks because a change in a completely different codebase had an undocumented side effect. The third-party service that was supposed to handle a core function behaves differently in production than it did in the sandbox. Each of these is, in isolation, a manageable problem. Together, they form the texture of most PMs' working lives.

The solution here is not a process change. It is a psychological one: accepting difficulty as a permanent feature of the landscape rather than a deviation from the normal state. The PM who is surprised and stressed by every new obstacle is going to spend a significant proportion of their career surprised and stressed. The PM who treats obstacles as expected and redirects their energy immediately toward solving rather than processing is more effective and substantially more resilient.

This does not mean suppressing the frustration. It means not letting the frustration determine how long you stay stuck before moving.

Here is something that the textbook version of product management does not prepare you for adequately.

Some of what you build will be built not because it is the right thing for the product or the users, but because someone with institutional authority decided it needed to happen and your manager communicated that decision downward as a directive. The strategic rationale may be thin. The user research may not support it. The timing may be poor. None of that will necessarily change the outcome.

This is an uncomfortable reality, and it is worth sitting with honestly before arriving at the standard advice about fighting for your autonomy and picking your battles.

The fighting-for-autonomy part is correct and important. The PM who accepts every politically-driven directive without pushback gradually loses the ability to push back at all, because they have communicated through their behaviour that pushback is not something they do. The data-backed counter-argument, made clearly and without making it personal, is a legitimate and often effective tool. It does not always win, but it is always worth making.

The picking-your-battles part is equally important, because the PM who treats every directive as a hill to die on will exhaust both themselves and the goodwill they need to win the battles that actually matter. Not every politically-driven decision is worth the relationship capital it costs to reverse it. The judgment of which ones are worth fighting is one of the most important and least discussed skills in senior product management.

What nobody tells you clearly enough is that this dynamic does not go away as you become more senior. It changes shape. The politics become more sophisticated and the stakes become higher, but the fundamental reality, that product decisions are sometimes made by people whose primary concern is not the product, remains.

Document everything. Record who made which decision and on what basis. Not as a defensive bureaucratic exercise, but because those records are the only protection you have when the consequences of someone else's decision get attributed to your judgment.

This one needs to be said plainly, because the professional rationalisation of it tends to obscure how genuinely unfair it can be.

The PM owns the product outcome. That is the job. It is also the accountability structure that makes you the most visible target when the outcome is not what the organisation hoped for.

The product missed its revenue targets. Was that because the PM made poor prioritisation decisions, or because the sales team was under-resourced, or because the marketing campaign was underfunded and launched into the wrong channels, or because a competitor emerged with a significantly better-funded operation, or because the economic conditions changed? Almost always, the real answer involves some combination of all of these things. The attribution is rarely clean.

That does not stop the attribution from landing disproportionately on the PM, because the PM is the person who said what the product would do and when it would do it. They are the face of the product promise internally. When the promise is not met, the face of the promise is the natural focal point for the organisation's disappointment.

What makes this particularly difficult is that the PM often genuinely does not have the levers to control the outcome they are accountable for. You do not own the sales team. You do not control the marketing budget. You did not set the revenue target that came from two levels above you. You can influence all of these things through relationships, through communication, through the quality of the product you build. You cannot determine them.

The practical protection is documentation: the decisions that were made, who made them, what the data said at the time, what alternatives were considered and why they were rejected. This is not about building a legal defence. It is about having a factual record when memory becomes selective and accountability needs to be assigned. Facts are the only reliable protection against retrospective rewriting of history, and retrospective rewriting of history is a regular feature of organisational life when things go wrong.

This is the one that PM culture finds hardest to absorb, because the entire professional apparatus of product management is built on the implicit promise that better decisions produce better outcomes.

They do, in aggregate, and over time. But in any specific instance, the relationship between decision quality and outcome is much messier than that.

You can identify the right problem, do rigorous user research, build the right solution, execute a flawless go-to-market, and still find that the timing was wrong. The market was not yet ready for what you built. A competitor with ten times your funding launched a comparable product three months before you and captured the distribution. A macroeconomic shift changed the priorities of the users you were serving. None of these were failures of judgment. They were failures of luck, or timing, or resource parity, or forces entirely outside the product team's control.

Product management, done well, improves the odds. It does not guarantee the outcome.

The psychological implication of this is important, because internalising it is the difference between a PM who learns from failure and one who is destroyed by it. If you measure yourself primarily by outcomes, you will be at the mercy of factors you cannot control. If you measure yourself by the quality of the decisions you made with the information available at the time, you have a standard that is both honest and within your control.

This is not a counsel to be indifferent to outcomes. Outcomes matter enormously, and the PM who does not care whether the product succeeds is not doing the job. It is a counsel to maintain a clear distinction between what you controlled and what you did not, and to direct your learning toward the former rather than torturing yourself about the latter.

Good decisions that produce bad outcomes deserve examination. They also deserve perspective. Sometimes the decision was as good as it could have been, and the outcome was determined by something else.

I want to address the one that is most important and most consistently underaddressed in professional conversations about product management.

No single item on this list, taken alone, is likely to break you. Timeline slippage is manageable. Political interference is navigable. Being blamed for things outside your control is frustrating but survivable. Even the randomness of outcomes, accepted with appropriate perspective, is something most people can live with.

The problem is the accumulation.

Over months and years, the constant low-grade stress of a job where the timelines are always under pressure, the difficulties never stop arriving, the politics are always present, the accountability exceeds your actual control, and the outcome is never fully in your hands produces a particular kind of wearing-down that is different from acute stress. It is quieter and harder to notice in yourself, which makes it more dangerous.

I have watched brilliant PMs burn out at organisations where I have worked, and it almost never looked the way burnout is portrayed in the popular imagination. It did not look like a breakdown. It looked like someone who gradually cared a little less each week, who stopped bringing the energy and the curiosity that had defined them, who got through each day without it being visible that something was wrong, until one day the light had gone out entirely.

By the time it is visible to the people around you, the cost has usually already been high.

The solution I want to offer is not a mindfulness practice or a work-life balance tip. It is a more fundamental reframe: treat your energy as the most important resource you manage, because without it, none of the professional skills matter.

That means being honest, regularly and without self-judgment, about whether the job is giving back as much as it takes. The cost-benefit calculation of professional roles is rarely discussed explicitly, but it is always operating implicitly, and when the balance is negative for long enough, the body finds ways to rebalance it that are outside your conscious control.

If the job is costing more than it is giving back for a sustained period, the answer is to change the job. Not to become more resilient. Not to manage the stress more effectively. Not to find ways to maintain the smile through the accumulation. Those are short-term coping strategies that delay a reckoning rather than resolving it.

Change the role. Change the organisation. Change the scope. Something needs to change, and the something is never you.

The PM is supposed to be the most informed person in the room about the product. In practice, they are frequently the last to hear the things that matter most.

The engineer who discovered a serious architectural problem three days ago and has been quietly trying to resolve it before saying anything, because raising it feels like admitting failure. The designer who knows the usability research contradicts the direction the team is heading but has not found the right moment to surface it. The stakeholder conversation that happened two levels above you and produced a commitment nobody thought to pass down. The sales feedback that has been circulating in a different Slack channel for a month that nobody connected to the backlog.

Information in organisations flows through relationships and trust, and it flows unevenly. The PM who is not close enough to the team and the wider organisation to be the first call when something goes wrong is operating on a delayed and filtered picture of reality, and making decisions on that basis without knowing it.

This is not a failure of process. No amount of standups or status updates fully solves it, because the information that does not surface in structured settings is usually the most important kind: the thing someone is not sure is worth raising yet, the concern that feels too vague to formalise, the early signal that has not yet become a clear problem.

The solution is relational rather than procedural. The PM who has invested genuinely in the human connections across their team and their stakeholder network, who has made it clear through consistent behaviour that they want to hear difficult things early rather than polished things late, and who responds to early signals without shooting the messenger, will receive a more accurate and more timely picture of reality than the one who relies on formal reporting channels alone.

Create the conditions where people bring you problems before those problems become crises. That requires trust that is built over time and maintained through every interaction, including and especially the uncomfortable ones.

This one surprises people who have not done the job, because the PM is constantly surrounded by people. Meetings, standups, stakeholder sessions, one-to-ones, planning ceremonies: the calendar is rarely quiet. But being surrounded by people is not the same as having someone to talk to honestly, and the distinction matters more in this role than in almost any other.

You cannot fully confide in your team about your doubts regarding the product direction, because part of your job is to maintain the team's confidence in that direction while you are still working through your own uncertainty. You cannot be fully transparent with stakeholders about the internal challenges you are managing, because that transparency carries political costs that can compromise your ability to operate. You cannot always tell your manager what you genuinely think is going wrong, at least not without careful calibration of what is safe to surface and what is better navigated quietly.

The result is that the PM carries a significant amount of context, concern, and uncertainty that has nowhere to go. The combination of high visibility and genuine isolation is one of the most consistently underacknowledged features of the role, and it contributes meaningfully to the burnout described above, because isolation under pressure is its own form of sustained stress.

The solution is to build the relationships that allow for genuine honesty outside the formal reporting structure. A peer at a similar level in a different organisation who does the same work. A mentor who has navigated the same terrain and has no stake in the political dynamics of your current context. A coach, if the organisation supports it or you are willing to invest in it privately. Even one honest professional relationship in which you can say what you are actually thinking, without calibrating for its impact on your position, is worth more than it is possible to quantify.

The PM community is, in my experience, more generous with this kind of support than the competitive surface of the industry might suggest. Find your people. The ones who will tell you what they are actually finding hard, rather than performing confidence they do not feel. Those relationships are one of the most undervalued forms of professional development available to you, and they cost nothing except the willingness to be honest first.

I have written this not to discourage anyone from the role, but because I believe that people who go into product management with an honest picture of what it involves are better equipped to handle it than people who discover the difficult parts through experience without any framework for understanding them.

The job is genuinely rewarding. The intellectual challenge is real. The connection between your thinking and what exists in the world, between your decisions and how users experience a product, is a form of agency that is rare and meaningful.

It is also harder than it looks, in ways that are structural rather than personal, and the PMs who last are almost always the ones who found a way to be honest about that with themselves before the accumulation made it unavoidable.

A question worth sitting with: of the eight realities described above, which one are you currently underestimating in your own situation?

The honest answer to that question is usually the most useful starting point.