@jdvhoutenWith Thymer, our planning IDE for makers, we’re entering an enormous and established market of productivity software. We’re fully aware it’s a crowded space where most newcomers fail. Consequently, we need to make a good product and we need a moat. This post is about the second part, building a moat.
Before we get to that, let’s see why the conventional wisdom of building a really small MVP works for other startups but not for us. The conventional wisdom is straightforward: You have an idea, but you don’t know if the idea is any good. What do you do? You contact a bunch of people who you imagine to be prospective customers and you talk to them and ask them if your idea makes sense to them. If they seem receptive you slap together a minimal product with various nocode tools. A form builder puts rows into a google sheet, which in turn sends an email to a remote assistant that executes steps to be automated later. Use a site builder to pitch your idea. Collect some credit card numbers and you’re off to the races.
The assumptions here are (1) you can figure out what the market wants by talking to people and (2) you can demonstrate viability by duct-taping some tools together. If customers aren’t biting then no harm done. Fail fast; try again.
There are three major downsides to this approach from my perspective. First, if you simply build what people ask for then you can never create a revolutionary product. If Henry Ford had asked what people wanted they would answer “faster horses”.
The second downside is that the only products you can build are those that lend themselves to quick prototyping. You can build a MVP for, let’s say, an Invoice Scanning service. You advertise it as powered by an AI-based Deep Learning Neural Network. In reality you just outsource the data entry work. You focus on growing your customer base and when you’re confident you’ve got that part figured out you start on your AI wizardry to make the product real. Aside from the ethics of this approach, the strategy works[1].
Now consider a product that can’t be faked as easily. For instance, a new high-performance database. You could talk to tech companies and ask them if they need a better database (they’ll say yes) and if they’re willing to pay (also yes) but this doesn’t tell you anything you don’t already know. This is a product-first startup and if you don’t have a product to show people you don’t have anything.
The third downside to the nocode approach is that even if you can get your startup off the ground this way, what you end up with isn’t going to be a tech startup. And if there is no tech, where does your moat come from? If your product can get cloned easily it will get cloned the moment other people figure out you’re doing well. Sure, competition is inevitable for any startup and you can try to out-execute everybody. Still, there are always people who are as smart as you are but more ruthless and willing to work harder. If at all possible, you want to avoid an attack by clones.
If you have to solve some schleppy technical problem in order to make your product stand out the equation changes. The downside is that it requires a much bigger upfront investment to get a first version out. This implies a much bigger opportunity cost in case you build the wrong thing. In addition there is execution risk of having to do substantial rework as you learn more about the market. Small prototypes are much easier to change.
The upside is that having to do a lot of work up front discourages the competition. Anybody who successfully clones Figma will do very well. Daunted by the work it would take, the aspiring cloner will look for easier opportunities. Figma’s technical excellence makes their users happy and keeps their competitors at bay. Win-win. If your product requires hard technical work you eliminate a large chunk of the competition. Most startups are started by business-minded people who have only a secondary interest in tech. They’ll avoid hairy tech problems because that’s not where their strengths are. Good software engineers want to work on their own ideas and don’t want to lazily copy somebody else’s. If you create a product that requires some real technical skill to pull off you take a slightly bigger risk but you get a moat in exchange. That’s a good deal, if you ask me!
All good businesses have a moat. Without a moat market participants are forced to compete on cost which results in a race to the bottom. In this scenario everybody loses, including the customer. You can’t offer decent customer support or deliver a good product when you’re forced to cut every corner just to survive. You don’t want to struggle to survive. Where is the fun in that?
When you’re good at tech but not great at marketing or sales it makes sense to lean as much on your tech skills as possible to give your startup an unfair advantage. It’s never a big mistake to lean into your strengths. In some circles the approach where you do months of coding before talking to any customers is considered lunacy. I don’t think this is justified.
Sometimes building a better product requires solving some hard technical problems. You risk building the wrong product by solving problems nobody cares about. That’s just the price you pay for entering a market with something new.
[1] One of the poorly kept secrets in the valley is that many of the AI startups fake their product like this.
