Interviewee: F6, Signalen - VNG
Role: facilitator
Date: —
Interviewer: —
Interview Summary
Personas
Project owner, community manager…
Facilitator role
My role, community manager, is essentially that of a linking pin between the community of municipalities and Amsterdam’s product owner. I collect input, facilitate voting on feature priorities, share sprint review updates and newsletters, and make sure questions get answered — either by me or by other municipalities stepping in. The community itself is quite active; it’s not just me posting, others contribute too. I also maintain an overview of all feature wishes, linking them to relevant posts and people so nothing gets lost. Priorities are set based on broad community support and a simple impact-versus-effort logic. Features with little support or high development cost get parked, not dropped — everything gets registered. Beyond the platform itself, I also facilitate reference visits between municipalities and help make connections when one municipality’s solution could be relevant to others.
Facilitator s relation to decision makers project leaders
My role stays focused on the substantive side: facilitating input, sharing information, and connecting municipalities with each other. The financial and governance side — formalizing the cooperation structure, setting up a legal framework, handling payments — sits with VNG and the steering group. I’ll chase people who haven’t paid, but calling budget holders isn’t really my place. The transition from Amsterdam as owner to Amsterdam as participant is still being worked out. A key open question is where the development will sit once it leaves Amsterdam, what role VNG will play, and how funding will work long-term — community contributions alone won’t cover it. The steering group currently has no formal mandate — it advises, but Amsterdam could technically still override it. That’s expected to change as governance is formalized.
First phase start
No response recorded.
Second phase understand
No response recorded.
Fourth phase experiment cocreate
No response recorded.
Fifth phase transfer
New municipalities usually come in through a tender or via VNG, and I give demos together with a colleague. After that, it can go quiet for months before they suddenly go live — they’re not obliged to keep us informed. Sometimes they join through an ecosystem partner, which means the community contribution conversation comes later and the relationship is less clear from the start.
Sixth phase finish
For the longer term, development will continue beyond V2, with things like the shift from machine learning to LLMs already in the pipeline.
Tools used
Connections between municipalities — like which integrations are running where — are tracked in a shared file that everyone can fill in and view. The community is largely transparent; in principle everyone has the same access and can see what’s being shared.
Monitoring progress
the roadmap is being built based on community input — municipalities filled in which functionalities they actually use, which helped prioritise what needs to be in the MVP for migration to be possible. That process also helps Amsterdam step outside their own way of working and see how others operate.
Collaboration
The main collaboration channels are a Teams environment with different channels for Signals 2.0 development, product guidance, documentation, and general discussion. The sprint review keeps everyone updated on what’s being built. The sounding board serves a different purpose — it’s where municipalities share experiences, present how they’ve implemented things, and spar with each other about practical challenges. The community aspect is genuinely valued — municipalities don’t just come for the software, they come for the network. Being able to ask other municipalities how they handle certain situations is something you simply don’t get with a regular supplier. That peer exchange happens both in Teams and through reference visits, where municipalities can visit each other in person to see how things work in practice. I help facilitate those connections, matching municipalities of comparable size and context.
Specific painpoints
Participation in votes and polls is around a quarter of municipalities, which isn’t bad but could be better. Turnover within municipalities makes consistent engagement a challenge. I try to keep everything as transparent and accessible as possible — sharing agendas, summaries, and outcomes in Teams so that even those who weren’t present can follow along. Staff turnover within municipalities is an ongoing challenge. People change roles or leave, and there isn’t always a good handover. We try to ask departing contacts to add their successor, but a proper onboarding process for new community members doesn’t really exist yet, even though there’s quite a lot to get up to speed on.
Room for improvement
Sharing within the community skews towards successes and practical questions rather than failures, though people are generally open about things that aren’t working well. There’s no structured way of capturing lessons learned, and I’d actually like to know more about how community members experience the collaboration — what they feel is missing, what they’d want to see more of — but I wouldn’t know how to organise that right now.
Platform requirements
The main tools are Teams for everything community-related and email for the newsletter and steering group updates. In principle everything needed is already there, though it could be better organised. The product owner in Amsterdam largely relies on me to relay what’s happening in the community — he doesn’t look in himself much.