Early on in the Cascade journey, we were inspired by the likes of Notion, Airtable, Webflow, Zapier, Coda and others that have had success creating “no-code” toolkits for a broad range of use cases. We studied the stories of Airtable and Webflow particularly closely: we believed Howie, Vlad and their teams laid out an example of well-executed code abstractions that made engineering paradigms (databases and CSS, respectively) accessible to a much wider audience. We thought we could do the same with advanced analysis.
From those two stories, we knew that the path to product/market fit would be long and arduous. Webflow experienced a long post-launch period in an “uncanny valley”, where they had enough functionality to be compelling on the surface but not enough to get users to truly invest.
Even armed with this knowledge about our predecessors (and a healthy seed round to power through), we underestimated the length, difficulty and uncertainty that the journey would entail. It’s one thing to hear about a startup deep in the trenches of pre-product/market fit building for years, it’s another thing to experience it.
With the benefit of hindsight, we now have a clearer perspective on code abstractions, where we fit and the questions we should have asked early-on. The companies we looked at broadly broke down into two categories, which have different criteria for success.
Automation infrastructure (Zapier, Clay, Automate.io) needs an exceptionally clear first use case.
A single use case makes or breaks your first interaction with a user, and that use case is likely how they’ll find you in the first place. You need to be exceptionally clear on what that use case is and why your solution is leaps and bounds better than anything else. Many companies I’ve talked to hedge and list the several use cases they’re just ok at — that won’t work. Only after solving a single use case does a user consider using the same infrastructure for other things.
For Zapier, the killer use case was getting data out of Salesforce. For Clay, the use case was auto-enriching leads for sales teams.
Toolkits (Webflow, Notion, ProductBoard) need an exceptionally clear, reachable audience for whom the tool is a gamechanger.
Toolkits are designed around the workflows of a specific function. If done well, they have the potential to be the “IDE” for that function, capturing the attention of their audience for a good part of their working day. To do that, toolkits often need an exceptionally large about of functionality before they gain any real traction — companies can push through that slog if they maintain a laser focus on an audience they understand well.
For Webflow, the function was non-technical startup marketers that needed to build websites. For Notion, the function was product managers in San Francisco.
Note: absent in this discussion are Airtable and Coda. My belief is that these companies are the exceptions that prove the rule: they eventually found traction and have built healthy businesses, but they both wandered significantly on that road, burning capital and exhausting people along the way. I don’t believe there’s a playbook to be built there.
Cascade (and, I would argue, other analytical tools like Causal, Equals and Canvas) had components of both categories, required by the peculiar nature of the analytics space. Being an “automated analysis toolkit”, sat us right in the middle and further confused our situation. But we had neither a super clear use case nor a super clear audience, though we had loose versions of both. If we had declared ourselves automation infrastructure, we would have struggled to identify the specific use case that would be our “killer app”, given how bespoke analysis tends to be from company to company. But if we declared ourselves a toolkit, we would encounter a similar issue: business analysts are generally not consolidated into one function, but they’re called various things throughout various portions of most organizations.
We eventually were given major cause for pause by asking one question: what portion of the audience we were trying to reach would spend more than half their day in the app? The number was certainly greater than zero, but we were also trying to sell the tool to teams for whom there was no reasonable chance we would fundamentally change the way they worked. That meant that either our audience was too small or our value proposition was not sharp enough.
Some questions we should have asked that would have helped early-on:
If building automation infrastructure:
If building a toolkit:
