Twenty years in, and I still see the same caricature everywhere:
Product manager = the person who "takes the requirements from the customer and gives them to the engineers."
A human translator. A glorified ticket-pusher.
That's not product management.
That's project coordination wearing a product hat.
If that's what you think a PM does, you'll ship a lot of features that nobody actually needs.
You'll keep the trains running on time — straight into the wrong destination.
I see this misunderstanding on LinkedIn constantly.
People proudly declare that product used to be "Features → Roadmaps → Delivery."
No. That was never what product was supposed to be about.
Product management, done right, is first-principles thinking.
It's detective work.
You keep asking "why" until you get to the root problem.
80% of the real work happens before the ticket (or a line of code) is even written.
Once you truly understand the problem, the solution often becomes obvious.
A couple of weeks ago during a mentoring session, I found myself explaining exactly that to my mentee:
"Think of yourself as a detective.
Your job isn't to build what they say they want.
Your job is to figure out what they actually need."
That single sentence sums up the entire philosophy — and it's the antidote to the "feature courier" trap so many teams are still stuck in.
How it plays out in real product work
I've seen the damage when this step is skipped.
Stakeholders hand you a list of features.You dutifully ship them. Six months later nobody uses half of it, the team is burned out, and the business hasn't moved the needle.
The classic Henry Ford example everyone knows (but still ignores):
"If I had asked people what they wanted, they would have said faster horses."
Customers can describe their pain. They rarely know the right solution.
That's our job.
At Revy Autos we started with "we need a marketplace for cars."
If I had accepted that at face value, we'd have built another classifieds site.
Instead we kept digging until the real problem surfaced:
too many people wasting each other's time
trust and speed of credible matching
Those insights became the underlying principles for the entire product design.
The same lens, everywhere else
This isn't just an MVP trick. It's how I operate now — full stop.
- Client onboarding → I dig past "we need a roadmap" to what success actually looks like in 12 months.
- AI decisions → Same rigor: what exact problem are we solving, or are we just chasing the shiniest toy?
- Tool selection → What job are we really hiring this tool to do?
Why this becomes a superpower
Once you internalise first-principles product thinking, you stop reacting to noise.
You stop building the wrong thing really well.
You stop wasting political capital on battles that don't matter.
Instead you deliver clarity — first to yourself, then to the team, then to the business.
That clarity is what separates the product leaders who consistently ship impactful work from the ones who just keep the trains running.
It's repeatable. It's teachable. And it works whether you're defining an MVP, choosing a tool stack, onboarding a client, improving team execution, etc, etc, etc — there is no limit to where you can apply this rigor.
This is going to be a recurring theme here, because it's the single most reliable way I've found to cut through noise and deliver real results, every single time.