10 product management lies we all tell
Not malicious lies. The comfortable kind, the ones that let a room move on without anyone having to say the harder thing. I've told most of these myself. Here they are, with what's usually true underneath.
Every one of these has been said in a meeting I was in. Several by me.
They're not lies in the dishonest sense. They're shortcuts, the phrases a team reaches for when the real answer would cost more time than anyone has. Which is exactly why they're worth naming.
1. "Users asked for this."
Three users. Two years ago. One was the CEO's cousin.
Requests are anecdotes, and a handful of loud ones becomes "the market" surprisingly fast. Worse, building whatever gets requested is how teams end up in the Product Death Cycle: ship, silence, ask what's missing, ship that, silence again.
2. "We're data-driven."
Someone made a pie chart in Google Sheets once. It gets referenced in decks to this day.
Data-driven means a decision could have gone the other way depending on the number. If no recent decision was actually reversed by evidence, the phrase is decoration.
3. "We have a well-planned roadmap."
You mean a list of unvalidated guesses made last December about what users might need this year.
A roadmap of features with dates isn't a plan, it's a queue. A real one is a short list of bets and a much longer list of noes.
4. "We talked to users about this."
You showed them mockups and asked whether they liked it. People are agreeable, especially to the person who built the thing.
"Do you like this" gets you a compliment. "Walk me through the last time you had this problem" gets you the truth.
5. "We have great UX."
Everyone internally knows exactly where to click, because they've been clicking there since 2019.
Your team is the worst possible sample. You cannot un-know your own navigation.
6. "We validated this thoroughly."
You asked two colleagues on Slack whether they'd use it.
Internal enthusiasm is the cheapest signal available and the easiest to mistake for evidence. Colleagues aren't customers, and they want you to feel good.
7. "We're experimenting and learning fast."
You spent six weeks building one A/B test on a button colour.
Experimentation isn't a tool you install, it's a rate. If the answer to "what did we learn last month" takes more than a few seconds, the rate is zero. That's the case for starting absurdly small.
8. "We understand our users deeply."
The last time anyone on the team spoke to a real user was four months ago, and it was a support escalation.
Understanding decays. It's a habit, not a state you reach and keep, which is why five conversations a week beats one research project a year.
9. "It'll work, it worked for our competitor."
Their users aren't your users. Also: how do you know it worked? You saw them ship it. You didn't see their retention curve.
Copying a competitor's roadmap means inheriting their bets, their mistakes, and their context, none of which are yours.
10. "This is just an MVP to test the concept."
Your MVP has 47 features and took six months.
At that size it isn't testing a concept, it's a launch with a humbler name. And every one of those features now costs you forever, whether it earns its keep or not.
What to do about it
You don't fix these with a process document. You fix them by making the honest version cheap enough that people reach for it.
Pick one. Just one. If it's number 8, put two customer conversations in the calendar this week and make them recurring. If it's number 1, take the next request that arrives and spend twenty minutes finding the need underneath before it goes anywhere near the backlog.
The tell that it worked is simple: someone in a meeting says "actually, we don't know that yet," and the room treats it as useful rather than obstructive.
If you read this list and recognised your own team in most of it, that's usually a capability gap rather than a people problem, and it's what Product Advisory exists to close.