The link between the car and the F2 team: 8X what product owners can learn from F2 driver Richard Verschoor

At first glance, the worlds of software development and motorsport may seem far apart, yet they share striking similarities: a strong focus on teamwork, data-driven decision-making, and the ability to perform under pressure. For decision-makers guiding digital transformation, collaborating with nearshore teams, or managing complex projects, the approach used in Formula 2 offers valuable insights that can also be applied within the IT sector.

For the second year in a row, we are a proud partner of Richard Verschoor, the F2 driver who has been competing in Formula 2 since 2021. Racing for MP Motorsport, he is in the midst of the championship battle. Richard operates in a world where speed is literal and where innovation and teamwork determine the difference between winning and losing. His role within the team – serving as the link between the car and the engineers – can be compared to that of a product owner in IT. We recently spoke with Richard to explore the lessons his experience as a ‘product owner’ in Formula 2 can offer and how they may be applied in our IT context. How does he approach themes that will likely feel very familiar to any product owner?

1. Innovation as a survival strategy

Standing still means falling behind – a principle that applies equally to motorsport and technology. “For us as a team, it is essential to keep up with developments in the world,” Richard explains. “We must continue to innovate. A racing team that fails to do so will lose its competitive edge and fall behind.”

This urgency around innovation is immediately recognizable in the IT sector. Whereas F2 teams innovate within strict technical regulations, software developers operate within budgetary, technical, and compliance constraints. Developing innovative solutions is key to gaining a competitive advantage in the market. As a product owner, you must be able to operate in an environment where continuous renewal, acceleration, and improvement are encouraged. Your role is to enable and support your team in this process.

2. Data is key 

Formula 2 teams measure every variable on the track. Richard explains: “All the data generated during training sessions and races is recorded and can be analyzed afterward. I cannot mislead my race team, because they can see everything I have done on the track.”

The importance of data in F2 can be directly compared to the IT sector. Teams collect data points – such as cornering speeds and braking times – to ultimately achieve faster lap times. This process begins with simulations during race preparation. The car is continuously optimized, and based on the characteristics of the circuit, the best configuration is developed. In free practice, the first race data is added and analyzed, leading to adjustments in the car’s setup and overall strategy. The same process is repeated after qualifying and the sprint race.

This iterative approach closely resembles software development: something is built, tested, evaluated, and then improved further. For this cycle to be effective, access to key data points is essential, along with clear communication with stakeholders and a shared objective. This is exactly what product owners – whether Richard in F2 or a product owner in a development environment – deal with on a daily basis.

3. Speed and prioritization

Both speed and prioritization are critical. The approach is straightforward and effective: “It always starts with the question: are there problems? If so, that becomes the priority.” This principle – solving problems first before moving on to improvements – is directly applicable to incident management and planning new software releases.

Richard explains: “If the differential is not set correctly, it means the entire rear of the car has to be dismantled, which is a lot of work for a mechanic. Even though we have several people available for this, it still takes at least an hour to complete. So if we only realize after 2 p.m. that the differential isn’t adjusted properly, it will be impossible to fix it before qualifying. There is definitely time pressure involved.”

Product owners will recognize this dilemma immediately. Just as Richard must make choices when faced with competing priorities, product owners often encounter similar situations: a critical bug discovered late in the sprint, or a technical issue that blocks the entire team. The questions are the same: where do you focus, what matters most, and what solution minimizes negative impact for users?

The time pressure Richard describes is part of a product owner’s daily reality. A production incident on Friday afternoon with a release scheduled for Monday forces difficult decisions. Just as Richard’s mechanics need an hour to dismantle the car, a development team requires time to build a proper solution. A skilled product owner communicates this clearly to stakeholders: will you accept a one-day delay with a solid fix, or a quick patch that may cause further issues later and require urgent attention?

Remaining calm under pressure, managing multiple and sometimes conflicting priorities, and ensuring that all stakeholders are aligned is essential. Keeping the end goal in clear view is of utmost importance.

4. The combination of specialized roles and flexibility makes the difference

In F2 racing teams, success depends on specialized roles and effective collaboration – just as in modern software development. Richard explains: “In our team, we have four engineers, each with their own area of expertise. We also have a chief engineer, two performance engineers, and a data engineer who monitors all the car’s data.” This structure, where every expert has a defined responsibility, is comparable to software teams with frontend and backend developers, DevOps engineers, and data scientists.

For product owners working with such diverse teams, it is essential to be able to “speak the language” of each specialist. Just as Richard must communicate with engineers from different disciplines, a product owner must be able to engage with stakeholders across various domains – from technical architects to business analysts, and from compliance officers to end users. This requires a broad understanding of all project areas, without needing to be the deepest expert in each one.

Richard highlights the importance of knowledge sharing and flexibility: “One person is better at changing a differential, while another is more skilled at replacing something else. If someone is out sick, their work still needs to be done.” In software teams, this kind of flexibility is supported by T-shaped developers – specialists with a broad foundation who can step in where needed. A product owner working with T-shaped developers can rely on a team that adapts quickly to shifting priorities or unexpected absences.

Ongoing knowledge exchange is vital for team continuity, especially under pressure. An effective product owner facilitates this through regular demos, thorough documentation, and cross-training sessions. By staying informed –from technical architecture to business requirements – the product owner can move fluidly between different perspectives and ensure all stakeholders have access to the same information. Just as Richard’s team must continue functioning when a specialist is unavailable, a software team must be resilient enough to ensure delivery despite unforeseen challenges.

5. Collaboration and trust as the foundation

The relationship between the driver and the engineer is crucial, and Richard compares it to the connection between a product owner and a development team. “It’s about teamwork. In a racing team, the relationship between driver and engineer is extremely important – if that bond isn’t strong, you’ll never work well enough together.”

Just as in software development, open communication and mutual trust form the basis for success. Trust must be built; it is not something that can be taken for granted. Richard describes his experience: “At first, my engineer questioned everything I said and didn’t believe me. He always wanted to wait for the data to verify everything. The turning point came when I gave feedback about damage that wasn’t immediately visible. When he later saw that I was right, he realized I knew what I was talking about. For me, trust is also about proving yourself. But if you consistently do what you say and provide good feedback, then trust develops.”

For product owners and their teams, the same principle applies. Credibility is built through consistent delivery, transparent communication, and actively encouraging feedback. A good product owner fosters a culture where team members feel safe to give and receive feedback openly and constructively. This means not only creating space for opinions and ideas but also ensuring that dialogue remains respectful and focused on improvement. In this way, a shared foundation is built where everyone knows that what is said is also heard.

At NetRom, we actively support this process. In our daily stand-ups, we create structured moments for open communication, where issues, progress, and dependencies are discussed directly. In addition, we provide our Romanian developers with training on Dutch communication styles: direct, open, and straightforward. These cultural trainings make collaboration smoother, reduce misunderstandings, and help feedback to be both given and received more effectively.

Like blended development teams, F2 teams do not always collaborate physically in the same place. “I often consult with engineers over the phone,” Richard notes. “Once I called an engineer and he turned out to be on holiday. He happened to be working on a car setup while enjoying his vacation.” This kind of dedication and flexible way of working demonstrates that physical presence is less important than commitment and professional discipline. For a product owner, the same holds true: it is not about whether the team sits together, but whether there is trust and a shared understanding of the common goals.

6. A strong team spirit is essential

Maintaining a strong sense of team spirit requires conscious leadership. Richard describes his approach: “I find it important to build a good relationship with the mechanics. I often talk with them and give them team shirts. I do a lot to show that I appreciate their work.”

This investment in relationships pays off, especially when results are positive. What Richard calls “one big family” is also recognizable at NetRom. For us, teamwork takes precedence over individual success: we celebrate together when we successfully complete a project or deploy a complex release without issues. For example, teams in both countries will buy cake and share it during an online team meeting. These moments of pride not only strengthen team bonds but also make it clear how each person’s contribution directly supports the collective result.

At the same time, trust and a strong culture – areas where a product owner plays a significant role – also provide a positive environment during setbacks. Reviewing together why something did not go as planned, or why deadlines were not met, creates opportunities for improvement. Problems and mistakes are seen as chances to learn and enhance collaboration. This makes teams more resilient and ensures that the atmosphere remains constructive, even under pressure.

By consciously celebrating successes and analyzing setbacks together, you build a culture where everyone understands: we win together, we learn together, and we grow together. This mindset creates the same strong cohesion found in close-knit Formula 2 teams – a prerequisite for performing at the highest level.

7. Cultural diversity as an advantage

Like many blended development teams, modern Formula 2 teams are internationally composed. Richard shares his experiences with cultural differences: “Last year I had an Italian team. This year I have a Dutch team, but all my engineers are Italian, so by now I know how to work with Italians. But when it comes to cultural differences, we Dutch are quite direct. So sometimes I have to be careful not to come across too forcefully.” He describes how Italians can be passionate and quick to stress, while the Dutch tend to communicate more directly and rationally. As Richard puts it: “As long as we treat each other with respect, we always find a good solution.”

The same dynamic is visible in international IT projects. Most teams consist of people with very different backgrounds and nationalities – a trend that continues to grow. In nearshoring, the field in which NetRom operates, our Romanian teams work with Dutch clients. Even though we actively introduce our teams to Dutch practices, different communication styles and work cultures come together. This requires openness and adaptability on both sides but can also be complementary and enriching. The product owner plays a key role in creating an environment where these dynamics are well managed.

A concrete example of the strength of cultural differences is Richard’s chief mechanic: “He is Finnish and has a strong work ethic. He is used to always giving his all. He is always ready, you never hear him complain. His attitude is good for the atmosphere in the workplace.”

When cultural and physical distance are factors, facilitating face-to-face meetings helps. Getting to know each other better on location builds a strong foundation of mutual understanding. This ensures that cultural differences contribute positively to collaboration and lead to more innovative solutions.

When managed effectively, cultural diversity is not a barrier but a strength: the combination of different perspectives, work styles, and communication approaches results in innovative solutions and better-performing teams.

8. Relevant experience is invaluable

Richard’s perspective on setbacks offers important insights. “I had two rather difficult years in Formula 2. But because those years were so challenging, I wanted to fully understand the reasons why things were not going well.” His curiosity about the root causes of problems highlights the difference between teams that learn and grow from setbacks and those that are held back by them. “During that process, I learned a lot about teamwork—about communication with the team, but also about all the technical aspects of the car.”

This experience – learning from setbacks and recognizing patterns – is highly valuable for IT teams. For a product owner, it is useful to assemble a team that includes both less experienced and highly experienced developers. This creates a balanced mix of speed, quality, innovation, and out-of-the-box thinking. At NetRom, we follow this approach and ensure that every team includes at least one senior developer.

On average, our developers stay with us for more than 12 years. This long tenure enables them to build in-depth domain knowledge in the sectors where our clients operate. The combination of technical expertise and domain-specific understanding strengthens our teams and sets us apart from many competitors.

When projects go through challenging phases – such as technical obstacles or shifting client priorities – this accumulated knowledge provides the confidence to move forward and develop solutions that are well suited to the client’s context.

Lessons from Formula 2

The lessons from Formula 2 racing demonstrate that excellence emerges from the right combination of talent, technology, and teamwork. For product owners, Richard’s experience provides concrete guidance: from data-driven decision-making and effective prioritization to building trust in multicultural teams and learning from setbacks. As in F2, every detail matters, and the right collaboration makes the difference between a strong performance and a victory.

Our approach

The principles for successful collaboration found in Formula 2 are also at the core of how we work at NetRom Software. We have built our nearshore development teams around the same values: data-driven decision-making and optimal collaboration. The combination of extensive IT expertise, strong focus on soft skills, deep domain knowledge, and long-term practical experience enables our teams to perform at the level of a successful F2 team. These are the ideal building blocks for any product owner looking to accelerate progress on their roadmap.

Full speed ahead to success?

Curious how your organization could benefit from a high-performance nearshore team working according to this proven approach? Get in touch with us via the form below for a free consult.