On Moat

CLVIII

[Product is a Moat; Time Reveals Secrets; Being Patient to be Impatient; 4.5 Terabytes of Champagne Problems; You didn't build it Wrong, you built a Prototype; Money Doesn't Speed up Pregnancy; My Competition Can't See Me; Build a Great Product]

Thesis: Great product takes time to build & resultantly is a really good moat.

[Product is a Moat]

Back when I thought I needed to raise money to start a company, the contrived wisdom that the business world conspired to make an axiomatic truth is this notion that you need some 'moat' to build a startup.

Moats were taught in business school and every single entrepreneurial program I've ever participated in.

It's this notion that you can build something into your business that makes it hard for some hypothetical competitor to copy.

What always befuddles new entrepreneurs and me to this day is the claim that having a really good product is not a moat.

Rather, 'acceptable moats' are usually one of the buzzwords business people love, like 'network effects' or 'intellectual property'.*

Since AI has ostensibly made it easier to ship prototypes that people mistake for products, the 'product is not a moat crowd' is doubling down on the claim that 'distribution is the only moat'. Basically, this means that having followers and a network is the only way to make your position defensible.

Don't get me wrong, distribution is massively important - Jack's great social presence means that it's really easy for us to get eyes on our ideas and products and website. This is huge for the program!

But, much the same way as we'll see about product, this distribution came from a process of trial and error and intense focus on Jack's part to figure out what the market generally cares about content wise. Like anything worthwhile, it takes time to build.

Perhaps not realizing this, some VC / Business type brow beat young, inspired people out of the idea that a really good product is a moat because someone told them it’s not investible or something.

Yeah, you can have a shit product and great marketing and make fast money, but you can't tell me that a company with just as good marketing and a better product wouldn't eat your lunch all day.

It's really, really hard to make a good product. It's an iterative process that is as much as guaranteed to have failures and moments where everything just kind of breaks.

It takes time. And it takes people using earlier iterations to get there. And, as we'll see, it takes the world falling apart and fighting through the fire of things burning and breaking to get it right.

So no, having a great product isn't 'not a moat'.

I believe a great product is one of the best moats there is.

_{*I think the success of social networks have made us over index on network effects for products where it doesn’t matter. And I've always thought that intellectual property was crock of shit in SaaS - why would I file a patent explaining how I do the thing I do when it would be very hard and expensive for me to ever know if you actually copied me? Trade secrets are self evident - of course I won't share my code with my competitors! But if you talk about trade secrets, this VC / Business type gets uncomfortable and typically says that’s not really intellectual property, perhaps because they realize that it collapses into basically the same thing as saying product is the moat, but wait, they're supposed to believe that product can’t be a moat, so I guess trade secrets can’t either.}

[Time Reveals Secrets]

There are some secrets that only time reveals.

No amount of VC capital, LLMs prompting each other in loops, or yapping at networking events will show you the answer to the questions that you should be asking if you're starting a business.

Important questions, like "What features would my customers actually use?" can really only be answered by putting the feature in front of your customers and seeing if they use it. Even then, it's imperfect information - did they use it because you brought it up in conversation? Did only the customers who will churn in one month use it? Do the customers who use it actually end up spending more and staying longer?

The answers to these questions are the ones that you put back into your product.

As an example, so many WhiteWhale customers have asked us for the ability to have different lists with different signals for different use cases. We built and maintained this feature for a while, and people actually used it a lot!

But a lot of people used it TOO much. They would spend time tweaking and playing with it and over engineering with it. And the people who put the most time into this would often get the least value & churn quite quickly. They'd be caught in configuration hell rather than taking action.

The users not playing with this feature a lot generally stayed longer; unsurprisingly, getting rid of the feature increased retention.

So, in this case, neither listening to what customers wanted or even watching the short term behavior of what they used would have shown us the truth - we needed time to observe long term behavior.

I'm sure you can get an intuition about these things, but only by actually testing it. And I think that even someone who has built one great product needs a lot of time with the customer of a second product to build a great product for them, too.

For all I know, if 80% of our users were rev ops people, then maybe that feature we cut would be what actually kept them around longer!

[Being Patient to be Impatient]

In this way, building a great product is a function of staying in the game long enough to actually know what your customers care about.

The longer you're around, the more information you collect, and the better you can make your product. At some point, you've collected enough information that on some axis your product is materially better than the alternatives on the market.

And then you sprint.

For Jack & I, the 'later' in the above quote is now.

And it will be until it's not. We'll hit a plateau and then, if we keep listening, we'll have a chance to learn more than we ever could have before.

And we'll slow down to speed up again.

[4.5 Terabytes of Champagne Problems]

Asides from thinking in terms of user facing features, there are engineering decisions to make it all possible that only become clear after things break.

When we started WhiteWhale, I didn't understand what a database was. 2 years later, I manage a pretty sizable one, at 4.5 TB; more than half of that is one table!

The challenges that this creates befuddle me every 5 months or so during a growth spurt.

Over the last calendar month, we've been adding on average a customer of day, and in the last trailing quarter, added over twice that total.

This not only increased the size of the database, but more interestingly & problematically increased the frequency that it is read & written to.

This can get overwhelming engineering wise, especially when the problems appear all at once. It can feel like the world is falling apart, and you want to scream for mercy.

Until you remember that this is exactly what you signed up for: everything is going according to plan!

Oh no, you have too many customers now!

What a blessed problem to have - it really is what one of my mentors always refers to as a Champagne Problem.

So, you buckle up, switch from a reactive state to a proactive one and aggressively & quickly dispatch with the problems.

[You didn't build it Wrong, you built a Prototype]

When I first started partaking in this pattern of increasingly load leading to too much pressure on the system, I wondered what you might be wondering: did I design something earlier incorrectly? If I would have built it different from the start, would it have been more robust by the time we got to this current load?

To some extent, likely yes, but the same mentor who speaks of champagne problems also re assured me that this is somewhat of a fools errand, attempting to engineer the first draft so well that it never breaks under any conditions.

I was skeptical at first, but now having been through a number of these cycles, I'm utterly convinced he's correct.

The most basic reason cited is that by not fixating on hypothetical problems like having too many users in the future, you’re more effectively able to build a product that solves today’s problems. This is especially true when the hypothetical problem in the future is one of these champagne problems: if you have positive gross margins (gasp) and you get more customers, then you also have more money to solve those problems with!

And money often times does make the problems easier to solve. At the very least, it justifies spending the engineering time to solve them.

Another really important reason to not fret about building something perfectly for all future states is that you just don't have enough information yet. At the start, you've undoubtedly made bad assumptions. The longer you're around, the more information you collect, and the better your assumptions should become. The better your assumptions are, the more confidence you can and should have building on top of them!

As an example, early on, we thought we'd need to collect and store information on decision makers at potential target companies. As it turned out, this assumption was wrong!

Imagine if I would have spent another 80 hours making those tables and python scripts and services more robust and scalable. Maybe there would have been some system wide benefits, but as it is, the code I wrote did exactly what I needed it to: just enough for us to know if we needed it to do more!

[Money Doesn't Speed up Pregnancy]

All of this is to say that building a really powerful product that works at scale takes time and effort and is not some linear, straightforward thing.

It's an iterative process, and I'm really not so convinced that having funding or anything would have sped it up or would speed it up in the case of WhiteWhale.

These things take time and effort and trial and error and all that. Maybe with money you could speed up each step in the function, but you'd still have to be taking the steps.

I don't care how forests you burn by having LLMs spam each other in a loop, building something great takes time and the information you learn by building something bad and then something not so bad and then something okay and then something good.

I'm sure there are experts and wizards who can do it faster than Jack & myself, but even for them, time is still an input.

If a great product is a function of time input, then it takes time for a competitor to come in and copy you in a meaningful way; without time, surely they'll miss many of the important details.

And if a great product puts a buffer of time between you and the competition, well, then, that's just as much of a moat as anything.

[My Competition Can't See Me]

I've talked a lot about what I'm doing in a post that's supposed to somewhat be about competition. After all, moats imply you're keeping someone out.

This is perhaps arrogant to say, but I still don't think I have any real competition. Even the copy cat from ~5 months ago seems to have switched up a bit already (that didn't take long!).

A quasi competitor in the space that raised $60M and sold five figure annual contracts pivoted to copy another quasi competitor that raised $15M; now they both do a free trial + $20/mo base subscriptions for a chat like product with built in data apis & some sequencing tools.

Testing both, I can't imagine that either is profitable with the amount of LLM compute that goes into their free tier. And while our product doesn't do half the things either of theirs does, where it does overlap, I believe our results are much better - based on where their engineering and marketing appears to be going, they still don’t think the part we’re focused on, the research, is that important or differentiable!

So, we'll have people seriously copy us eventually and persist, but they're all fighting different battles right now.

And notice two other facts:

• We've been around for 2 years

• Our public goal of hitting $1M ARR with 2 people implies we haven't hit $1M arr yet!

Judging with VC standards, we're a fucking failure.

By the time anyone realizes they're wrong, it'll be too late, if it isn't already.

[Build a Great Product]

I don't really know why or how it became consensus that a really good product is a moat.

Maybe it has something to do with the fact that building a really good product is just really hard and takes time. Maybe people are so fixated on a silver bullet and capturing the wisdom of really successful people with some repeatable formula.

I don't know what it is. But it doesn't matter. It’s wrong, and that’s a hill I’ll die on.

It's okay to say that your moat is that your product doesn't suck.

Try to build a great product. See how long it takes for the product to actually be great - I don’t even think my product is ‘great’ yet, and it’s been two years!

Try, though. And keep trying. And see how long it takes for someone to copy you.

Live Deeply,