From playground to product teams: our journey in Product Development

Dit Engelstalige artikel is geschreven door Ann Baranova.

At Voys, we like to experiment. In 2023, we shared how Product Development evolved and restructured its architecture in favor of speed and scalability. That was a huge step forward.

Not long after, we realized that architecture wasn’t the only thing slowing us down. The way we worked together in the Product Development circle (the Holacratic term for team) also needed a rethink.

As a Scrum Master at Voys, I had the chance to be closely involved in this journey — from the early workshops to supporting the first experimental team and helping new teams get started. In this post, I’d like to share our story so far: how the restructure unfolded, what we learned along the way, and where the journey is taking us next.

Challenges in Domain Driven Design

After moving to a microservice architecture (named Holodeck), the ambition was clear to become more of a product organization. The Product Clarity circle was established, the Product Owner role strengthened, and roadmaps introduced.

We also set up nine domains, inspired by Domain Driven Design (DDD), covering things like routing, connectivity, identification, customer relations and others. On paper, this looked like the logical next step. But over time, the structure wasn’t consistently supported or maintained. What started as a solid idea gradually lost traction, and in practice it led to challenges:

• Many domain teams lacked a clear, structured way of working. Some tried elements of Scrum or Kanban, but most weren’t truly agile in spirit.
• Colleagues were often spread across two or three domains at once, which led to shattered focus and little stability.
• Without a cohesive product vision and sustainable backlog management, work defaulted to technical delivery for current customers rather than exploring future value.

As someone put it in a workshop:

Laying the groundwork for change

To tackle these challenges, we knew we needed more than just structure. We hired UX researchers to strengthen discovery, launched a cross-role Product Discovery circle to grow product thinking, and I joined Voys as a Scrum Master to support with the restructure and help set up the first teams.

We also kicked off a restructuring project with a volunteer working group of Product Owners, Developers, Product Coaches, Scrum Masters, and colleagues from Culture and Communications. Together, we aligned on our optimization goals, our change story, what “product” really means for us, and how to define and structure future teams.

Defining product areas turned out to be much harder than expected. No matter how we drew the lines, they didn’t quite fit. So in the end we agreed to start with a shared backlog and form teams that weren’t tied too tightly to product areas.

Enter the notorious Agile Alpacas 🦙

While the bigger structure was still evolving, we didn’t want to wait. So we started a test group what came to be the notorious Agile Alpacas.
This was a group of colleagues passionate about agile ways of working, product thinking, and exploring new approaches together. It also gave them a safe space to try things differently. From the start, the team seemed to nicely gel into a herd — shared values, common motivations, and a strong sense of ownership quickly bound them together.

There was a lot of hype and interest from the rest of the organization, as people were curious to see how such a cohesive team could be built. The Alpacas put a lot of attention into building trust on different levels – using basic Scrum events like Sprint Reviews and Retrospectives, but also through team-building activities, team days, team health checks, hackathons, and even fluffy fun like alpaca tattoos and stickers for everyone.

They also started a trend: soon other teams began naming themselves too – from Scrummy Bears 🐻 to Lucky Lions 🦁 – turning the idea of team identity into something fun and energizing across Product Development.
Through this, the Alpacas became ambassadors of a new way of working – showing what was possible when a stable, multidisciplinary team had autonomy, purpose, and trust.

From domains to product teams

Meanwhile, the working group finalized the bigger picture. The outcome was a shift from scattered domains to stable, cross-functional product teams.

• Some teams focus on specific products or subsystems.
• Others share a common feature backlog to deliver value across the product.
• To keep the codebase healthy, each team also owns a clear maintenance area.

Teams chose their setup in a self-assignment workshop – colleagues signed up for the team they wanted to join and formed on the fly. To kick things off, we set a common ground with agile basics and Scrum training, then brought it to life with a LEGO Serious Play large-scale Scrum simulation.

What we learned along the way

The restructure wasn’t without its bumps – the scope at times felt too broad, the natural resistance that comes with change was there, and progress didn’t always move at the pace we hoped. But what made the difference was the energy and openness of the group, the mix of perspectives, and the willingness to keep learning as we went. Clear communication and regular check-ins kept us on track, and experimenting with the Agile Alpacas gave us a concrete example the rest of the organization could flock around. In the end, it gave us energized new teams and a structure we can build on.

The journey continues

Today, Product Development at Voys looks very different from two years ago. We’ve moved from scattered domains to stable, cross-functional teams with clearer ownership and rhythm. Product Owners guide focus, and backlogs are more transparent and sustainable.

And it’s not just processes that improved – structures and ways of working have evolved too. Teams are more focused, collaboration flows more naturally, and feedback loops are quicker. Regular team health checks are in place and team feedback show that teams feel stronger and continue to grow with each sprint.

Of course, the journey continues. The next steps for us are about building on what we’ve started:

• Developing our agile ways of working further and helping teams grow into high-performing teams.
• Strengthening product thinking so we focus even more on the value we bring to customers.
• Creating more cross-team events to improve alignment, collaboration, and knowledge sharing.

We’re not “done” (we never will be). But the change has already made us faster, more focused and more aligned. The fun part? The journey keeps going, and we can’t wait to see what experiments and learnings will show up along the way.