I recently posted an article about the demise of DataDistillr. It was painful to write and I was worried that by doing so, it would make me look very foolish. After all, I was documenting what mistakes I felt I made that caused the failure of DataDistillr. I didn’t want to point fingers at anyone other than myself, but I did want to share some lessons which I learned that hopefully will help people in their startup journey. I did get some heat from some folks in an online community which I joined. I won’t name names, or print quotes but it wasn’t kind to say the least. (One even called me a troll!!)
With that said, after reading my list, I couldn’t help but notice that these lessons are all the things that every founder is supposed to “know”. Concepts such as stay focused, hire slow, fire fast, etc. Every founder should know these things… How is it that I didn’t?
The answer is that it isn’t so simple. When you are in the thick of things, you have to make choices while juggling many different priorities, and the answer isn’t always obvious.
I’m going to present you with a situation that actually happened to us and give you the chance to decide what you would do if you were in charge. I’m changing the details slightly so that nobody gets embarrassed but the substance of the interaction is something that really happened to us.
Here’s the situation: You have a meeting with a data analyst from a prominent investment firm. You have been chasing the person for several weeks. The individual in question runs an analytic team, and has the pain points that the product was meant to solve. She has budget and really likes the tool. She would like to use the tool to craft analytic queries that join Excel spreadsheets with some financial APIs and ElasticSearch.
She believes that our tool would be an ideal solution, however in the present state, it does not support ElasticSearch. Our query engine, Apache Drill did support ElasticSearch (ES), however, our tool did not have the necessary UI components to allow a user to connect to ES and execute queries. Now, adding ES to our tool was part of the roadmap, but we had not prioritized it until we had customers asking for it. Here was that exact situation… a major customer was asking for this feature. For some perspective, we estimated that it would take about 2 weeks to add the required functionality to the tool to query ES.
The ideal situation would be to ask the customer to sign an agreement to buy the product conditional upon our team adding the ES functionality, however they’re not willing to do that. They just want to buy a product that is ready for them to use. They are not willing to pay until they can use ES with the product. But, they say that they are willing to pay if we can get ES to work with our tool.
What Do You Do?
One answer would be to walk away. Tell the customer thank you very much. As soon as we have ES integrated, we will reconnect with you. This option is obviously fraught with risk in that you risk losing the customer entirely. But, you do have the advantage in that you are not making any diversions from the roadmap and your priorities.
Another option is that you are willing to add the ES functionality and that it will take about 2 weeks to do so. You could offer them that if we do so, would they sign a contract with us? This approach has the obvious advantage in that you could close a big customer. Also, it shows the customer that you’re willing to do what it takes to get their business. The risk is that you could end up doing a lot of work for nothing since you don’t have a signed contract. You also could end up doing work that only benefits one customer and diverges from your priorities and roadmap.
What Actually Happened?
Well… what if I told you that we decided on option 2: to build the ES functionality. But what was the result after that?
Now if I told you that we built the functionality, then the customer tried it out, liked it but didn’t buy, you’d think… the team shouldn’t have broken away from their road map and just said no to the customer. This would be the most dogmatic approach, but it also would pretty much guarantee that you wouldn’t get that customer ever.
But what if I told you that we did the work, the customer was really impressed both with the tool and our customer service. As a result, they signed a contract and became one of our best customers. You’d think that was a gutsy move that paid off and that our team was solid in that we delivered on a tight timeline. Win-win.
So what actually happened? I’m not going to tell you… I’m going to leave you to ponder this. You see, being a startup founder is really f-ing hard. You have to make hard decisions like this one every day. Sometimes you make the rights ones and sometimes you don’t. If you take the cautious approach every time, you likely wouldn’t have a startup in the first place.
The bottom line is that despite all the advice and “rules of thumb” that are out there, it isn’t always obvious what the right thing to do is.
What were the challenges the author faced in documenting the mistakes that led to the failure of DataDistillr, and how did they respond to criticism from an online community? regard