Well, this is the post I’d hoped to never write, but alas, we’ve reached the conclusion that it’s time to shut down DataDistillr. We gave it our best, but in the end we weren’t able to achieve product-market fit.
What Happened?
I think several things led to our demise. Basically, it can be boiled down to changing market conditions, not building the right product and not selling what we had effectively. As CEO, I own all of this and accept responsibility for all this except for changing market conditions.
What I Learned
This is the painful part to write as it kind of makes me sound like a fool…. Ok, so maybe I am a bit of a fool, but it’s very easy to look at all this in retrospect but much more difficult to do so when you’re in the middle of it all. Also, we did do a lot of things well, like building a solid product that worked really well.
1. Monetization: One of the things we didn’t do well at DataDistillr was have a solid plan of how we are going to generate revenue. Clearly, we knew that we were going to charge for our product, but exactly how and what was something that we settled on too late. I’m not talking about specific pricing but rather, the decision of whether we were building a SaaS product, or a hosted product on customers’ VPCs. What ended up happening all too frequently was giving customers free trials that involved a lot of customer success work. For my next project, our goal is to monetize the product from the beginning. We may not have the specifics (IE: Pure consumption vs monthly subscription) decided, but the big picture will be set and that will be up and running from day 1.
2. Building Too Much: It’s often said that startups have to focus. I think at DataDistillr, while we did our best, especially with our advisor’s guidance, to focus around RevOps use cases, by that point we weren’t able to move quickly enough to build out specific features that would have been useful for those use cases. We tried to build something that did everything. In retrospect, we should have started smaller and focused on a small subset of that and really made sure that worked really well.
3. Building the Wrong Things: We spent a lot of time early on, building new capabilities into Drill that made it more comparable with Dremio and Presto. In reality these companies were not our competition. Examples of this were the plugins for ElasticSearch and Splunk. Plugins which were neat, but nearly nobody was asking for them. They were also time consuming to build. In retrospect, about a year and a half into the project, we did a lot of work on stability and security. This work ultimately enabled us to make DataDistillr a true SaaS product. We should have focused on these things a lot earlier on and skipped stuff like the Splunk & ES work.
Related to that, one of the lessons I learned is that the less technical your audience is, the more hand-holding they will want. One of the things we should have done earlier was to build “canned” analytics for data sources such as SalesForce, and Hubspot. That way when a user would connect these data sources, they didn’t have to do any work. They could just connect and go.
4. Not Developing a Marketing Plan: Of all my personal weaknesses, I believe this is one of my biggest. I can do really neat things with tech, but marketing is not my superpower. We didn’t have a good plan with DataDistillr as to how to promote our product early on. I’ve not had great experiences with marketing companies and people. In the past I’ve worked on various projects that have had a marketing component, and I’ve seen us pour tons of money into marketing with very limited return on that investment, so it’s personally difficult for me to spend money on it. For my next startup, I see marketing as absolutely essential and as such, our first hire will be someone who has experience marketing early stage startups. I don’t have such a person in my rolodex, so I will be leaning on our investors for assistance finding such a person. But, I believe that this is will be the success or failure of the company and so we will be doing this from the beginning.
Along these lines, as soon as the MVP product is deployed, I think it is really important to have a sales pipeline plan developed.
5. Hiring the Wrong People: In general, I think we hired good people, however we made a few hires that were not good fits and I kept them around for too long. I’m not going to name names, or do anything that would embarrass anyone. I think everyone we hired were good people but maybe not good for us.
I also didn’t fully appreciate the importance of having people who had early stage startup experience. In other words, hiring someone with 20+ years of development experience isn’t necessarily a bad hire. But if that person has never worked for a startup before, they won’t understand how startups should operate and might not be the best hire.
I also fell into the trap of hiring junior staff and interns because they were less expensive. The issue this caused was that they required more supervision and management than we really could give. Not going to repeat that.
6. Hiring Too Quickly/Burn too high: When we did our initial raise, the market was booming, and people were literally throwing money at us. Our investors were pressuring me to hire, so hire I did. In retrospect, this was also one of my biggest mistakes as we ended up driving up our burn rate far too quickly, relative to our revenue. For the next startup, I will be much more judicious when it comes to hiring and trying keep our burn as low as possible, especially until we can show solid revenue and growth.
7. Not Relying on Contractors: One of the things I think we should have done early on was identify tasks which could have been contracted out. I don’t think this was a big issue, but going forward, if we identify tasks that lend themselves to a short term contractor, being better about using contractors for short-term tasks.
8. Focusing on Enterprise: This one I’m still on the fence about which is our early focus on enterprise. Early on, we decided to go after large enterprises as customers. We ended up having precisely zero success in this but spending a lot of time on it. Some of this was due to bad luck. As an example, we had a potential deal with a major medical device company. We had budget allocated, NDAs signed, an internal champion, everything was heading in the right direction. Then our internal champion left and we never heard from them again. This happened to us with Deloitte as well. We were working with a group from Deloitte and they really seemed to like us and wanted to partner with us for government contracts. We had meeting after meeting with them, NDAs were signed, we were working towards an MOU and then crickets. We found out later that the team lead with whom we were working got a job at AWS and never told us. We were working with SAP as well, got the project scoped out, everything was going well, then all of a sudden, they had to put it on hold for budgetary reasons but wanted to resume in a few months. We never heard from them again and our emails started bouncing back.
The bottom line was that we wasted a considerable amount of time going after these kinds of deals that just failed to materialize for one reason or another. This also affected our roadmap in that we assumed that we would get some enterprise customers so we built features and architecture that were important to large enterprises. I don’t know that it was necessarily a mistake to go after large enterprise, however, I do think we could have handled that differently. Perhaps waiting until the product was more mature. I’m still not sure… However, for our next startup, we will not be targeting large enterprises until later in the company’s development.
9. Not using the Build/Measure/Learn Loop: One of the things I didn’t do at DataDistillr was to rely on customers to tell me what they wanted. We kind of went all in on the build part and not so much on the measure/learn parts. For my new company, I am changing that approach.
The bottom line is that for my next project, I want to built the absolute least as possible and collect user feedback before investing time and resources in something.
10. Better Communication with Investors: One of the things I want to do better next time is keeping our investors in the loop. We met regularly with our main investors (Foundation and BVP) but I didn’t do a great job of keeping our investors regularly updated as to progress, both good and bad. A personal goal of mine is to issue monthly reports to all our investors.
11. Doing “Free” Work: One thing which happened all too frequently was that we would have initial meetings with a potential customer. They’d lead us to believe that they’d buy our product if we did X, Y or Z. We’d assume that they were telling the truth, and dive into all kinds of work for the customer to get them to sign up, only to have them never sign. My next product is very different in terms of business model, however, the goal is to make a product which sells itself without the need for much human intervention in the beginning.
12 Controlling Non-Salary Expenses: In general I think we did a good job of controlling non-salary expenses, however there were a few expenses which I think we could have done better at minimizing. The main categories were professional services such as legal and accounting. I was advised early on to retain an attorney from a big firm for the VC deals. In retrospect, this was a waste. When we did the BVP deal, we ended up spending a ton of money on both our attorneys and theirs. Every meeting with them, they would being tons of assistants and charge us through the roof for their time. I don’t know if having a “big law” attorney is good for optics or not, but I personally do not believe that they delivered value relative to their cost.
What’s Next?
Well.. I was looking for a job for the last few months, and let me say that the job market is truly horrendous. I’ve also learned that I don’t do well on coding interviews. Maybe because I generally work on actual problems that real people have instead of contrived BS.
But, I’ve found something recently that I’m enjoying and it combines AI and Security… So stay tuned…