Moonshots and why not every rocket needs to go to the moon to be successful
"An act or instance of launching a spacecraft to the moon," according to the Oxford Dictionary.
In software, we think of moonshot as something ambitious, devoid of the certainty that the project will succeed, but that can transform/create a business.
Moonshot is something that creates or changes your business on a 10x scale. It's not an incremental improvement or process improvement. It's something that changes the game but has a 1% chance of winning and a 99% chance of failing.
Some examples of moonshot -
Tidal - X Company
X Company (affiliated with Alphabet/Google, https://x.company/) has projects such as Tidal (https://x.company/projects/tidal/) with the goal of protecting oceans and bringing science to the way we use their resources.
The image below shows monitoring cameras from the project attempting to interpret the feeding behavior of fish by tracking objects in the water:
And Tidal's goal is ambitious:
Today, half of the world relies on fish as a major source of animal protein, but nearly 90% of our wild fishing stocks are depleted. With our global population expected to balloon to 10 billion people by 2050, there is an urgent need to find new ways to nourish our growing global population without damaging the ocean.
Starlink - internet worldwide
How could we change the world if we had accessible internet for everyone, anywhere? With this idea, Starlink (https://www.starlink.com/) started a project to place satellites in low orbit to provide internet access worldwide.
Satellite communication technology has existed for decades. In 1945, Arthur C. Clarke published an article called "Extraterrestrial Relays" describing the basics of artificial satellites in geostationary orbit. I think Arthur C. Clarke was a time traveler because of his incredible ability to predict the future - here's a video of him describing what a personal computer would be like in 1974! https://www.youtube.com/watch?v=sTdWQAKzESA
The first artificial satellite was Sputnik, launched by the former Soviet Union on October 4, 1957. We became accustomed to the technology by watching game broadcasts or by subscribing to companies like Sky or Dish, which sold access to paid channels.
In the distant past, when I worked as a consultant for a large bank, I remember lamenting every time I figure out that a branch had only satellite connectivity. It was synonymous with slow, poor, and expensive connectivity. One major problem was that of latency, which in summary is the time it takes for communication to go from your computer to the satellite and back.
This problem cannot be solved. We are limited by the speed of radio waves (similar to the speed of light), and we cannot accelerate light... A traditional stationary satellite is 35,800 km (22,245 miles) away from Earth. The higher the altitude of the satellite, the larger the coverage area of its signal and the fewer satellites you need to place in orbit to cover the same area, and placing a satellite in orbit costs (or used to cost) a few million dollars.
This is where the moonshot comes in. That moment when someone has an idea that combines absurdity with the question "would this work?" The Starlink project plans to install 42,000 satellites in low orbit, 550 km (341 miles) away, which would solve the latency problem and provide internet coverage in New York and the Sahara desert.
But putting 42,000 satellites into orbit was completely unfeasible until we began to see parallel developments by other companies, such as SpaceX, which developed rocket technology that could autonomously go into space, land on Earth, and be reused for another launch, greatly reducing the cost of satellite launches.
And today we have Starlink selling its product with an approximate latency of 50ms (500ms is the average latency of a traditional satellite), achieving a 10x improvement from this moonshot!
Moonshot thinking
What do you need to implement moonshot thinking? A lot, certainly, but let's focus on some important points.
Experiment
The culture of experimenting with the new is perhaps one of the most difficult things for an established company. The new takes you away from safety, and a corporation is premised on safety, on maintaining the "status quo".
The Innovator's Dilemma (https://amzn.to/3Vu2AzP) is a classic book. In it, Clayton M. Christensen shows how the creation of new "disruptive technologies" destroyed established businesses because of the belief that these new technologies would be a threat to the existing model.
"Disruptive technologies" are initially bad, bring in little margin, and have a high risk of dying. Why invest in something that is worse than the solution you already have running?
That's how Blockbuster would have thought when comparing itself to Netflix's business model - the online viewing experience is bad, limited, dependent on the internet, doesn't have the social moment of going to a video store... and at the end, Nexflix killed Blockbuster.
And to avoid staying in past examples, Chegg (www.chegg.com), an education platform that helps students with their homework (I wish there was something like that in my time!), plummeted in value on the stock market after announcing that it is having difficulty attracting new users due to ChatGPT (https://www.cnbc.com/2023/05/03/chegg-shares-jump-17percent-wednesday-after-dropping-48percent-on-chatgpt-concerns.html). Have you ever asked ChatGPT to help you with a math problem?
How do you fight in a game when you have no idea who your competitor is? Innovate and create your own competitor!
(Don't) Move Fast and Break things
"Move Fast and Break things" is attributed to a quote from Mark Zuckerberg and Facebook's thinking model. The problem is that it is full of myths and little pragmatism. Nobody wants to "break things" or "fail often" ("fail fast and fail often").
Your company needs to choose the projects that will be tackled responsibly. We don't have infinite money or time, so choosing and focusing on projects is very important. This includes saying no to many things, supporting projects that may fail and have a high level of uncertainty, and knowing when to abort them without feeling guilty.
The secret here is to recognize failure early and move on to the next project. The "failing moment" is not the moment we stop the project, but the moment we decide to stop it and realize we could have done it six months ago.
And here's a tip: never follow the famous Six Phases of a Big Project Failure:
- Unbounded enthusiasm,
- Total disillusionment,
- Panic, hysteria, and overtime,
- Frantic search for the guilty,
- Punishment of the innocent, and
- Reward for the uninvolved.
There is no caste of chosen innovators
You were not born into a caste destined for innovation. Innovation can be created by any department and any person in the company, as long as there is room for it.
There should not be a "team responsible for innovation." If you have an innovation department in your company, that group should be the team of provocateurs, facilitating the development of projects within the company. The "innovation team" is unlikely to have a clear perception of the pains of operation/clients/production as the people who are working on the day-to-day will.
Having structured innovation team in the company is crucial, but expecting all ideas to come from there is naive.
The Hierarchy of Yes versus the Hierarchy of No
I recently heard an interesting concept about the "hierarchy of no versus the hierarchy of yes," which basically compares the effort to create a new project in a corporation versus a startup.
In a corporation, you are subject to the hierarchy of yes. Your project, submitted to your boss, will be submitted to your boss's boss and so on until it receives a maximum "yes," which means it can be pursued. This iteration can be relatively short in a flatter corporation or longer in a larger corporation, but it always implies one thing: a "no" at any link in this chain means the end of the project. If you sold your idea to your boss, who gave a yes, just one "no" from any other hierarchical level (vertical or horizontal) is enough to shelve your project. Do you know that challenging project that someone in legal said was too risky? Or maybe that project that your boss's boss's boss said wasn't worth pursuing? Well, it went to limbo.
In a startup, the process is a little different. Because it is a much more chaotic structure, more bazaar than cathedral (https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar), a "no" to a project basically means you should try again, perhaps with another internal group or another co-founder who supports the idea. Once you have a "yes," you have the green light to move forward.
In summary, a "no" at any stage in a large corporation that is not aligned with innovation kills a project. A "yes" at any iteration in a company that seeks innovation makes an idea feasible.
Not every rocket needs to go to the moon to be successful.
We've been talking here all the time about "10x" projects, projects that will "move the needle" and radically transform the company.
But not all of these projects need to be "rockets to reach the moon." Sometimes, small initiatives can change the game as long as they address a clear pain point.
I'll give you two examples from the same company that I consider to be a great case study, which had great success given a set of small projects with tiny teams. These projects are not "rocket science" but certainly changed the value of the company by 10x (or 100x).
(1) PayPal and the fight against fraud
Max Levchin was one of the founders of PayPal and tells his story in "Founders at Work" (https://amzn.to/3HEpqim). The merger of x.com and Confinity, which were two competing payment companies, gave birth to PayPal.
The company was initially created to allow for electronic money transfer between Palmpilot users, which you probably don't even know what it is, but it was a smartphone-like device from the 1990s.
The idea was cool, innovative, created traction among excited geeks, and had up to 12,000 active users on the platform, but the solution couldn't grow more than that, couldn't cross the chasm ("Crossing the chasm" - read it!) and really scale.
However, they realized that the web version of the application was gaining traction. Internally, nobody gave much importance to the web version because it was just a big Plan B, in case the user who did not have their Palm in hand could transfer money using the web as a contingency. The Palm version of Paypal was discontinued in 2000, when the web version had crossed the 1.5 million user mark.
eBay at the time was starting to gain traction, and PayPal began to be widely used by eBay users as a secure form of payment between buyer and seller on the site. eBay ended up buying PayPal for $1.5 billion in 2002 (https://www.cnet.com/tech/tech-industry/ebay-picks-up-paypal-for-1-5-billion/) and the rest is history.
But going back to the beginning, the merger of x.com with Confinity was very difficult for both companies, and Max ended up somewhat sidelined, running a team that consisted of him and an intern.
Max realized that PayPal's growth came alongside a large increase in fraud, and that if something was not done to reduce the number of frauds, this could be the end of PayPal.
At the time, the process of fighting against these frauds was very manual:
We actually had these human investigators, like 20 to 30 human investigators, that would try to unravel particularly large fraud cases and see if we could recover some money or send the Feds after somebody. We didn’t really have much success sending people after criminals. All they’d try to do is see where the money went and see if we could recover some of it before it left the system. That was pretty difficult to do because the tools we had available to us at the time allowed you to look at only a couple of accounts at the same time. If you had a well-coordinated fraud, with thousands of accounts or hundreds of thou- sands of accounts involved, you basically didn’t know how to follow it.
Max's idea was to create a tool that could predict fraud for investigators to work more assertively. This improved the performance of the investigation team, making them work on only the top 5% of cases, which were the ones with the highest chance of being the biggest losses.
The tool drastically changed the amount of fraud. In the early 2000s, several competitors of PayPal began to close due to the amount of fraud they encountered. eMoneyMail, was a competitor that faced 25% fraud at the time, which led to the closure of the operation.
The amazing innovation team at PayPal consisted of a talented programmer who understood the business and realized that fraud would break the company and an intern who dropped out of college to create this product.
Peter Thiel (one of the founders of PayPal) founded Palantir years later with the goal of identifying criminal networks and mitigating fraud. "the idea was that, if the software (used by PayPal) was good enough to identify money launderers, it could probably identify terrorists, too."
2 - David vs. Goliath (or PayPal vs. eBay)
PayPal really took off with sales made through eBay. Here's a quote from Peter Thiel in his book Zero to One (https://amzn.to/3LWDGW5):
...once you’re 10x better, you escape competition. PayPal, for instance, made buying and selling on eBay at least 10 times better. Instead of mailing a check that would take 7 to 10 days to arrive, PayPal let buyers pay as soon as an auction ended. Sellers received their proceeds right away, and unlike with a check, they knew the funds were good.
The problem was that eBay had its own payment system, a company called Billpoint that eBay acquired for $43.5 million in 1999.
How do you compete with payments on eBay when eBay itself has its own payment system?
Enter Reid Hoffman, who said:
PayPal’s biggest traction was with eBay. But eBay had an internal product called BillPoint. PayPal, as the sort of 3rd party disrupter, was at a serious disadvantage there. eBay was the only gold mine that existed. We had to win. It was time to leverage the athletes’ competitive talent. One decisive move in the war was focusing on e-mail. The real platform for auctions wasn’t the eBay website, as most people assumed. It was e-mail. People would receive emails when they won auctions. eBay knew this but didn’t understand its importance. PayPal, on the other hand, got it and optimized accordingly. Very often PayPal would notify people that they won the auction before eBay did! People would then use PayPal to pay, which of course was the goal.
That's right, one of the strategies that the small David/PayPal used to defeat Goliath/eBay was to be able to send emails more quickly to the user saying, "You won the auction! Do you want to pay with PayPal?"
At the time, eBay couldn't understand why most users were paying with PayPal instead of paying through eBay itself! In the end, it was a simple army of bots that were able to notify users and create a lower-friction experience (on friction and simplicity, check out here).
A digital guerrilla strategy, but one that resulted in a $1.5 billion exit and created a group of millionaires (and billionaires) who later became known as the PayPal Mafia (https://en.wikipedia.org/wiki/PayPal_Mafia).
Final reading tip: it's worth watching the video of Peter Thiel, presented by young Sam Altman (now CEO of OpenAI) and talking about competition and monopolies.
