Recognising the Scaling Triggers

Dominique begins by identifying the signals that indicate a company has entered the scaling stage. These are not abstract metrics. They are concrete organisational symptoms that most product leaders will recognise immediately.

Feature requests from customers start contradicting each other at a rate the existing prioritisation process cannot handle
New hires take longer to become productive because the product knowledge is stored in people's heads rather than in documentation
The engineering team's velocity appears to decrease even as the team grows, because coordination costs are rising faster than capacity
Customer churn increases not because the product is bad but because different segments need different things and the product is trying to be everything to everyone

At Vertuoza, these signals appeared almost simultaneously. Dominique shares that the company's initial reaction was to work harder, to hire more people, and to try to maintain the startup pace. This made things worse. More people without better structures meant more coordination overhead, more conflicting priorities, and more frustrated engineers.

“Scaling is not about doing more of what worked before. It is about doing different things entirely. That realisation cost us six months we could have saved.”
- Dominique Pellegrino

Restructuring the Product Organisation

The core of Dominique's talk describes how Vertuoza restructured its product organisation to address the scaling challenges. The changes were not cosmetic. They involved fundamentally rethinking how the company made product decisions, how teams were organised, and how success was measured.

From one team to three squads

Vertuoza moved from a single product team that handled everything to three dedicated squads, each aligned to a specific value stream within the construction workflow. One squad focused on project planning, another on site execution, and a third on financial tracking and invoicing. Each squad had its own product manager, its own backlog, and its own customer segment to serve. The squads shared a common platform layer but operated with significant autonomy in their respective domains.

Dominique is candid about the cost of this restructuring. For two months, velocity dropped as teams adjusted to new boundaries, new communication patterns, and new ways of making decisions. Some engineers resisted being assigned to a single domain when they had previously worked across the entire product. Two senior developers left because they preferred the generalist model of the growth stage.

warningThe temporary velocity dip

Dominique warns the audience that any significant organisational restructuring will cause a temporary drop in output. This is expected and should be planned for. The mistake is to reverse the restructuring because of the dip. The companies that push through the transition emerge with higher sustained velocity. The companies that retreat remain stuck in the scaling trap.

By the fourth month after the restructuring, Vertuoza's total output had exceeded their pre-restructuring levels. More importantly, the output was better aligned to customer needs because each squad had deep context on its specific segment rather than shallow context across the entire product.

Lessons from Scaling in Construction Tech

Dominique draws lessons specific to building product for traditional industries, which resonates strongly with the Belgian audience where many tech companies serve sectors like construction, logistics, manufacturing, and healthcare that are in the early stages of digital adoption.

In construction tech, the end users are often people who are not digitally native. Site managers, foremen, and subcontractors may have limited patience for complex software interfaces. This creates a specific scaling challenge: as the product grows in capability, it must not grow in complexity for the end user. Dominique argues that this constraint is actually a gift because it forces the product team to be disciplined about information architecture and interaction design in ways that B2B SaaS companies serving tech-savvy users can sometimes avoid.

check_circleDesign for the least technical user in your customer base, not the most enthusiastic champion. At scale, adoption depends on the people who did not choose your product
check_circleInvest in onboarding infrastructure before you think you need it. The gap between a product that works for power users and one that works for everyone is the gap between growth and churn
check_circleBuild feedback loops that reach beyond the buyer to the actual end user. In B2B, the person who signs the contract is rarely the person who determines whether the product succeeds
check_circleAccept that scaling in traditional industries is slower than in tech-native markets, and adjust your investor expectations accordingly

Dominique notes that the Walloon and Belgian construction industry has been particularly receptive to digital tools in the past three years, driven by regulatory changes around building permits and energy efficiency reporting. This regulatory tailwind creates both opportunity and pressure for construction-tech companies like Vertuoza to scale their products responsibly.

Preserving Culture Through the Scaling Transition

Dominique ends with a topic that is often overlooked in scaling discussions: culture. As the organisation grows and restructures, the informal culture that defined the early team risks being diluted or lost entirely. New hires do not share the founding stories. Remote team members do not absorb values through proximity. The company's identity becomes something that must be actively maintained rather than something that exists naturally.

At Vertuoza, Dominique introduced two practices to preserve product culture during the scaling phase. First, every new product team member spends their first week visiting construction sites with customers, regardless of their role. This creates a shared understanding of the customer's world that no documentation can replace. Second, the company holds a monthly product retrospective where the entire product organisation reviews not just what they shipped but why they made the decisions they made.

lightbulbCulture is a product too

Dominique frames company culture as a product that requires the same intentional design, iteration, and maintenance as the software itself. If you let culture happen by accident during the scaling phase, you will get a culture that reflects the chaos of scaling rather than the values that made the company worth scaling in the first place.

Product Management in Scaling Stage

Original Presentation Slides

Recognising the Scaling Triggers

Restructuring the Product Organisation

From one team to three squads

warningThe temporary velocity dip

Lessons from Scaling in Construction Tech

Preserving Culture Through the Scaling Transition

lightbulbCulture is a product too

This article is for Consortium members

Key Takeaways

Related Editorials

Product Management in Growth Stage

Building Trust: Collaboration in Product Teams