Five years ago, we embarked on one of the most unusual—yet at the same time, one of the most exciting—projects we’ve ever undertaken, because it allowed us to learn more and better from our clients and help them make smarter choices regarding their technology decisions. Interestingly, it came from a client that didn’t even seem to fit our profile at the time: a very large venture capital firm in the United States. This firm had led an investment round for one of the startups we had helped build, and knowing that we had worked closely with them, they posed an intriguing question: “You’ve worked with many startups—do you keep data on everything you do?”
At that moment, I suspected they wanted to buy something we had developed for a startup that had failed in the past. I thought about the implications: our work is 100% confidential, and we had signed NDAs with our clients, so it didn’t make much sense to continue the conversation—plus, I would never throw away more than 20 years of experience. So I replied, somewhat warily: “Yes, but that information isn’t available.”
The man asks me again, quite insistently, "Are you familiar with the concept of 'patterns'?"
As a former software design instructor, I replied confidently, "Of course I do—I spent 18 years teaching that very concept."
He continued, "Well, I'd like to see if we can identify, across all the code and other information you have, the commonalities among successful startups. If you think that's possible, let's talk in a few days…"
I was both taken aback and excited; I hadn't imagined that was his intention, but suddenly, the idea struck me as brilliant. Identifying predictors of success in the behavior of the startups we've worked with in the past…brilliant!
After giving it a lot of thought, I accepted his proposal a few days later, but with an even more interesting twist: "Let's do it, but let's also undertake a project that we consider even more useful: let's find out what startups that fail have in common." Our reasoning: failure is common and widespread, while success is an atypical event—or rather, rare.
To provide some context, we’ve been helping startups for 26 years. We started back when they weren’t even called that in Latin America. We began by working with some of the “pioneers” behind solutions that exist today, such as Bumeran (a Latin American version of Match.com) and Yahoo Encuentros (the vintage version of Tinder), and we’ve continued to help more companies build their products, primarily in Argentina and the United States. This many years of experience has allowed us to assist founders in decision-making and to understand the unique challenges of building technology for a company that hasn’t yet succeeded and will pivot many times until it does (or fails). For various reasons—some internal and others less so—our portfolio has a success rate more than 10 times the regional market average, and this is what made us an interesting subject for the study.
To carry out the analysis, we brought together several key members of the Digbang team. We’ve all been working in technology and data for many years, but we were fortunate to have one of our leaders on the team who has a background in mathematics. With her help, we developed a small-scale study method where, by analyzing code, analytics, and project tracking, we ultimately determined which independent variables were the most relevant predictors for distinguishing between success and failure.
Since this is a private study, there’s good news and bad news. The bad news: we can’t publish it. The good news: last year we were given permission to share some data on what we call “failure predictors.” Here are some of the findings we found most interesting, along with a few tragicomic stories we encountered. The sample we used for the study consisted of 130 startups from different industries and of varying sizes—roughly the number of companies we had helped develop up to that point—led by both technical and non-technical founders.
First finding: Startups that focused more on technology than on the user were three times as likely to fail (excluding DeepTech cases).
A rather unique example that illustrates this point was a company whose CTO had us conduct a stress test to handle 200,000 daily users within six months. The reality, far from the CTO’s fantasies, was that the startup’s all-time peak never exceeded 3,000 daily users. Another similar example: A well-known startup (with over $20 million in funding) that we built from scratch hired a CTO who ended up rewriting the entire product in his favorite programming language; it took him a full year using a team three times larger than the one that originally built the product, and the startup shut down less than a year later.
Second finding: The difference between successful startups and those that failed in terms of the number of changes made to the original prototype (or plan) over the following 12 months was staggering—more than four times as many.
One example of this was a blockchain-based startup that extended its “MVP phase” by 21 months, essentially building the entire product we had envisioned during the Discovery phase, in order to have an “unbeatable” product at launch. The wait didn’t pay off: within two months of launch, the number of changes needed to adapt “the ideal product” to the needs of early users exceeded six months of work, and by the tenth month, they downsized the team due to budget constraints.
Third finding: More than 70% of startups that failed wasted nearly 20% of their code on features they don't use (or that are used by only 5% of their users)
As I tried to recall an anecdote related to this statement, something strange happened to me. It’s such a pervasive problem that I can’t focus on any one example in particular. What we generally see are two groups: those who rush to build things they never use, and those who want to generalize every scenario they encounter, creating, without a doubt, super elegant, maintainable, and scalable code—they’d get an A in college—but it’s very unrealistic for these scenarios.
In all these cases, our job goes beyond helping these companies design and build their products; we also strive to influence them so that these biases do not affect them. In our experience, it has been easier to positively influence companies where the founder is not a technical expert, as well as those where there is a technical founder with a strong track record as a CTO (who does not serve as a programmer on the project).
We have several theories about why this happens, but explaining them would take even longer than this article, and we’ve made a few enemies by mentioning them... so we’d rather save them for one-on-one chats and avoid getting flamed for bringing them up publicly ;)
Demian Schnaidman is the CEO of Digbang. Connect with Demian here.
.svg)
.png)
.jpg)
.png)
.png)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
