Being a tech enthusiast, I stumbled onto a short documentary about an ingenious invention from the past, the Snow Cruiser - an expedition vehicle from the '40s built to explore south Antarctica. Proclaimed as one of the greatest engineering legends of all time, it was a brilliantly thought-over machine that embodied so many brave ideas, yet it failed spectacularly.
The story of how the whole venture of building the Snow Cruiser started, evolved, and failed reminded me of why many innovative products and ventures fail today - some have challenges with the setup, some with the timeframe, while some cannot easily get to the funding they need.
Ready to learn some venture building lessons so your next venture doesn't end up like the Snow Cruiser?
In 1939, Chicago’s Armour Institute of Technology set a course to build an innovative new type of vehicle intended to explore the Antarctic. The team managed to build a beast of roughly seventeen meters in length, positioned atop overly large pneumatic tires in just 11 weeks. But, the Snow Cruiser went one step further. From the structure that held a biplane with a crane on top of the vehicle; from the power system, which consisted of a diesel unit that supplied electricity to four separate electromotors on each wheel, to a heating system along the entire vehicle, which was based on the utilization of the heat of the engine coolant. It was a respectable accomplishment even by modern standards.
But, the production did not go smoothly. Armour was rushed by politics to finish up the Cruiser ahead of the planned schedule so it could be used on the upcoming expedition, causing the construction team to work around the clock. Since Armour had to find ways to make the vehicle ready earlier, they searched for ways to shortcut production time and found an interesting solution.
Instead of testing the finished Cruiser in-house, they managed to plan out a live testing run where the Cruiser would be driven from the factory in Chicago to the docks in Boston (where a transport ship to the Antarctic would pick it off), planning to resolve all issues along the way.
The 1600km trip did not go without issues. The Cruiser had driving problems early on, causing heavy traffic jams while eventually slipping off the road under heavy rain. Eventually, when the Cruiser arrived at the dock, it was discovered that it does not fit the ship, so part of it had to be disassembled.
Once the ship arrived in Antarctica with the disassembled Cruiser, things started to unravel quickly. Before making the first contact with a snowy environment, the Cruiser was almost wrecked by falling through the unloading ramp.
Within the next few minutes, the crew discovered immense problems with its drivetrain. Firstly, it proved to be vastly underpowered and it failed to achieve friction between tires and the ground causing the tires to rotate in place. Momentarily it became obvious that the tire engineering was inaccurate and that the Cruiser won't move anywhere.
Trying to bootstrap a quick fix, the crew positioned chains onto the tires and even unmounted two spare wheels from the Cruiser and bolted them onto existing ones ending up with double wheels, and hoping for double traction. They improved the traction a bit and could drive the Cruiser at a slow speed, but the new wheel configuration led to improper weight balance across the wheels, making it only possible to drive the Cruiser - backward.
It doesn't come as a surprise that taking in all the factors of the operation, it was not feasible for the Cruiser to accomplish its mission. Instead, they drove in a loop of 148 km in reverse. Eventually, the crew admitted defeat and left the Cruiser permanently parked for use as a stationary laboratory.
Now that we've learned about the innovative, yet ill-fated Snow Cruiser, one can not just ignore the fact of how many parallels we can draw to modern-day product development.
Decisions are steered by politics and agendas that don't put the customer (or even the product) first. Often observed in situations where a launch is forced ahead of schedule just so the general public (or key stakeholders) get a false impression of things moving ahead. And don't get me wrong - I'm all for early rapid launches.
In the case of the Snow Cruiser - they still were on a planned production schedule when politics decided to shorten the deadline so that they could announce the project publicly for the upcoming Antarctica expedition.
This is where most product agencies or software companies get it wrong. They build for years without ever knowing who they build for. Data shows that most of those products fail once they get launched.
Reasons for that are simple: going too far ahead of building for a hypothesized customer, market, or problem. Instead, the focus should lie in acquiring data first (and fast).
The Snow Cruiser team could probably also have resolved some issues by using either tested components that have already been put to use in such environments (tires) or doing some stand-alone segmented tests. They ended up like most product companies end up with - a setup where pivoting was not feasible anymore because they've gone too far for too long.
Many products get into development without properly challenging (god forbid even testing) some of the main hypotheses (or the general idea) around them. They build for customers that don't exist, conceptualize features that no one even needs and when the shit hits the fan, use internal focus groups to determine next steps and customer needs (as opposed to acquiring real customer data).
As for the Snow Cruiser, I don't necessarily think that they had false assumptions around the idea, but mostly around the real-world operation of those components altogether. It was a false assumption that those tires would have sufficient friction on snow just because they do on swamps, a false assumption that the new untested drivetrain would have sufficient power in a real environment just because it proved to work in a testing environment and a false assumption that such a weight distribution would work in snow as opposed to tests on solid surfaces and so forth.
Too many assumptions around your core feature are dangerous. That's why it's always smart to have a conservative ratio between data and assumptions if possible not greater than 3/1 (meaning 3 confirmed or at least solid data points/hypotheses on one assumption).
Here are some learnings from the story of the Snow Cruiser that, if applied correctly, will make a difference for your next venture as well.
Keep your product lean. Ruthlessly stick to the market needs vs. wants, and eliminate all potential fuss that could distract you or use up your R&D time.
It's always easier to add once you have a clear need (knowing what to do) than to remove if unneeded (guessing why it's obsolete and how to pivot). Having your USP defined early on will provide you with a clearer focus on areas where you have more control versus areas that you still need to acquire control over. Unfortunately, Snow Cruiser did a lousy job at leveraging risk by using too many untested components at once.
Getting early traction with your customers is key to getting to Proof of concept. Whenever you can, aim for customer friction, even if it sometimes means demo-ing or releasing an unfinished product. Sometimes you might discover what they really need and how to pivot early on.
Imagine Snow Cruisers' tires or drivetrain being tested independently on a demo vehicle in the Antarctic in the early phase of the mission. Having such data points would pivot the whole construction 180 and could have led to mission success.
Whatever product you wish to build, plan in as much time as possible for iterations. This ultimately applies to situations where you might have external factors limiting your potential runway (investors with a new round, a big launch event, limited resources, etc).
You don't want to end up in a situation where your product's fate is leveraged by your next go-live. So many companies end up that way just because they don't iterate through data but through assumptions (if they iterate at all).
Do not be afraid to launch unpolished, imperfect versions of your product - you'll end up either failing sooner or get up acquiring new useful data that will help you vastly improve your product. In the end, nobody wants to build for a sandbox but for real customers, right?
Snow Cruiser was an over-designed and under-tested machine that was rushed into service. But even under such circumstances, it could have stood a chance of success if just one single factor in the venture equation would have changed. This can also apply to any other venture. Sometimes, even a faulty, unrefined product is sufficient and stands a chance of success, given it is iterated according to the real customer data and if there is sufficient time left for iterations till you get it right.
Like what you’ve read? Check out our open positions and join the Martian team!See openings