Cascade allowed non-technical business teams to import large datasets, transform and combine those datasets using a variety of no-code tools, then visualize and present their findings via an interactive data app. For a full overview, check out what Cascade did.
We built Cascade on a few fundamental assumptions, which we go through below. For each one of those assumptions we were partially right and partially wrong — right enough to make the assumption in the first place, but wrong enough that we eventually had to change course. We accompany each one of our assumptions with a deeper dive into what we got right and wrong about each one.
Assumption 1: A booming market of non-technical business analysts is ready to buy better data tooling
Both the founders knew from our prior lives (Jon at Infoscout and Jake at Capital One) that there was a large market of non-technical, data-savvy analysts buried deep inside many organizations. Those analysts were caught between the limitations of spreadsheets and the heavy lift required for code, leaving them with inordinate amounts of extra work crunching numbers and updating presentation charts. That creates a “silent tax” paid by many organizations in the form of time spent by this talented but undervalued group.
If we did our jobs right, we thought we could uplevel this entire professional discipline.
We were partially right. Our mistake had nothing to do with the presence of this market, which in our opinion still exists and is growing. However, the challenge is not how much that market needs a solution like Cascade, but how we could repeatably reach them, much they’re empowered to buy it and how much the solution was worth. Open questions about one of those is likely a surmountable challenge, but in our case all of those were a bit murky. We break that down here:
While our ROI was real, it was incredibly difficult to quantify, and it even more difficult to discover who needed it without talking to them first.
Assumption 2: We could tackle that market by offering a general-purpose, no-code toolkit
We knew that our audience tackled problems that were incredibly business-specific, defying the constraints of more opinionated, purpose-built products. They needed a solution with the flexibility of a spreadsheet but with the power and automatability of code. We were also seeing the rise of “no-code” toolkits in many different sectors, so it felt like the right approach to our problem was to build a composable set of building blocks that could be rearranged to tackle bespoke problems.
We were right that a no-code toolkit was likely the best way to fill in all of those gaps.
But we underestimated two things. First, the more use cases a product can tackle, but blunter the overall value proposition is. The sales and marketing motion for blunt products needs to be incredibly strong, probably stronger than most early-stage companies with founder-led motions can assemble. Each customer cares only about their use case(s), not all the rest of the things a product can do.
Second, because the product did many different things, it was unclear how we would build a repeatable sales and marketing engine around it. Being use case-agnostic confuses everything from marketing messages to sales materials to the talent needed on a sales team. Founder-led sales worked (my belief is that founders can sell virtually anything to a degree), but any kind of scaling or playbook-building was rife with problems.
We’ve since spent a lot of time thinking about why other no-code toolkits have succeeded or not. We break that down here:
Assumption 3: We could take market share from a multi-billion dollar, legacy competitor
The only major player that occupied our category was Alteryx, a $10B+ legacy incumbent. The Alteryx product is both extraordinarily old-school and massive: a Windows-only, desktop product that grew up in the 2000s and was far from modern.
The presence of such a large but obviously flawed incumbent was music to our ears. Alteryx had already done the work to educate the market about the need for products like ours, and it had already tested some important interface paradigms. While its userbase loved the product (a fact we should have paid more attention to), we believed that we could play Figma to their Illustrator: deliver a collaborative, cloud-native experience that was obviously better once they saw it.
But we underestimated two things: the amount of product we would need to build to start repeatably winning, and how high switching costs would be for many of their customers. We didn’t have a clearly identifiable market force at our back, other than broad trends around collaboration and cloud-based solutions. Those trends helped enormously, but we needed more than that to overcome the hurdles we faced.
Over-indexing on a competitor also has more subtle but important effects on how a company runs. We break that down here:
Looking back, we picked what seemed like a very good place to start. We were in a hot space with a unique approach, lots of cash and a great team. But all of those assets also made us overconfident, trusting that were on the verge of success while not paying close enough attention to what the market was telling us. In sum:
- We overestimated our "why now". Even with comps like Figma, we weren’t as clear as we should have been about why the world needed a cloud-based version of Alteryx now. We could have answered that question in a number of ways, but that would have forced us to examine larger market forces more closely, establish allies and try to ride a wave rather than swim the distance.
- We allowed our ICP to fray, replaced by a focus on a competitor. In our fight to prove that we could win against Alteryx, we over-rotated on any customer that might be interested in switching or considering alternatives. While being responsive to customers sounds good, being responsive to any customer creates a slow death of a thousand cuts. In the pursuit of breakout traction, we were too responsive to any sign of that traction, which pulled us in a million different directions at once.
- We fell into a second-time founder trap. There is a long list of reasons that repeat founders do well: prioritization is clearer, more scenarios are anticipated and gaining the trust of the team, customers and investors is all easier. In total, the company can move a lot faster with experienced leadership. We're incredibly grateful for a broad group of supporters rooting for us along the way, some of whom were customers or were instrumental in getting deals done. But we overlooked an important nuance: deals done on the back of personal relationship equity is not the same as market signal. Founders can sell almost anything, and we did. We took those early wins and strode forward, using our ample cash to try to build our way to breakout growth. No product-focused founder is immune from the instinct to build, but repeat founders especially are given the runway to indulge that instinct. We must be especially careful to see the market clearly.
I do believe we executed our play about as well as any startup could. That is to say, I doubt another de novo company will come along with the same strategy and succeed where we did not. I also believe that a version of Cascade that can succeed: one that’s paired with an existing product suite with existing distribution that has access to business analysts (accounting software or data platforms for investment bankers, for example). It’s also possible that burgeoning AI capabilities will help us move past interface-heavy, no-code interfaces like Cascade. Instead, we'll see more automated systems where the user needs to merely dictate the output rather than define the process. If a new company can draw from our lessons and build on new technical advancements, perhaps we will have taken a tiny step towards making life better for the millions of smart, data-minded business people we aimed to serve.
If you found this helpful or if you have feedback, please get in touch.