24 Harsh Truths of Product Management I Learnt the Hard Way, the infographic in this PDF

Product management

24 Harsh Truths of Product Management I Learnt the Hard Way

The hardest part of product management isn't the product. 24 harsh truths about decisions, money, ownership, evidence and your level, grouped by where they bite.

Want this as a PDF?

You'll also get The Product System, my weekly note on leading product in the AI era. Unsubscribe anytime, and I'll never sell your email. How I handle your details

1

The full infographic, as a PDF

The exact one from the post, sized to print or keep within reach.

2

A copy in your inbox

The download link lands in your email too, so it's there when you need it. No follow-up campaign.

3

The Product System, weekly

My note on leading product in the AI era. One idea a week that compounds. Unsubscribe anytime.

The hardest part of product management isn't the product. It never was.

The product is the part you were trained for. You can learn discovery and learn to read a funnel. What wears people down is everything around it: the money, the org chart, the approvals, and the things nobody says out loud in the meeting.

These are 24 truths I learnt the hard way. They are harsh about the system, not about the people working inside it. I've grouped them into six themes so you can see where each one bites. If you want something shorter, the 12 brutal product management truths piece in the Vault is the companion to this one.

Read them as a check on your own week. Some will feel obvious. The useful ones are the ones you've been working around without ever naming.

Decisions and saying no

Every yes is a no you didn't announce. Time and people are fixed, so each new commitment pushes something else out. The only choice is whether you say which thing, or let it slip and hope nobody notices.

Half your roadmap is a no nobody dared to say. Items sit there for quarters because removing them means a hard conversation. They cost nothing on paper and a lot in focus.

The meeting happened. The decision didn't. An hour of discussion can end with everyone nodding and nothing settled. If nobody can say what was decided, who owns it and what changes on Monday, you had a conversation, not a decision.

Prioritisation is popular until your item loses. Everyone wants a clear framework until it ranks their request fourth.

A deadline with no trade-off is not a plan. It is a demand. If the date moved in and nothing moved out, the scope, the quality or the team's evenings will pay for it.

And nobody thanks you for the feature you killed. Stopping the wrong thing is valuable work that leaves nothing behind to point at.

The better move is to say the no out loud, with the reason, while it is still cheap.

Money and value

Finance decides what gets built. Not you. The roadmap lives inside a budget, and the budget was usually set before your best idea turned up. Knowing how the money gets allocated is part of the job, not a distraction from it.

Wanting it and paying for it are different. People will tell you they love an idea in an interview and never open their wallet. Enthusiasm is a signal. Payment is evidence.

Users love products the business cannot afford. Free, generous and heavily supported makes people very happy, right up to the point where the numbers stop adding up. A product has to work for the user and for the business, or it stops existing.

Treat commercial sense as a product skill. The best product call in the world still needs someone to fund it.

Org and ownership

Your org chart is visible in your product. Split the teams one way and the product tends to split the same way. Users feel the seams even when they never see the chart.

Nobody owns the problem between two teams. Each team owns its part and hits its goals, and the user's actual problem lives in the gap. It stays there until someone decides the gap is their job.

You have all the responsibility and none of the authority. The product manager answers for the result without managing the people who build it. So the work runs on influence: clear reasoning and a decision people can repeat back when you're not in the room.

Stop waiting for the authority to arrive. Find the gaps between teams and pick one to own.

Evidence and approval

Every request arrives as a solution, not a problem. Someone asks for a button or a report. The work is finding out what they were trying to do when they asked.

A real problem can still be the wrong problem. It can be true, painful and well researched, and still not the one worth solving now, because it's too small or not tied to anything the business needs.

The loudest voice watched the fewest users. The strongest opinions in a room are often the furthest from the evidence. The people who sat with users tend to speak last, and with more caveats.

Approval depends on who backs it, not what proves it. Bad ideas arrive pre-approved. Good ones need a business case. An idea from the top of the org can skip the questions a new idea from the team has to answer in full.

The better move is to hold every idea to the same evidence bar, including the ones with a sponsor, and to make that bar visible so it's harder to skip.

Politics wins where the evidence stays private. Put it on the table.

Speed, AI and the edge

A working demo isn't a working product. A demo shows the happy path once. A product has to survive real data and the user who does the thing nobody expected.

A team can hit every deadline and still miss the market. Delivery gets measured against the plan. The market doesn't care about the plan.

AI ships faster. It can't tell you what to ship. And your competitors use the same models, so access is not an edge. When everyone can build faster, speed stops being the difference. What's left is the judgement about what is worth building, for whom, and what to leave out.

The faster the build gets, the more the call in front of it matters.

Your level and your career

Your job title isn't your level. Titles mean different things at different companies, and the same title can cover very different scope. What counts is the size of the decisions you make and the results you own. The gap between title and level is hard to see from the inside, which is exactly why it's worth checking.

Loyalty to one company costs you money. The market prices your experience fresh each time you move, and an internal pay review rarely does. That isn't a reason to leave. It is a reason to know what your experience is worth outside.

Good product management is invisible. Bad isn't. When the work goes well, the problems it prevented never happen, so nobody sees them. When it goes badly, everyone does. So make the invisible work visible: write down the calls you made, the risks you took off the table, and what changed as a result.

Your career runs on what people can see. Give them something to see.

Almost none of it is about the product

Read the list again and very little of it is about the product. It's about money, people, power, evidence and time. That's the part of the job the title doesn't describe.

The product is the part you can learn from a book. The rest you learn by getting it wrong, often more than once. Knowing these truths in advance won't make them go away. It will help you spot them sooner and make the call before the system makes it for you.

Download the one-page version and keep it where you plan the next quarter.

Questions people ask

What is the hardest part of being a product manager?
For most product managers, the hardest part isn't the product itself. It's everything around it: budgets set before your idea arrived, problems that fall between two teams, approvals that depend on who backs an idea, and responsibility for results without authority over the people who build them.
Why does product management feel so political?
Because product managers carry responsibility for outcomes without direct authority over the teams, the budget or the approvals. Decisions get shaped by who sponsors an idea as much as by the evidence behind it. The practical answer is to hold every idea to the same visible evidence bar, including the ones that arrive pre-approved.
What does "every yes is a no" mean in product management?
It means time and people are fixed, so every new commitment pushes something else off the roadmap. When a team says yes without naming what it's giving up, the no still happens, it just happens without anyone deciding it. Good product managers say that no out loud, with the reason.
Does AI give product teams a competitive edge?
AI makes building faster, but competitors have access to the same models, so access alone is not an edge. When everyone can ship faster, the difference moves to judgement: deciding what is worth building, for whom, and what to leave out. AI can speed up the build. It can't tell you what to ship.
Is a product manager's job title the same as their level?
No. Titles mean different things at different companies, and the same title can cover very different scope. A product manager's real level shows in the size of the decisions they make and the results they own, which is why it's worth checking your level against the work rather than the title.