Shipping features isn’t the job. Solving problems is
Three lessons on product management from Laurens De Jonghe.
The PM role is one of the most debated jobs in tech. Everyone has an opinion on what it should be. Fewer agree on what it actually takes. We sat down with Laurens De Jonghe for an honest conversation about the craft, the hard lessons, and where the role is heading. What came through might challenge a few assumptions.
Your job isn’t to ship features. It’s to solve business outcomes
We spent some time talking about what it actually takes to do the job well. With plenty of skills worth mentioning, one stood out for Laurens above the rest.
“Understanding customer problems and linking them to the business outcome of the company.”
Simple to say. Hard to actually do. And the place where most PMs lose the thread.
The trap is seductive. There’s always a backlog to groom, a sprint to fill, a stakeholder asking for something. It’s easy to spend your days in execution mode, writing tickets, running standups, following up on delivery, while telling yourself you’re doing the job. But Laurens draws a sharp distinction between shipping features and creating value.
Every feature idea, every piece of customer feedback, every request from sales gets filtered through the same question: does this connect to a real business goal? That could mean reducing churn, expanding into a new market, or helping customers close deals faster. The specific goal doesn’t matter as much as the discipline of always asking whether there is one.
“As a product manager, it’s really about defining the outcome and building the right solution for it.”
A book that resonated with him on this is Melissa Perri’s Escaping the Build Trap. The core idea: product teams that just build and build, without anchoring to outcomes, become feature factories. Fast, busy, and ultimately not moving the needle.
As AI makes it easier than ever to ship things quickly, this kind of discipline only becomes more important. “You can build everything, but if you do not build something that a customer needs, it has no value.”
Honesty is a strategy, not just a habit
When we asked what he’s learned from being a PM, honesty came up before anything else. For Laurens, it’s a practical skill that requires judgment about when to say what, and to whom.
Complete honesty can backfire. If you share your roadmap several months in advance there’s a risk of creating promises you may not be able to keep and to set customers up for disappointment.
His approach isn’t to withhold. It’s to communicate at the right level of abstraction. “Describe the area, not the solution.” You can tell sales you’re working on lead identification without committing to a specific feature or release date.
The same logic applies internally. If a solution is wrong, say it. If engineering is taking longer than expected, say it. “Be honest, even if it’s not the right solution or engineering takes too long or the impact is not there.”
And then there’s the version of honesty that’s hardest in practice: saying no. “Everyone is asking about a feature, or whether you can solve this. And as a product manager, you have to say no.” It’s how a PM protects the focus of the team and keeps the roadmap connected to what actually matters.
The PM role is expanding, not disappearing
There’s a lot of noise right now about AI replacing product managers. Teams are experimenting with the capabilities of vibe coding tools, using them to build and ship new features at speed. In Laurens’ experience, these tools are useful for prototyping and testing, less so as a replacement for real design thinking.
But his broader point isn’t about the limitations of specific tools. It’s about what happens to the role as they improve.
“An engineer will become more of a product manager, and a product manager will become more of an engineer.”
The gap between writing code and defining what to build is narrowing. That changes the job. More prompting, more reviewing, more technical fluency. But Laurens is clear on what doesn’t change: the importance of understanding what customers actually need.
“A customer cannot always translate their problems into outcomes. That’s still the most important part of product management.”
When building is fast and cheap, the bottleneck shifts entirely to judgment. What is worth building, for whom, and why. That’s not something a coding tool answers. It’s what a good PM does.
It always comes back to the problem
Nobody knows exactly what the PM role looks like in five years. The tools are changing, the boundaries between disciplines are shifting, and the expectations on product people are evolving.
What isn’t changing is the question every PM still has to answer: what does this person actually need, and are we building the right thing for it?
“You have to understand the problem from A to Z. Go visit the people experiencing it.”
The tools will keep improving and the role will keep shifting, but the PMs who stay curious about the people they’re building for will always have a foundation to work from.