Your roadmap
is fiction
( and everybody knows it)
Your team is great. Your product is real. But somehow your roadmap is always delayed and "two weeks" means two months.
I help founders and tech leaders
ship predictably.
What changes
Here is what working with me actually looks like:
4 products
Built from idea to market-fit as first product hire (and yes, plenty didn’t make it)
5 days
To the first visible changes in how teams work
18 → 6 months
To ship major releases at one SaaS company
Is this 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 structure to quickly build what is most valuable.
Your team is technically capable, so why does every release feel like a miracle?
Any of this ring a bell:
A backlog that keeps growing but never empties
Deadlines that slip, again and again
A team working hard but but nobody can explain where the time goes
Knowledge scattered across people's heads, Slack threads, and old Notion docs
Spending more time talking about the work than doing the work
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
I’m not the right fit for everyone. And that’s fine.
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 actually change anything
How I work
I don't advise from the side-line. I join your stand-ups, work in your Jira, sit in your Slack channels, and make decisions with your team. Not about them.
That means:
I work in your tools, your rituals, your rhythm
I help you prioritise ruthlessly and build habits that stick without me
And when the structure holds, I step back. Not out.
Typical outcomes:
Founders who stop firefighting and start building
Delivery that moves at the pace you promise your clients
A team that knows what to work on. And why.
This is not a workshop or a 2-day audit. The goal is a team that doesn't need me anymore.
How we work together
Discovery call (free) 30 minutes
You tell me where it hurts, I tell you if I can help. No pitch, no deck.
1
First days
I join the team for a few days. Standups, tools, the works. I'm doing real product work from day one, but mostly I'm figuring out where the mess actually is.
2
The real work
Stay and fix what's causing the chaos: structure, prioritisation, delivery rhythm, team clarity. How deep I go depends on the situation. It evolves as things improve.
3
Transition
The goal from day one is to make myself unnecessary. Good consultants do that. The other kind you already know.
4
Pricing
€800/day
No packages, no retainers, no surprises.
The first engagement is 3 to 4 days and costs €2,400 to €3,200. Think of it as a test run. You see how I work, I see where the problems actually live.
After that, most founders keep me on for 2 to 3 days a week over 3 to 6 months. Roughly what a senior hire costs. Without the recruitment process, the notice period, or the RSZ headache.
Not sure if the budget fits? Just ask. I'd rather have an honest conversation than lose you to a guessing game.
What actually happened
Factry
Factory operating system for industrial clients. ~12 people, bootstrapped, Ghent.
When I joined, a single client implementation had just taken 18 months. Not because the team was bad. The structure was. Standups ran an hour. Knowledge lived in people's heads. Developers sat waiting for each other.
I restructured the rituals, split the team by product area, and introduced a UX-led analysis phase before development started. I didn't do the product work. I changed how the organisation worked so the team could.
The next comparable implementation took 6 months.
Spotto
Belgian real estate marketplace for CIB, the federation of real estate agents. First product hire.
Months of external development had gone quietly nowhere. There was no product function. No one deciding what to build. No way to know if it was working. No shared understanding across teams.
I built that from scratch: a structured way to cut through stakeholder noise, continuous user research, a way to actually measure what was working, and an SEO strategy that took the platform from 10,000 to over 100,000 monthly visitors.
Two years later, Spotto was a recognised platform in the Belgian real estate market with a team that 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 be the reason the team could actually focus.
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 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.
Let’s talk
If you read the "is this you?" section and felt seen, grab a slot.
I work with a small number of clients at a time, so availability changes. If nothing fits your schedule, drop me a mail at bart.pinnock@nimflex.be and we'll figure it out.
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.