I Have Seen the Future of Space Exploration…And It Looks Like Web 2.0
July 17th, 2008 by RajeevFew things outside of online advertising and putting some meat on the barbecue excite me, but on Friday I had a chance for some rather other-worldly excitement.
My friend Adeo Ressi (founding member of TheFunded.com and Trustee of the X PRIZE Foundation) organized a private tour at NASA/Ames Research Center in Mountain View. We made a couple of stops along the way but the real eye-opener was the project site of the lunar small exploration vehicle.

You might be wondering what’s so eye-opening about lunar exploration, given that it’s been a part of US space exploration since the 1950s and 1960s. What’s amazing is the approach that the NASA team working on the lunar small exploration vehicle is taking a team of 12 scientists took less than two years to conceive, design, and create an exploration vehicle that can take a 40-50kg payload to the moon all at a cost of approximately $50M. Once this exploration vehicle is proven and productized, imagine the number of private or commercial experiments or satellites that could be launched on a $50M budget.
The comparison between this approach to building space exploration vehicles vs. the traditional approach and the comparison between traditional software development and web 2.0 approaches is striking.
A traditional NASA approach to space (space shuttle, recent explorer missions) as far as I can tell, is a 10-20 year project with hundreds if not thousands of people involved at a cost of $1 billion or more dollars. An infinite amount of analysis is done to ensure that every potential problem has three fail-safe solutions and absolutely all risk is eliminated.
In contrast, the NASA team managing the small exploration vehicle spent 8 months designing a new vehicle from the ground up, got it funded by NASA to the tune of $50M, and then spent the next 8 months building a prototype. Their first launch is scheduled for next year. How did all of this happen? From talking to a few members of the team, it seemed there were several key ingredients:
1) Risk taking: The team members and their management were not afraid to take risks. This is probably due in part to the facts that this vehicle is unmanned (so no potential loss of human life) and the total project cost is less than $100M.
2) Use of off the shelf components: The team members are using a lot of off the shelf components. I’m not talking about Home Depot, but pretty close. The tanks that hold gasses to control lunar descent are literally scuba tanks. You can see them in the picture. The gas that is used was developed by the Department of Defense for missile control purposes.
3) Entrepreneurialism: There are only 12 members on this team. Most of them appeared to be in their twenties and thirties. Their workspace was strewn with sandwich wrappers and pizza boxes. Is that how you would normally picture a government scientist’s work area? These guys are going to see the fruits of their labor next year, not in 10 years.
I couldn’t help but compare this to traditional software development from the 80s and 90s to software development today. The lunar exploration vehicle team is not exactly developing on the timetable of a Facebook application, but it’s not too far off. Traditional software used to take 1-2 years to develop a beta version and cost $5-$25M in the process. The end result would be a huge success if there were more than 10 customers. Fielding a stable v1 could be a 3-5 year process. Today, that time frame is measured in months and in hundreds of thousands of dollars.
The number of experiments that can be undertaken and satellites that can be launched at a $50M price point has to be several of orders of magnitude greater than what is currently available. Any small to medium sized company could launch a communications satellite for whatever purpose – traffic information, weather information, wireless communications, etc. Hundreds or thousands of bio and pharmaceutical companies could conduct experiments outside of Earth’s gravity. The possibilities are endless.
As a repeat entrepreneur, one additional lesson that I took away from the tour was the efficiency and productivity that can be generated by a small but highly skilled and highly focused team. In fact, hiring more and more people is often the “easy” solution because it lets a product team get away with lots of manual processes as well as unfinished 90% or “near” solutions. Constraining the size of a team requires that complete solutions be built end to end, and these types of solutions typically generate the most benefit for the entrepreneur and their customers.

















