Unfortunately today I am announcing that we are shutting down SmarterCloud.  The decision was a long and painful one, but the team ultimately realized that we could not achieve our vision of being the leader in insider threat detection.  If you hit me up on LinkedIn or Twitter, I am always happy to dive into the myriad reasons this happened, but for this blog post I wanted to list the three key mistakes I made as an early-stage founder.  I also want to highlight that they are mistakes, as I think it is really important to admit failure and not spin this into “it was a learning experience and yay everything is cheery!”  As I’ve written before, there is way too much in terms of sunny materials on the Internet that paints everything optimistically.  Realism in entrepreneurship is sorely lacking.

Lesson #1: Do Not Validate Past the Close.  We had amazing success early on getting our message to resonate in the marketplace.  Through a series of customer interviews and the team’s prior industry experience, we realized there was a massive gap in the tooling available for insider threat detection on cloud infrastructure.  Lots of competitors existed to prevent insiders from leaking Salesforce or Google Drive data, but there was almost no one focusing on Amazon Web Services and Microsoft Azure.  By analyzing compute and storage log data, we could build an anomaly detection platform that highlighted “hey, this person is downloading data off of EC2 and that’s kind of fishy”.  Pretty straightforward concept, glaring market need.

Being an early stage startup, our approach was to raise the minimal amount of funds we would need to get 9-18 months worth of runway to pay ourselves and a few of our former security and data engineering buddies a bare bones salary, plus a WeWork office.  This strategy led us to entering awesome business competitions like the New Venture Challenge, which focus on telling a story of how your product will fit and scale in the marketplace.  Unfortunately, this led us to “validate past the close”.  As soon as large enterprises told us they were willing to pilot our product, our fingers should have hit the keyboards coding.  Unfortunately, we spent too much time after customer validation on message refinement and pitching.  If we had hit the keyboards coding, we could have gotten something for our customers to play around with and provide real field data feedback, which is invaluable.  By the time summer rolled around and we started coding, the 800-pound gorilla in the room had released a major competitor.  That valuable time lost was because we did not understand…

Lesson #2: Money is a Lagging Indicator, Not a Leading One.  This one is oft-repeated online, but easy to dismiss.  Successful founders who have raised unicorn-status funding say, “I can not wait to get back to building my product!” or “The company is about our customers, not our investors”.  Another way to put this is, “By the time you have raised money, you have already succeeded at that stage”.  We viewed capital too much as a goal in itself.  By raising money, we felt we could do more.  Get an office.  Hire our friends.  But what we did not realize was that the investment is a lagging indicator.  By the time a venture capitalist decides to invest, they have already made you grind it out for months, if not years.  Behind the overnight successes are journeys that took a decade or more.  Instead, companies should focus on…

Lesson #3: Build a Viable Product, Not Just a Minimal One.  The Internet Zeitgeist, along with a lot of modern concepts in Design Thinking and MBA entrepreneurship courses focus on the “minimum” portion of MVP, not the “viability” portion.  For example, people hoping to launch a phone app are encouraged to show people storyboards and pictures of how the app “would behave” rather than rushing to write code.  And, to be fair, that process helps weed out really poor ideas.  If you want to build the next Facebook, putting some diagrams in front of people may help you realize, “Jeez people already really like Facebook enough”.  But as soon as you get even a single person saying, “Yes I would buy what you have described/shown to me, where do I sign?”, start building.  The product has to be viable.  We had several schematics and detailed architecture diagrams of what our product would do, but little in the way of demonstrations.  In today’s world of freemium, it’s just really hard to get anyone to pay for schematics.

In fact, Eric Ries, founder of The Lean Startup movement was recently on an episode of Nick Moran’s venture capital podcast The Full Ratchet discussing this exact same concept.  When Ries did consulting for General Electric to help bring “the startup way” inside the corporate behemoth, he got resistance that if the company focused too much on the customer and their needs, they would miss opportunities to get real revenue.  He clarified.  He did not want GE to bring diagrams of a potential engine to customers to see if they wanted to use it.  Rather, he wanted to find some viable product that could be sold without spending months or years in the R&D phase.  So, the company found an existing engine that was completely functional, but could be used in a new application.  While research and development continued on improvements to specifically meet the needs of the new industry, GE was bringing in revenue and new customer insights based on actual field data.  But there was a viable engine being deployed! And that is the part of this story I feel is often overlooked.

As with most founders, I am extremely proud of my incredible team and the work we accomplished.  Since most of us were students throughout the experience, we are landing on our feet at new gigs across the country (I’ll have more to say on my next journey in the coming months).  There is still space for a bold vision on deterring cybersecurity threats in the enterprise, and lots of work to be done, so I look forward to seeing how our friends and competitors carry this sector forward.