Case studies
Factry
Factry builds FactryOS, a factory operating system that gets implemented on-site at industrial manufacturers. When I joined in 2021, the company had grown from 3 to 11 people in under two years. Fast growth, but the processes hadn't kept up.
The situation when I arrived
The daily standup was scheduled for 15 minutes. It consistently ran an hour.
The reason was structural. Every developer was assigned to a separate client project, so every standup was effectively a series of one-on-one status updates. While one person talked, eight others stood waiting. Then the next person talked. The same pattern repeated in sprint planning and retrospectives. There was no sprint review at all.
The one frontend developer had it worst. They were being pulled across every project, context-switching constantly, never able to build momentum on anything.
The knowledge problem was just as serious. Because each developer worked alone on their project, everything lived in individual heads. If someone got sick, their project stalled. There was no shared understanding of the codebase, the clients, or the decisions that had been made.
Factry had just completed a major implementation at a steel factory. It had taken 18 months. A new implementation was coming: Jacques IJs, a Belgian ice cream manufacturer wanting to replace paper-based production workflows with a digital system. The budget was 12 months.
Yves, one of the founders, was running product for the OS alongside managing the company. He was visibly frustrated at the end of that first standup. So was everyone else.
What I changed
The rituals
I restructured the standup around the board, not around people. Instead of going person by person, we walked the active items and asked one question per card: is this blocked? If not, move on. The standup dropped back to 15 minutes.
I removed the founder from the standup. This sounds small but it matters. When the founder is in the room, developers self-censor and defer. Questions that should be asked in the moment get saved for the next meeting. Removing that dynamic forced the team to solve problems themselves.
I trained people to ask questions immediately, in Slack or in person, instead of banking them for the next planning session. The cost of a blocked developer waiting 24 hours for an answer is enormous. The cost of a 2-minute Slack message is nothing.
I introduced sprint reviews, which the team had never done. Showing working software at the end of each sprint creates a forcing function for actually finishing things, and it gives the founders a regular, honest picture of progress without needing to attend every standup.
The team structure
Factry had two distinct products: FactryOS (the operating system implemented at client sites) and Factry Historian (a data historian for factories). These required different skills, different client relationships, and different ways of working. I split the team into two focused groups, each with their own rituals. Developers stopped sitting in meetings irrelevant to their work.
I also changed how projects were assigned. Instead of one developer owning one client project alone, every project was shared across the team. The primary developer still had the deepest knowledge and the fastest output, but at least two others knew the codebase well enough to step in. When someone was sick or on holiday, nothing stopped.
The analysis phase at Jacques IJs
The previous implementation had taken 18 months partly because requirements were discovered during development rather than before it. Developers would build something, show it to the client, and find out it wasn't quite right. Then rebuild. Then discover something else.
For Jacques IJs I came in early, before development started, and spent time on the factory floor with the people who would actually use the system — machine operators, production planners, the IT manager. I wanted to understand their actual jobs: what they did, in what order, what frustrated them, what would make their day easier.
I turned that into UX prototypes and ran them back through the factory workers. They gave detailed, specific feedback immediately — because they could see and react to something concrete rather than trying to imagine an abstract system. The operators told us what worked, what didn't, and what we'd missed entirely. We refined the designs before a single line of code was written.
The effect on the development team was significant. Instead of starting a sprint with a vague requirement and discovering edge cases mid-build, they started with clarity. Decisions that would previously have surfaced as blockers in week six were made in week two, on paper, in a feedback session.
One developer pushed back. He wasn't happy that so much had been decided before he could weigh in on the technical approach. That tension is real and worth acknowledging — there's a balance between upfront clarity and leaving room for technical judgment. But the overall improvement was substantial enough that we kept the approach.
The product frameworks
For the Historian product, I introduced outcome-based release planning with Jeroen, the other founder who was running product there. Instead of planning releases around features, we planned around what we wanted users to be able to do differently. This sounds like a small reframe but it changes everything — it forces you to ask whether you've actually delivered the outcome, not just shipped the code.
I introduced user story mapping as a tool for analysing and slicing new releases. This gave Jeroen a structured way to decide what to build first, what to defer, and how to sequence delivery so that clients got value early rather than waiting for everything to be finished.
I introduced user personas for both teams so that developers could make day-to-day decisions — the small UX calls that never make it into a ticket — with a real person in mind rather than an abstract user.
I moved the backlog from Notion to Azure DevOps and introduced kanban thinking and flow metrics so the team had a shared, honest view of what was actually in progress versus what was waiting.
The result
The Jacques IJs implementation was delivered in 6 months. The previous comparable implementation, at a steel factory in Sweden, had taken 18 months.
That's not because the team worked faster or harder. It's because they started clearer, shared knowledge better, and spent less time waiting for each other.
Factry published the Jacques IJs case study on their own blog. The client described operators who "really love working with the MES" and a factory floor running with less stress and more peace of mind. That outcome started with understanding what operators actually needed before anyone wrote code.
The frameworks and team structure I introduced at Factry are still in place. That's the only metric that matters for this kind of work.
factry.io — Factry is a Ghent-based industrial software company.
Further reading: Factry published their own account of the Jacques IJs implementation here, and wrote about the team restructuring and scrum approach here.
Spotto
Spotto is a Belgian real estate marketplace, developed for CIB, the professional federation of Belgian real estate agents. Before I joined, the platform had been in external development with Sopra Steria for somewhere between six and nine months. It was quietly going nowhere.
The situation when I arrived
The platform had been in external development for several months before I joined. There was no embedded product function — no one close to the business whose job it was to translate market knowledge into product decisions, answer developer questions fast, or make sure what was being built was actually what was needed.
I was that person from day one.
Being embedded at CIB changed the speed of everything immediately. Developer questions that had previously taken days or weeks to answer I could resolve in hours — because I was in the building, understood the business, and could do the research myself when the answer wasn't obvious internally.
The first release was delayed. The platform wasn't ready and there was no shortcut around that. But from that point, I had a clear picture of what needed to exist and started building it.
Building the product function
With a small development team and a large number of internal stakeholders, I built a proper product process from scratch.
The stakeholder problem was the first thing to address. CIB is a federation with many departments and opinions, and everyone had views on what Spotto should do. I introduced two tools that changed the dynamic considerably.
The first was the opportunity-solution tree, a framework by Teresa Torres that maps real user problems to potential solutions. When a stakeholder came with a feature request, I could trace it back to the underlying problem they were actually trying to solve — and often find a better solution than the one they had proposed. It also created a shared map of what we were trying to achieve, which made prioritisation discussions less political and more productive.
The second was a value-versus-effort matrix for ranking potential solutions. When stakeholders asked why we were building one thing instead of another, I could show the reasoning transparently. That reduced the noise considerably and built trust in the process.
I introduced KPIs aligned to business goals, which gave stakeholders something to agree on before discussing solutions. It is much easier to align a room around "we want more agents actively listing properties" than around which specific feature achieves that. The KPIs created a shared language for decisions.
I started continuous discovery with actual platform users — three feedback sessions per week, every week. This meant product decisions were grounded in real user behaviour rather than internal assumptions. When a stakeholder insisted they knew what users wanted, I usually had recent, direct evidence to work with.
Stabilising and growing the platform
Once the platform was live and stable, I turned to growth.
I learned SEO properly and started working with an external SEO agency as an informed partner rather than just a client. We implemented technical and content SEO across the platform. Organic traffic to commercial pages doubled within six months.
I built a product analytics stack that tracked the full conversion funnel — from search to property view to contact. For a B2C marketplace with many entry points and open user journeys, this is genuinely complex to instrument correctly. It had never existed before. For the first time, we had a clear picture of where users were dropping off and why.
I introduced sprint reviews and used them to close the gap between the development team and the internal marketing team. Developers demonstrated what they had built in plain language. Marketing stopped being surprised by releases and started producing content aligned with what the product was actually doing.
I built a data pipeline connecting every listing to address-level property data and historical publications. This made serious data analysis possible for the first time. I used it to research the relationship between EPC scores and property values — work that was picked up by the Belgian press and referenced in a political context.
What this story is actually about
Spotto is a different kind of story than Factry. There was no clean team to restructure. The starting conditions were difficult and the environment was complex — many stakeholders, limited development capacity, a platform that needed both stabilising and growing at the same time.
What I built was a product function that didn't exist before: a way of deciding what to build, a way of understanding users, a way of measuring progress, and a way of communicating across teams. Not from a playbook but from the ground up, adapted to what the situation actually needed.
Two years later Spotto was a recognised platform in the Belgian real estate market with consistent organic growth, press coverage, and internal teams that understood what they were building and why.
spotto.be — Spotto is a Belgian real estate marketplace for CIB Group.