Everest failed, here is the postmortem
Everest was an app you used to set and track goals. It failed within two years and blew $2.2m (Some cash came from Peter Thiel) to get only 300k downloads. I remember seeing the deck and reading about it when it launched and knew it wouldn’t go far. Sure it was pretty, but i just didn’t see it being big and their monetization strategy didn’t make sense. More fundamentally, they were trying to change peoples’ behaviors and that’s kinda impossible.
Everest set out to build a technology platform that inspired and empowered people to live their dreams and achieve their personal goals. Popular dreams included: travel the world, learn Spanish, run a 5k, write a book, buy a house, and get in shape.
The shut down email
It’s with a sad heart that we must inform you all that Everest will be shutting down soon. In the end, we were unable to get enough people using Everest to justify the significant costs of running the service and keeping a team employed.
***Please visit Everest.com as soon as possible if you’d like to save your moments to your computer; the servers will be taken offline soon.***
If you need to reset your password to save your Everest moments, you can do so from within the iOS app.
Sincerely,
The Everest Team“Please watch out for one another, and love and forgive everybody. It’s a good life, enjoy it.” — Jim Henson
What Everest did right
- Focus on great design: Was good enough to be differentiation to help them gain attention to raise money, get featured by Apple and do deals with brands. CAVEAT: I think their focus on design actually killed and distracted them
- Culture: Helped cohesion when the times got rough
- Clear mission stakeholders bought into: They enunciated a mission that staff, advisers, investors, and clients all bought into
Why Everest failed, in their words
Technical reasons for failure
- Offline sync is hard: They shouldn’t have started with this feature. It took months and over complicated.
- Built rubbish architecture: “the words “spaghetti code” and “technical debt” were getting thrown around the office” and “There were talks of scrapping the codebase and starting from scratch. We chose to use it, clean it up, and move on, but it took months.”
- No automated testing: “There was no structured or automated approach to testing the product. All the functionality had to be tested manually, over and over again.”
Execution reasons for failure
- Didn’t track metrics: Nothing till more than 8 months after launch. They didn’t pick their core metrics and deploy the resources to track them prior to launching
- Didn’t build an MVP: Their MVP was overblown with ‘nice to have’ features and they kept adding more. They didn’t state their assumptions and then go look to verify them before overbuilding. “We kept adding rather than being oriented around subtracting”
First, make it easy. Then make it fast. Then make it pretty.
If your MVP takes a year to build…it’s not an MVP.
- Didn’t launch fast enough: They planned in launching in 4-6 months and totally overshot it
- Didn’t solve the problem: Motivation is key to achieving goals (the point of the app) and “we couldn’t crack it.“
- Unfocused, tried to do too many things: They felt they needed to facilitate peer-to-peer offline and couldn’t find “a scalable way to do this offline” which frankly doesn’t make sense and their initiatives were further distractions to the fact they couldn’t get a working platform functioning.
- Office in a poor location: Wasted time traveling, harder to hire devs, didn’t participate in the “broader startup water cooler“. They ironically did this to “stay more focused.”
“Measure everything, but determine beforehand what questions you are trying to answer.”
- No real business model: Focus on brand sponsorships rather than paying customers
“One mistake we made was not making the user pay, either through an up-front purchase, subscription, premium features or some alternative, but clear and direct, business model. We pursued brand sponsorships instead, and although that generated interest, sales cycles were long and we were bound to ultimately be measured against active users”
Founder reasons for failure
- Technical cofounder messed up: Built an iOS app and hadn’t done one in a while.
- Operated distributed team: Started distributed in different places and then moved to SF, but the technical cofounder didn’t as couldn’t find a big house for his family.
- Team too inexperienced in product: Their V2 was focused on making their ui/x even more pretty rather than “understanding how to better solve the problem.” They built a product requiring too much manual input for a mobile product. They didn’t interact with customers to understand what they wanted and how they used the product (or not)
“It was a more well-made product than Version 1, and retention was nearly 60% Day 1-30 (after steep day 0 drop-off). So I think it had more to do lack of differentiation – it was ultimately too similar to Instagram,”
- Cofouners didn’t get on: There is a lot of subtext in the fail blog, and it is only one side, but the founders didn’t get on. Whilst there wasn’t a blow-up they should have sorted things out.
- Didn’t manage burn: They blew $100k pm with no product-market fit and understanding of the problem they are solving.
We were spending $90–105,000 a month for most of the company’s life. We hired more people to fix process/product problems instead of fixing our approach. Bloat creates more bloat.
Key lessons to learn
- Set assumptions for the startup, launch a simple MVP to test those assumptions, and do it fast
- Define a target user group you want to make happy by solving an actual problem. Once you make that group happy, you can move on to the next group (Think Facebook). In social apps you need to start by building engagement, then acquisition and finally how to scale acquisition
Start simple. Build a high quality solution to a real problem for a cohesive group of people. If you solve one problem really well, then you can move on to the next problem (one simple approach at a time) instead of trying to tackle several things at once and, as a result, not really solving anything. Product development is about earning the right to build the next thing.
First, build the kernel of value. For free apps, this means engagement. Then, focus on activation. Then on acquisition.
- Build your tech stack properly from the start as technical debt can and does kill you.
- Hiring takes 3x longer than you plan for and it is worth waiting for an A-player
- If team isn’t working out early, follow your guy, get ready to fire them “Stick to a three strikes and you’re out policy.”
- Hire your cofounders wisely. It sounds like there were cofounders troubles, particularly with the tech guy. Also, the tech cofounder is key
- Shared vision and values are required. “A shared vision is not enough of a reason to work with somebody“
Having a technical co-founder is essential. You need somebody to own the history of your codebase. If you don’t have a technical co-founder, then progress comes to a halt as soon as you can’t pay an engineer. Technical co-founders also make it easier to hire the right talent.
More reading
You can read the original fail blog here