Evert Vanderstadt is a Product Engineer at Poppy, the Belgian car-sharing platform. At Poppy, the engineering team works without dedicated product managers. Developers go directly to the people experiencing a problem, work through what’s feasible with them, and own the solution from there.
It’s not the standard setup. But the way Evert talks about his work raises questions that are relevant well beyond it, whatever your role looks like.
Closing the gap between problem and solution
At Poppy, engineers start with the person, not the ticket. Evert meets directly with internal teams, the operations people managing cars, coordinating mechanics, handling the day-to-day logistics, and works through problems with them.
“You sit down with the people that have a problem and figure out how you can help them. And as an engineer you know all the technical stuff, so you can think with them.”
That thinking-with matters. The conversation isn’t just requirement gathering. It’s a collaboration where Evert can reason about what’s technically possible in real time, explore different directions together, and often land on an approach that works better for everyone involved. Fewer translation layers means the signal stays cleaner. What the person needs and what gets built stay closer to each other.
Poppy also structures the work to protect that focus. The team runs on six-week cycles, each built around a small number of meaningful projects. Once a cycle starts, the goal is to finish completely, meaning in the hands of users, before moving on. After each cycle comes a cooldown period for bugs, small fixes, and ad hoc requests. It’s a deliberate rhythm that keeps engineers focused on what matters rather than pulled in too many directions at once.
The model also shapes how Evert handles feedback and requests. His instinct isn’t always to build exactly what someone describes.
“Let them use it and see if they still dislike it. Maybe you think a certain solution is not correct, but once they start using it, it’s actually quite fine.”
The reasoning is straightforward: a user’s idea of the solution is based on what they imagine. Their experience of the actual thing is different. Shipping something, even if it’s not perfect, gives both sides real information to work with. That’s harder to get from a conversation.
Simplicity isn’t the default. It’s a skill.
When asked what the most important skill in his role is, Evert points away from technical ability and toward something harder to define.
“Gathering problem statements in a simple way and solving them simply. Because you can solve a problem in so many ways, but if you start always creating new concepts and new tables in a database, it’s going to get really messy.”
At some point, a product with too many features and too much internal complexity becomes one nobody fully understands, including the people who built it. What Evert describes is a discipline: a resistance to novelty for its own sake. Before reaching for a new pattern or a new abstraction, the question is whether the problem can be solved with what already exists. Often it can.
This also shapes how Poppy thinks about hiring. They don’t hire primarily on technical skill.
“We hire really specifically, more on whether a person has a feeling for understanding people. And very importantly: not being an arrogant person.”
That second part isn’t a throwaway. Someone who assumes they already have the answer stops asking questions. And if you stop asking questions, you solve the wrong thing, probably in the most complicated way available.
AI makes everything faster. That’s the problem.
Evert is direct about what AI has done to how he works. The change has been total.
“I rely on it completely to do my development.”
The efficiency gain is real. He builds more, faster. But something unexpected followed.
“You can do a lot, and then you have five messages from different people: can you do this, can you do this? And they’re like, yeah, it’s really easy to do now. So you start doing five things at the same time.”
The tools removed friction that used to function as a natural filter. When something was hard to build, only the most important things got built. Now that building is fast and cheap, the queue fills with everything. Staying focused on what actually matters, rather than what’s currently easy to do, becomes a harder problem than before.
“Efficiency gain is there. But it doesn’t mean the work becomes less. I feel like I’m even working harder.”
More capacity doesn’t reduce the workload. It expands what people think is possible to ask for.
What this adds up to
Poppy’s model, engineers owning the full problem without a dedicated PM layer, isn’t how most product teams are built. But the pressures Evert describes are not unique to it.
Staying close to actual user problems rather than secondhand interpretations of them. Choosing simplicity when complexity is always available. Protecting focus in a world where execution keeps getting cheaper.
“Creating things and making life easier for my colleagues. That’s what I like.”
Whatever the structure around the work looks like, that orientation is a good one to hold onto.