At Product Hunt, we are so passionate about helping startups and makers launch their products and share them with the world. Much of our site is about beginnings — the moment a product launches, and the moment someone discovers something new that they love. But, we’re also big believers in reflecting on and learning from endings . Unfortunately, the endings aren’t talked about nearly enough — or as favorably — in the startup world.

We were fortunate enough to have Everest Co-founder Katherine Krug share the story about the rise and fall of the beloved goal setting app. When the product launched in December 2012, Everest’s future was glaringly bright. The concept, design, and hype around the app strongly signaled its future success. But exactly two years later, in December 2014, Everest shuttered.

What happened during those 24 months? What led to the rise and fall of the promising Everest app? What follows are Katherine’s reflections on what went right, what went wrong, and what she learned during Everest’s two-year lifespan.

Press enter or click to view image in full size

The Everest Postmortem

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.

We approached behavior change in the following ways:

• Steps: Encouraged people to break big goals into small daily actions; “take a step a day to achieve your goals.” Users could plan steps and set reminders.
• Streaks: Helped users feel momentum through step streak tracking and celebrations.
• Dream Team: Encouraged users to pick up to three people to join their Dream Team for social accountability. Dream Teams provided step suggestions, encouragement, and nudges to a user when she hadn’t taken a step toward her goal.
• Inspiration: Provided an “inspiration” button instead of a “like” button. Users could check their inspiration score and feel progress even on days when they hadn’t taken a real world action.
• Challenges: Provided a guide for achieving goals (e.g. run a half marathon) without the work of creating their own steps. It was the foundation for what would later be sub-communities within the app.

We launched our iOS app in December, 2012 and officially closed shop in December, 2014.

What went right

Press enter or click to view image in full size

(1) We placed huge value on design, and it paid off. When we set out to raise our first round, we didn’t have any Silicon Valley connections. Victor Mathieux’s pitch deck design helped turned cold emails into warm leads. We were featured by Apple on every release, often for many weeks at a time. Julian Bialowas’s decks helped us land six-figure contracts with big, well-known brands. Even internal documents maintained hugely high standards.

(2) We built an incredible company culture. Every person who joined Everest had quirky, passionate personal interests they pursued, and the office was a place of support, encouragement, and growth. We went rock climbing every week, went on afternoon trail runs, got into kite surfing together, had interns lead us in powerlifting and karate, hiked Yosemite, and so much more together. The culture held us together when times were rough.

(3) We got incredibly amazing people to believe in the idea [READ: SOMEONE NEEDS TO DO AND NAIL THIS MISSION]. We had some of the brightest investors and advisors out there who “got” the big vision for the company and believed in its potential impact. We signed some big name brands to participate in our Challenge platform (how we were monetizing). And I can’t emphasize enough how amazing it was to watch the people in our community transform their lives and take on meaningful goals. Every day I felt inspired.

What went wrong

(1) We thought we were building an MVP and it was chock full of “nice to have” not “must have” features. We kept adding rather than being oriented around subtracting. We thought we would launch in 4–6 months — which absolutely did not happen — and then rapidly iterate. We should’ve defined and tested our assumptions before we ever started building.

(2) We launched a slow, buggy product. When I say slow and buggy, I mean a friend once emailed saying he loved the app, but that he would tap his profile, brush his teeth, and then it would load. OUCH. This happened because:

Our technical co-founder was a super smart, great person — but hadn’t built an iOS app in a long while. We started the company as a four-person distributed team, and when it came time to move to San Francisco, he decided not to uproot his family.

• Offline sync was a trojan horse that cost us months and loads of unnecessary/added complexity. We should’ve pulled the feature (not to mention recognized that it wasn’t necessary in an MVP).
• About two months after our first estimated launch date, with new engineers coming on board, the words “spaghetti code” and “technical debt” were getting thrown around the office at the rate of 10,243 times per hour. 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.
• There was no structured or automated approach to testing the product. All the functionality had to be tested manually, over and over again.

This is all to say that we were an inexperienced product team, and went through some serious growing pains.

(3) It took us ~8 months post-launch to start tracking metrics well. We were iterating in the dark initially, then with limited visibility, and finally fully instrumented. We needed to pick core metrics and deploy the resources to track them prior to launching. Our v2 was focused largely on UI/UX improvements rather than on understanding how to better solve the problem. The lesson? Measure everything, but determine beforehand what questions you are trying to answer.

(4) Our burn was too high. 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.

(5) There was way too much manual input for a strong mobile experience. Building mobile first requires simplicity, and any point of friction must be eliminated.

(6) We knew motivation was one of the key elements of a person’s success in achieving their goals, but we couldn’t crack it. We would often see people try Everest, face a setback, forget about Everest, and then possibly pick it up again when they were motivated to try something else. We wanted to be the tool that kept you going through the hurdles, but we didn’t accomplish that goal.

(7) We recognized from the very beginning that technology’s place in helping people achieve their dreams was in facilitating person-to-person interaction. We scratched the surface of this online (allowing people to comment, cheer on, and get inspired by other people — plus allowing users to copy the steps others were taking pursuing similar goals), but we couldn’t find a scalable way to do this offline. We launched the Dream Series to bring people together for meaningful experiences to kickstart dreams, but it was a distraction as we were trying to get our technology platform to work.

(8) We had office space in the Presidio, instead of being with all the other startups in SoMa, Mission or FiDi. The same way your business advances because of ideas around the water cooler, we missed out on the conversations around the broader startup water cooler. We wasted time traveling to meetings and it hurt our ability to recruit engineers. We thought it would help us stay focused, but the negatives outweighed the positives.

Important Takeaways

Press enter or click to view image in full size

Product

• 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.
• 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.
• Technical debt, acquired early, can kill products. If you don’t have product-market fit and you’re still experimenting, tech lock-in severely reduces a team’s agility.
• Get outside of the building! Steve Blank got it right. You can’t iterate in a vacuum. Phone calls are not enough for user interviews and usability studies. Put your product in someone’s hands and watch them use it. Key insights lie in the subtle interactions someone has, and often the things they don’t voice over those that they do.
• When building a social product, optimize your funnel from back to front. First, build the kernel of value. For free apps, this means engagement. Then, focus on activation. Then on acquisition.

People

• Expect it will take at least 3x as long as you would like to hire for any position. Hold out for the A+ player.
• Follow your gut on the people you work with. If red flags are raised early, don’t sweep them under the rug; they will definitely come back in a more damaging way down the road. Stick to a three strikes and you’re out policy.
• Pick your co-founders wisely:
• 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.
• Work with people who share your values (e.g. work with people that treat others well if this is something you value). A shared vision is not enough of a reason to work with somebody. If you sense a co-founder won’t cultivate an environment that would allow you to do your best work, move on.

If you want to dig into the company further, we released a report in Spring 2012 discussing early struggles and learnings (pre-launch). You can check it out here. Big thanks to Victor Mathieux, Drew Moxon, Roderic Campbell, Michael Bina, Julian Bialowas, and Rob Phillips for their help on this.