The Process Tesla Uses to Speed Up Innovation
Sometimes one sentence gives away more than the entire talk combined. Here’s what I learned from the Tesla semi delivery event and how you can apply it to your own startup.
One Of The Core Product Loops
Tesla held its first-ever semi truck delivery event just a week ago. The media paid the most attention to the truck itself and quoted Musk a lot. For me, tho, the most important bit of information came from the other guy on the stage.
We’re gonna put these [Tesla semi trucks] into our own fleet, into our own supply chain and we’re gonna use these to transport goods between our factories and our suppliers.
Because we believe in it not only from the mission perspective and cost perspective but because we want to close that feedback loop. We gotta get that learning as fast as we can. We want it [the feedback] straight from the drivers, we want it straight from the service tech[nician]s that are working on it.
We’re gonna take all that data that is coming in and continue to refine the product and make it better just like we do it on the car side.
I strongly believe that great companies are built on three core product loops:
- growth loops that bring new customers;
- habit loops that keep existing customers engaged by providing them value;
- feedback loops that speed up innovation and improve the product.
Tesla was clearly hinting at the third one. So, let’s examine feedback loops in particular.
What Is A Feedback Loop?
A feedback loop is a loop where the output of the system is fed back into the system and the system is calibrated.
That’s a more technical definition. In more simple terms, it speeds up innovation. Which results in improved or totally new products/businesses.
Note that a key part of the definition is that “the system is calibrated”. If you’re collecting feedback but not improving your product, it’s a broken feedback loop.
Note also that the longer the feedback loop, the slower the innovation.
The five-year plans of the Soviet Union are a prime example of both broken and long feedback loops. The data was often incorrect for a variety of reasons. And even when some data points were correct, it took up to five years to make changes.
Most if not all governments work with long feedback loops (with yearly budget planning). But so do many companies (especially the big ones). Which gives startups an advantage.
Speeding Up Feedback Loops
Playing The Telephone
Even if you collect feedback, it might take a long time for the feedback to reach the right people. Tesla, for example, has over 110k employees — that is more than the second biggest city in Estonia. Also, all government employees (officials) use the government services but somehow things still seem to be moving very slowly when it comes to improving them.
So, there’s another push that should be made in terms of processes and culture.
The more people you need to go through, the longer the feedback loop gets. And the more data gets lost on the way. This is called the “broken telephone” effect. Which leads to a reduction in innovation.
Here’s an example of how Elon Musk urges the employees of Tesla to speed up feedback loops:
“A major source of issues is poor communication between depts. The way to solve this is allow free flow of information between all levels. If, in order to get something done between depts, an individual contributor has to talk to their manager, who talks to a director, who talks to a VP, who talks to another VP, who talks to a director, who talks to a manager, who talks to someone doing the actual work, then super dumb things will happen. It must be ok for people to talk directly and just make the right thing happen.”
Elon Musk, excerpt from an email to Tesla employees
So, to speed up feedback, cut down on the number of nodes that messages have to hop through to reach the right person.
Releasing Once In A Blue Moon
The longer the release cycle, the longer the feedback loop. So, it’s no wonder that “Release early, release often” became a mantra for software developers as soon as the open-source projects grew in size.
It’s also one of the big differences between Tesla and most other car manufacturers — Tesla sells cars that change each week basically (in terms of both software and hardware), while the incumbents mostly do big changes with facelifts that take years to come out.
Dogfooding With The Wrong Use Case
Dogfooding is the use of one’s own products for improving them. It’s the ultimate feedback loop cause it’s the shortest.
But products are often built for a specific use case. Ideally, you’d want to dogfood the product with the main use case. But companies have all sorts of different roles that might not fit the use case.
So, what tends to happen is, that the product that people are supposed to be working on, gets introduced to them only theoretically. A bunch of statistics, a bunch of features, and maybe a bunch of stories from a bunch of potential users. With very little emotional connection.
There are only two solutions to this:
- Make people use the product with another use case;
- Make people switch roles temporarily.
Both can work. There’s no right answer here really. The difference will be in frequency and willingness.
Using the product for another use case could work well. Especially if it’s a daily use case. But the product might not be suited to it at all, so, the problems that come up are not much related to the main use case. Plus it can result in a lot of daily frustration.
Switching roles is a temporary solution. You can only do it either as part of onboarding or perhaps once a quarter. Sometimes, it’s hard to do even that. Engineers don’t necessarily want to do so sales although they are happy to develop a sales tool.
A fallback (when there’s a lack of willingness) is to at least make employees work in support for a couple of days per quarter, so, that they’d see the problems first-hand.
Don’t Build Stuff For Hypothetical Users If You Can Help It
When you consider building something, prefer building stuff for yourself. You’ll have the absolute shortest feedback loop. It’s why I built Kypsis and Linkchimp — these were problems I had myself. I didn’t need to go ask a bunch of random people what and how to build.
There are numerous examples of people building successful companies out of products they built for themselves:
- Block Inc. (previously Square)— Jim McKelvey not being able to sell his glass faucets because he couldn’t accept credit cards;
- Etsy — Robert Kalin couldn’t sell his hand-crafted furniture online;
- AirBnB — Brian Chesky and Joe Gebbia wanted to rent out an air mattress in their room in San Francisco;
- Facebook — Mark Zuckerberg trying to get laid while in university;
This principle was already noted while programmers were tackling open-source and Linux in 1997:
“Every good work of software starts by scratching a developer’s personal itch.”
Eric S. Raymond, The Cathedral and the Bazaar
So, when you’re considering starting your startup, the most solid advice you can get is this — build something for your own needs. It’s the quickest way to innovate.
Want to learn more about startup best practices? Check out Product Loops — a library of best practices from top startups.
