Tesla Platform vs Purpose Built Car — 3 Years Later

A little over three years ago, I posted a blog about my then-new Tesla and my wife’s then-new Japanese car. The view I expressed was that the Tesla was conceived as an extensible software platform that happens to power a car, where my wife’s Japanese car was clearly conceived of as, well, a car. In other words, the Tesla is a platform, while my wife’s car is a “point solution.” I asserted that, over time, the Tesla would continue "growing" and adding new features, while my wife’s car would stay the same. Three years later, did that turn out to be the case? I can say, emphatically, that this has been the case.

Continuous Evolution, Continuous Delight

The Tesla has continued to evolve and delight me. While my wife’s car has been good, reliable, and comfortable transportation, it still does precisely what it did when she bought it four years ago, and does it in the same way. The Tesla, among many other new features, now literally drives itself, requiring only a destination to take me where I want to go. It stops and then goes again at stop lights and stop signs, watches out for pedestrians, bicyclists and motorcyclists, changes directions and navigates by itself, and brings me home—or wherever I want to go—without my involvement at all. Of course I am cautioned to stay alert and to override any unintended or dangerous behavior, but I have the feeling that’s as much out of corporate liability concerns as any other motivation.

While Tesla’s full, autonomous driving mode is in “beta” and does have some eccentricities IMO, I can testify that it’s real and it’s here today. And—more importantly in the context of my earlier blog—it’s now a feature of the same car that I bought three years ago. Three years ago, the Tesla had great low-speed follow and lane-keeping features, but nothing like what it can do today. In addition to “full self-driving” capability, my Tesla has spawned a host of new features over the last three years, ranging from a “theater mode” to new infotainment options, to UI changes, to more efficient energy recovery on braking. Since the whole car is software-controlled, basically any feature of the car and its performance can be optimized or enhanced.

Soft vs. Hard Controls

I have received at least 86 over-the-air software updates since 2019, nearly all of which added new features or enhancements. These were easy to apply—automatic, if you select that option. My wife’s Japanese car has had 6 firmware updates offered in the same time, mainly to fix defects. While her updates were nominally available over the air, doing so was so complex that in practice we either visited the dealer or downloaded software onto a dongle. OTA only started to work for us with the last of the six updates — I assume as the result of a previous fix.

Part of the reason the Tesla can be so flexible in terms of adding new features is that (a) the car itself is software controlled with minimal mechanical features, and (b) the vast majority of its controls are “soft” / touchscreen based. This means that the controls can be easily repurposed and reconfigured in software. Aside from the door locks, window controls and seat arrangement buttons, the Tesla only has seven mechanical controls: 2 thumbwheels, 2 rocker switches, and 3 levers (which have extra controls on them). All other controls are “soft.”

This “soft” nature of the Tesla’s controls is typical of the "abstract" nature of a platform architecture. A good platform is implemented at a degree of “abstraction” that allows components to pivot toward adjacent features. In the UI, this means making things like buttons “soft” so the "screen real estate" can be repurposed. In a server-side software platform, analogously, you seek to choose a level of abstraction that is high enough (but not too high) to enable pivots.

For example, in a banking application, one of the fundamental entities might be an “account” rather than a “checking account.” This would enable the same abstraction to deal with multiple types of accounts (e.g., checking, savings, investment) for those behaviors they have in common. The trick is making the abstraction concrete enough that it is intuitively obvious what it means, while at the same time general enough to allow for flexibility.

The Tesla UI has performed this trick through voluntary restraint. For example, while clearly they could put any controls anywhere on the touchscreen, they have kept the heating and infotainment controls in more-or-less the same position. Their function remains intuitive to the user, even though the features themselves have been generalized or changed. The "abstraction" remains similar.

Platform vs. Purpose-Built

My wife recently bought a new car; this time, one of Germany’s finest. Her 3-year-old Japanese car still works, but it no longer feels very exciting to her. Her new German car is indeed very cool—it has amazing laser-driven adaptive headlights, a first-rate heads-up display, good adaptive cruise control, a touchscreen with a gestural interface, and many other features. It’s clearly designed as a “driver’s car,” not as a self-driving one. The design goal is clearly around empowering the driver, not taking tasks off the driver’s shoulders. In spirit, her new car is very similar to her Japanese car—it’s clearly a car, not a platform.

Part of the “point solution” nature of my wife’s new car is evident from the number of dedicated mechanical controls. If I counted correctly, the dashboard, console and steering wheel of her new car have: 59 labeled mechanical buttons, 3 paddles, 1 joystick, 1 shift / gear control, 2 levers (with additional controls), 3 thumbwheels and a touch screen. The advantage of having discrete controls for so many functions is that an expert in using the car can find what they need quickly—like the pilot of a jet aircraft in an emergency. The disadvantage is that a button that turns the heat up will still turn the heat up 3 years from now. It cannot be usefully repurposed; the “user experience” is a fixed one.

My three-year-old Tesla, on the other hand, is still as exciting to me as the day I first got it. Just this morning I noticed a new feature; it’s a trivial one, but cool. When the Tesla is steering itself, there’s a steering wheel icon shown on the dashboard. Just this morning, I noted that the orientation of the steering wheel in the icon follows the orientation of the physical steering wheel—when the car turns left, the icon pivots left. When the car turns right, the icon pivots right. It’s trivial and cosmetic, but given that everything is electronic, it made me think: Is the icon the REAL steering wheel and the physical steering wheel the avatar, or vice-versa? Very Matrix-like.

Empowering the Driver vs. the Car

Could a car be designed that has the self-driving features of the Tesla, and the fine-grained driver-control features of my wife’s new German car? From a technical standpoint, absolutely. However, it’s very interesting that such a car hasn’t been created, at least so far.

I think that’s because of intent and philosophy. A company focused on creating a driver’s car will think about empowering the driver. My Tesla, on the other hand, does not have great driver’s aids like a heads-up display or laser adaptive headlights. I think this is because Tesla’s goal is not to empower the driver—it’s to empower the car to drive itself. The philosophies behind the two approaches are too different for them to merge, at least until one approach or the other becomes commoditized.

I very much look forward to seeing what the next few years will bring to cars. I think we will continue to see progressively more automation migrate into every car. Some cars will continue to appeal to those who like to drive or who distrust technology—but my money is still on the platform approach. I think we’ve just seen the beginning of what a fully-automated, software-controlled, self-driving car can do. That race will be won, I believe, by those who focus on personal transportation as a platform, not as a point solution.