Board

When reaching for a UDF system as a tool to solve a problem, ask yourself this: “am I modifying my own system’s behaviour, or is someone else modifying my system?”. If the answer is that you want to modify the behaviour of your own system, a database UDF may be a good option. If you want to grant someone else the ability to modify how your software behaves, then a SaaS UDF is the way to go. Permalink

Unlike I think pretty much all other professionals that don’t have it within their power to create their own tools – if you work in sales and you want better sales tools, you have to find a software engineer to do it for you – but we are software engineers and the tools that we use are themselves made out of software. So we have it in our power to fix them.

[I] went to work at Foursquare, I quickly noticed that Foursquare had the exact same problem. They had this big Scala code base and it wasn’t scaling. The solution at the time – and I am not joking – was to give all of the engineers a stick of ram, a screwdriver, and to say just upgrade your laptops.

I work on Earthly, another open-source build tool tackling similar problems. To Benjy, though, the important thing is not the potential for competition, it’s the size of the problem. I think an example of how much work there is to do in this space is the fact that Earthly and Pants are so different in their approaches, and yet both really fill in these needs.

There’s so much open space here to fill with good technology that two systems with radically different architectures and radically different approaches can both be very useful in their own right and also complimentary.

But once the chasm is crossed, hallelujah! — those product-market fit issues are solved and the challenge now is to just keep up with demand. Because once you cross the chasm, your company goes from a difficult “push-based market” to one that is “pull-based”, where customers are naturally drawn in.

Moreover, given how fast technology is changing, more startups are spending more time in the chasm… and they may never exit. And guess what? That’s ok.

All of the above means startups will face fierce and changing competition well into IPO territory, given the size of the markets relative to the size of a startup. But the whole point of this post is to argue that companies can still be successful despite never crossing the chasm, including IPO and beyond.

It’s simply a fallacy to believe that in all cases a market matures and starts to “pull” a product rather than requiring a continued “push” from the startup.

Whatever the reason, a product in these markets won’t be become repeatably “easy” to sell until well after it has reached hundreds of millions of dollars in sales. If you have such a product, that’s ok. In these situations, I generally recommend leaning into services. If the product is difficult to insert, you can reduce that friction by making the work to insert the product a core competency of your startup. While margins will be impacted, and sales cycles are likely to remain long, you’ll have more control of your destiny this way. If you’re lucky, over time as the market and partner ecosystem matures, you may be able to offload the integration work to a partner.

You know you’re in a hard, sometimes un-crossable market when it takes a lot of effort to build a business based on the ideal buyer for your product. In my experience, the two most common examples of these are: (1) non-“tech” verticals and (2) tech selling to struggling industries.

Every time I see a startup whose primary logos come from struggling sectors, I immediately recognize that they’re going to have a harder time going to market — their customer base is under duress. Even with a compelling product that has strong ROI for those customers, the churn of a buyer undergoing disruption will be reflected in the numbers. Budgets dry up, champions leave their jobs, projects are canceled, and so on. The hardest part for founders to to accept here is that all this can happen independent of how well a startup executes on its go to market in those markets.

It’s great if an enterprise startup manages to find product-market fit and ends up with a repeatable sales model in a large market, getting to a point where the market pulls them (and not the other way around). In that case, scaling fast is everything.

Why bother then? Because it is always possible to fight your way to success, to have a shot at building something great. Most enterprise companies are built brick by (often miserable) brick. As my former board member and now partner Ben Horowitz once said it best, “There is always another move”.

Last year's focus was on adding serverless flavors of their analytical & streaming engines, plus on expanding their data marketplace features. However, AWS's push towards "serverless" was soon criticized as only delivering auto-scaling capabilities rather than truly lifting infrastructural burdens off the customer. If it does not have on-demand pricing nor turn off fully when idle, it is not serverless by most cloud observers' definition (which is also AWS's own definition when they invented serverless functions with Lambda).

Beyond Redshift catching up to Snowflake on the separation of storage and compute, data sharing, and serverless with on-demand pricing, they have also caught up on data marketplace capabilities.