You keep thinking: the team is capable, the product is real, so why does everything feel harder than it should? But you tell yourself it'll sort itself out after the next sprint. Or the next month. Or the next quarter.
That's usually when founders bring me in.
3
founding teams, first product hire
5
days to first visible change
18 → 6
months in delivery time
This is probably you
You're a founder of a bootstrapped company between 5 and 20 people. You have revenue. You have a team. What you don't have is a product function that works.
Your team is technically capable, but things aren’t moving the way they should.
You recognise some of this:
A backlog that keeps growing but never empties
Deadlines that slip, again and again
A team working hard but getting nowhere
Knowledge scattered across people's heads, Slack threads, and old Notion docs
Spending more time talking than deciding
You don't need another consultant to come in, run a workshop, and hand you a deck. You need someone who gets embedded, helps fix the fundamentals, and stays close.
When to look elsewhere
Í’m not always the right choice for a challenge. If you fall into the categories below, you should probably look elsewhere:
Large corporates looking for a project manager to report upward
Teams that want a methodology imposed on them without context
Founders who want strategy advice but aren't ready to change how they work
What I do
I work with you and your team as an embedded product partner, not as an external advisor.
That means:
I work in your tools, your rituals, your rhythm
I help you prioritise ruthlessly and build habits that stick
I don't disappear after the engagement ends
Typical outcomes:
Founders who spend less time firefighting and more time building
Delivery that actually moves at the pace you need
A team that knows what to work on and why
This is not a workshop or a 2-day audit. It's ongoing, embedded work.
How we work together
1
2
3
4
Discovery call (free)
We talk for 30–45 minutes. I want to understand where the chaos lives and whether I can help. You'll know by the end of the call whether this makes sense.
First days
I join the team for a few days. I’ll be in your tools, your standups, your rhythm. I'm already doing product work, but mainly I'm getting a real picture of where things are. Just enough time for both of us to know if this makes sense and what the next few months should look like.
Embedded engagement
I join the team and do real product work while fixing what's causing the chaos: structure, prioritisation, delivery rhythm, team clarity. The depth of involvement depends on the situation and evolves as things improve.
Transition
The goal from day one is to make myself unnecessary. That means either coaching someone in your team into the product role, or helping you hire the right person. I phase out when the foundation is solid enough to carry on without me.
Pricing
€800/day. No packages, no retainers, no surprises.
The first days cost €2.400 to €3.200 and give both of us a clear picture of whether this makes sense. After that, most engagements run at 2 to 3 days per week over 3 to 6 months, roughly what a senior hire costs, without the long-term commitment.
If you're unsure whether the budget fits, just ask. I'd rather have that conversation than have you guess.
Case studies
Factry
Factory operating system for industrial clients. ~12 people, bootstrapped, Ghent.
When I joined, a client implementation had just taken 18 months. The team was capable but the structure wasn't — standups ran an hour, knowledge lived in individual heads, and developers were constantly waiting for each other.
I restructured the rituals, split the team by product area, introduced a proper UX-led analysis phase before development started, and made sure every project was carried by the whole team instead of single people.
The next implementation was delivered in 6 months. The previous comparable one had taken 18.
Spotto
Belgian real estate marketplace, part of CIB Group. First product hire.
After 9 months of external development that had gone quietly nowhere, I joined 3 months before the first planned release. I couldn't undo what had been built. But being embedded at CIB meant I could get answers to questions in hours instead of weeks, and start building the product function that should have existed from day one.
Two years later, Spotto was a recognised platform in the Belgian real estate market with consistent organic growth, a functioning analytics stack, and a team that actually knew what they were building and why.
Who I am
I started out as a developer. I know what it feels like to sit in a standup with no clarity on why you're building what you're building, or whether anyone has actually thought through what "done" looks like.
That frustration is what pushed me into product work. Not because I wanted to manage people, but because I wanted to remove the noise before it reached the team.
Over time I realised the two things are inseparable. You can do great product work, but if the team can't deliver it because of stress, unclear priorities, or fragmented knowledge, none of it matters. And you can have a high-functioning team that's building the wrong things for the wrong reasons.
That's the problem I solve. Not one or the other. Both, at the same time, from the inside.
I'm based in Ghent. When I'm not doing this, I'm probably outside walking my Weimaraner, da Vinci.
Contact me
Contact me
If you read the "who this is for" section and felt seen, let's talk.
I work with a small number of clients at a time. If you're wondering whether I have availability, just ask.
Fill in the form and I'll respond within 1 business day to schedule a call.
Your Questions, Answered
How do I know if this is the kind of problem you solve?
This usually works best for teams that already have a product and a capable engineering team, but where progress feels slower than it should.
Typical signs are:
the backlog keeps growing but never really empties
deadlines slip or priorities change constantly
product decisions keep escalating to the founder
the team is busy, but it's hard to explain what actually moved forward
If that sounds familiar, you're probably in the situation I usually step into.
What does working together actually look like?
I work inside the team's normal rhythm.
I'm in your tools, your standups, and your planning sessions. I'm reviewing work with engineers, clarifying priorities with founders, and helping the team make decisions faster.
A typical week might include things like:
reshaping the backlog so it reflects real priorities
clarifying what a feature actually needs to achieve
talking to users to validate assumptions
helping the team unblock decisions that have been circling for weeks
I don't observe from the sidelines, I work with the team.
Will this disrupt the team?
Usually the opposite.
The goal isn't to impose a new framework or slow things down with process. It's to remove friction so the team can focus on building.
Most changes happen gradually inside the team's existing rhythm. Over time you should see fewer escalations, clearer priorities, and meetings that actually end with decisions.
What exists at the end that didn't before?
A few things tend to become visible:
a backlog that reflects real priorities rather than every idea anyone ever had
a team that can run its own rituals without needing someone to facilitate them
decisions about what to build next that the team can explain clearly
fewer product questions bouncing back to the founder
In short: a product function that runs without constant intervention.
How do we know it's working?
You'll usually feel it before you can measure it.
Escalations become less frequent. Meetings get shorter. Decisions start sticking instead of being revisited every few weeks.
Within the first few weeks the team usually starts asking better questions and unblocking themselves faster. We'll agree on a small set of indicators at the start so there's something concrete to point to as things improve.
How do we know when it's done?
When the team no longer needs me to run well.
That usually means someone internally has grown into a product role, or you've hired the right person to take it forward.
I don't phase out on a fixed date. I phase out when the foundation is solid enough for the team to carry on without me.
Why not just hire someone full-time?
You might, and I'll help you do that when the time is right.
But hiring into a chaotic product setup rarely works well. A new product manager often spends months just trying to understand what's broken before they can start fixing it.
My role is to stabilise the system first. By the time we're done you'll know exactly what kind of product person you actually need, which makes that hire far more likely to succeed.
What if we start working together and it turns out not to be the right fit?
That's why the first step is always small.
We start with a short engagement to understand the situation and see whether the work is useful for your team. If it's not helping, we stop.
No long commitments, no complicated contracts.