Software development in automotive OEMs—particularly within traditional ones—remains a noticeable gap in the adoption of modern product thinking. While the industry has made strides in this direction, especially with the emerging automaker startups, many organisations still rely heavily on project-based structures and delivery-focused mindsets, often missing the opportunity to drive value through iterative, outcome-oriented development.
In this article, I share some thoughts shaped by my experience in automotive engineering and my long-standing interest in product strategy. I explore how established product management methodologies—especially those grounded in Agile and customer value—can be adapted to the complex realities of automotive software. I also highlight recurring mistakes I’ve seen OEMs make in their attempt to adopt product practices, and why these efforts often fall short without structural alignment and mindset shift.
Understanding the Boundaries of Product Thinking in Automotive
Admittedly, not all principles of digital product management neatly apply to the world of automotive software. The development of embedded and control software for vehicles must meet strict legislative, safety, and functional requirements—many of which are non-negotiable and exist independently of user stories or product-market fit. Features that ensure fault-free operation, enable compliance, and integrate tightly with vehicle hardware are essential, regardless of perceived customer desirability. In the case of well-established luxury brands, much of the value proposition is already embedded in the brand identity and aesthetic design language, which further complicates the traditional product discovery process.
However, even within this complex environment, product thinking remains highly relevant. It offers a structured approach to reducing waste, curbing unnecessary complexity, and aligning development efforts with actual customer value. Applying a product lens can help OEMs make more disciplined, hypothesis-driven decisions—particularly at the early stages of defining a new vehicle line. Without clear assumptions around customer desirability and long-term user engagement, even minor misjudgments can result in significant financial inefficiencies. Product management doesn’t replace regulatory rigor or technical excellence, but it can provide the strategic clarity to build software that is not only functional, but genuinely valued.
Applying Modern Product Management Methods to Automotive Software Development
There are, in fact, many opportunities to apply modern product management methods to automotive software development—often in ways that complement existing industry practices. For example, established luxury brands have long used invitation-only experiences, such as exclusive drive events for selected demographics, to build anticipation and desirability around their upcoming models. From a product management perspective, these are sophisticated forms of demand testing and early validation—akin to creating desirability hypotheses and testing them through controlled, high-touch MVPs.
Similarly, concept car unveilings that allow customers to place deposits are not just marketing tactics—they function as real-world MVPs for gauging customer interest, helping OEMs test demand before committing to full-scale production. These early interactions can offer valuable signals to product and engineering teams, especially when coupled with iterative design feedback loops.
Further along the product lifecycle, pre-delivery drive events and customer clinics present critical opportunities for learning. Product managers, in collaboration with engineering teams, can use these touchpoints to gather early feedback on in-car software features, usability, and user engagement. When taken seriously and paired with agile practices, these learnings can guide meaningful software iterations—refining everything from user interface flow to feature prioritisation.
Even for more accessible brands, the dealership test drive remains a powerful tool. By designing these experiences with product thinking in mind—ensuring the software’s interactive elements are intuitive, engaging, and aligned with driver expectations—OEMs can transform onboarding into a moment of emotional connection. These sessions are not just about showcasing hardware, but about onboarding users into an interactive digital environment. The most effective experiences feel intuitive and intentional, subtly demonstrating that the in-car software was designed with the driver in mind.
By rethinking these traditional automotive rituals through a product lens, OEMs can blend desirability testing, customer learning, and iterative software development in ways that bring measurable value—without compromising the rigors of automotive quality and safety.
3 Mistakes OEMs Make When Adopting Product Management
While many OEMs are beginning to explore product management practices, the translation from theory to execution is often inconsistent—and sometimes counterproductive. However, I’ve seen first hand some common mistakes that undermine the effectiveness of product thinking in the automotive software context:
1. Treating Drive Events as Marketing, Not Learning Opportunities
Drive events—whether exclusive previews, media drives, or dealer-hosted test drives—are frequently viewed as promotional milestones rather than rich opportunities for hypothesis validation. Without a clear framework for capturing feedback, and more importantly, without product managers actively translating that feedback into actionable insights, these events fail to inform product decisions. Engineering teams are often left siloed from customer experience learnings, resulting in feature development that lacks real-world grounding. An effective product manager should serve as a translator between raw customer feedback and the feature pipeline—deciding what to improve, what to discard, and where to pivot based on how users actually experience the vehicle.
2. Building for Scalability Before Validating the Idea
I’ve encountered cases where developers preemptively build complex, scalable infrastructure for features before proving that the feature delivers value to users at all. This is often driven by good intent to front-load technical complexity and scalability planning. However, when developing new software features or digital services, this approach can quickly lead to waste. Product teams need to be more intentional about differentiating between building to learn and building to scale. Without validated learning, scaling efforts are premature and risk creating systems that support features no one asked for.
3. Misdefining the MVP
Perhaps the most critical and costly misstep is the misinterpretation of what an MVP (Minimum Viable Product) actually is. In the automotive industry, the true purpose of an MVP is to avoid building the full product until there’s validated demand. A concept car with a deposit model is a textbook MVP—it tests customer intent before committing to production. By contrast, treating the first customer delivery as an MVP—especially when all vehicles are pre-sold—is a strategic error. At this point, the product should already be refined. Positioning it as an MVP and planning to iterate via OTA updates puts the brand at risk, not only in customer satisfaction but also in post-delivery warranty costs. An MVP is a learning tool—not an excuse to ship unfinished experiences to customers who have already paid.
As automotive continues its transformation into a software-centric industry, I believe product management has a crucial role to play. Not as a trend borrowed from tech, but as a necessary discipline that brings focus, agility, and customer value into the heart of vehicle development. My reflections come from years of working in this space—paired with a growing drive to improve how complex systems are designed, validated, and experienced.
I look forward to connecting with others working at the intersection of engineering and product—and learning together how we can build vehicles that are not only functional, but truly meaningful to the people who drive them.