In this session Collin & I use Volkswagen’s struggle to build Electric Vehicle (EV) software as a way to explore two themes:

1. the importance of getting a digital transformation right, and
2. the opportunity presented to competitors when large players simply cannot deliver good quality digital products.

We use two articles from the Financial Times as a springboard for our conversation. The first article, dated Jun 28, 2024 “Oliver Blume, VW and Porsche boss steering an EV strategy shift” and the second one, published September 2, 2024 “VW considers closing factories in Germany and cutting jobs” (both behind a paywall - sorry)

The first article describes an investment of $5 billion in the US based EV startup Rivian. The purpose of the investment is to create a joint partnership that allows VW to use Rivian’s EV software. The article quotes VW’s CEO Oliver Blume as saying, “In terms of a big tech transformation, you can’t do it all on your own… It should be a win-win situation . . . The motivation from our side is to speed up software transformation at Volkswagen in all our brands. Rivian has best in class architecture . . . Volkswagen has the scale”.

Collin and I explore this thinking of an acquisition / strategic partnership as a means for fixing an internal digital transformation challenge. For those of you who have listened to Collin and I, you probably won’t be surprised to hear that we are not convinced that such an approach will easily remedy digital product development challenges.

As we ask in the show, what mental models will need to change for these two companies - a digital native and a non-digital native, to work effectively together? As Collin highlights, ultimately these transformations are culture changes, which require heavy-lifting.

Since recording this session, the FT has come out with more articles on the challenges Volkswagen is facing. I have also started listening to some of the VW YouTube influencers who have been discussing software issues for a number of years. I am finding this to be a fascinating case study, albeit quite sad for the workers of Wolfsburg if the leadership of VW can’t get its digital act together.

In this session, I also refer to a 2017 Medium post on how Revolut used the build-measure-learn cycle to develop digital products quickly and acquire customers.

Hope you find the session useful.

If you like the show, please give us a nice rating and recommend the show. It helps others find the podcast.

In this last episode of our three part series, Collin and I continue to role-play an imaginary data-heavy product development project. In our last episode, Collin was granted some authority to get more involved in the project in an effort to reduce the risk that Collin felt was inherent in the delivery team’s approach. The delivery teams is a consulting firm that has been brought in by another group in the company. In this episode, Collin elaborates on the types of risks he sees, as well as how he would address those risks through an alternative approach to product development.

Collin and I are using this fictitious scenario to explore how ways of working, power dynamics and group-think play out in digital product development. In my opinion, these three forces are always at play in this type of work. Our goal in exploring this is to help listeners become better equipped to work with these forces on their own projects.

In this episode, Collin and I discuss the fact that using an approach that pushes risk out into the open earlier in the product-development lifecycle brings reality into the room very quickly. It forces people to stop imagining “happy-path” outcomes through Power Point and Gantt charts. This can often be experienced as “raining on the parade.”

In this episode, I ask Collin to help a senior manager identify the risks themselves by role playing the person who procured the consulting firm. In this scenario, a senior manager wants to be able to see the types of risks that Collin is seeing. This manager wants to be able to ask the questions that Collin is asking. And, they want to mitigate some of those risks without having to rely on delivery managers like Collin - “What is it that allows Collin to see digital product development in the way he sees it?”

Through the role-play, we discover risks that were hidden in the consulting firm’s Power Point presentation and Gantt charts. Because of the approach the consulting firm was taking, made worse by shrouding it in Agile lingo, these risks would not have revealed themselves until very late in the consulting firm’s engagement. As Collin says, “If the consulting firm had followed that plan they would have delivered late and asking for an extension. That may be good for the bottom-line on the consulting side, but puts the company’s strategic goals at risk.”

Hope you enjoy it. As always we would look forward to hearing from people.

If you are liking these podcasts, please do throw us some love in the ratings.

Thanks

In this episode, Collin and I continue to explore a digital product development project. Our project is heavily dependent on data and is to be delivered by an outside consulting firm. Our consulting firm says that they are are using Agile practices and principles to deliver the project, but as we learned in part 1, this team is in fact using a much more sequential “black-box” approach to delivery.

For Collin and I, this is a realistic scenario. It is something that we have seen multiple times in our careers. It is also a high risk project, not simply because of the heavy dependence on data, but also because of the proposed ways of working combined with the organisational and power dynamics of the situation. We feel that such dynamics are present in all real-world digital product development situations, but often not taken into consideration when talking about ways of working.

Our goal in this exploration is to give listeners tangible actions that they can use when faced with a similar situation.

In this episode, we explore further Collin’s idea of latent assumptions, which he introduced in episode 1. These assumptions are baked into projects, unrecognised as assumptions. Collin and I feel that this is particularly true for projects with a heavy reliance on data.

Dependent upon the ways of working, teams may not learn that their assumptions were incorrect until very late in the project, often when the budget is nearly exhausted.

We delve into the mechanisms that Collin is using to assess the risks within such a project and how to bring these risks into the light early to prove or disprove them?

We spend a lot of time in this session exploring how do you get people with the right level of authority to recognise the risks of such a project, particularly when many of those people aren’t equipped to see such risks?

We hope you enjoy it. As always please let us know what you think. And, if you liked the session, we would be very appreciative for a positive rating.