A common piece of startup wisdom is that you should go for a “single miracle startup”. If your startup requires no miracle at all to happen you’re probably aiming too low. If your startup requires multiple miracles to happen then failure is almost certain. A single miracle startup hits the sweet spot.
Why is it a bad idea to start a zero miracle startup? Suppose you decide to clone a simple but moderately successful B2B web product. This doesn’t require any miracles to happen. If the product is basic then cloning it shouldn’t even be difficult. Then it’s just a matter of finding customers and improving your product. As your product gets better you’ll get more customers, and as your marketing gets better you’ll get more leads. You can grind it out this way. It takes a long time, but you’ll get there eventually. A market that has a number of profitable businesses can always support one more, after all.
A big problem is that if your product and your business model are entirely derivative that any kind of runaway success is unlikely. It’s hard to get good press if your product is uninspired. Word of mouth can be one of your strongest assets, but the enthusiastic early adopters have already tried the original. They’ll pass on your clone. Those are pretty serious headwinds.
The odds that your clone will be more popular and more successful than the original are not good. Which means that your success has a ceiling. A pretty low one. You could clone a very successful product, but that’s way harder. If your product is just like Slack, but substantially worse and unfinished, who in their right mind will buy it?
You want to make your product different and therefore better at least in one dimension. You can make your product way faster, and distinguish yourself that way. Or you can make your product super easy to use. Or very pretty. Or integrate heavily with a popular platform and then your product will be the best X for users on platform Y. Any of these are better than straight-up cloning a product, but it’s still not optimal. You want to be so different that there’s a pretty good chance your product flops completely.
If you take some big product risks and it turns out there is an audience for it, then your product could create a new niche overnight. Your product will be the only one that meets a formerly unmet need, and that’s a big tailwind. This requires a miracle, but only a small one. It means that you don’t have to fight as hard to win unhappy customers from competitors. You’ll still need to do marketing, of course. People have to know your product exists.
We live in a huge and diverse world. Even wacky products end up with many devoted fans. By taking a seemingly riskier route, by making a product that is a little bit “out there”, you actually get better odds of success.
In many spaces you can find yourself competing against very large players. I’m convinced that as long as you build something which your users love, it’s possible to grow your business in those spaces even as an indie/tiny team.
For our existing product, we had a large competitor when we started, and another large one emerged afterwards, so we’ve had some experience with this. Around ten years ago we launched a company intranet SaaS tool for small companies. Lots of the software at the time was either very slow, clunky or enterprisey/complicated.
The large competitor at the time was Confluence, and to a smaller extent SharePoint. We launched with a nice drag&drop editor with blocks you could drag on a page to create wiki docs, forms/databases, share files and so on. If that approach sounds familiar, you might have heard other companies which then launched afterwards like Notion. Not exactly tiny players 😉
Even as a small indie shop though, it’s been a great market for us. With Thymer, the app we’re building right now, we’ll again be competing in a busy space. For the same reasons it worked for our first app, we think competing in a market with larger players is definitely possible again, by having our own unique ideas and focus.
We focus on a different part of the market
Having a large competitor also means the market is large. It’s very rare for any product to be the best in class for every single person or company in such a large market.
If your solution is better for a subset of those users, a specific niche in the market, go after that. The reason you’re building a product in the first place is probably because you have a vision to make something better, improve on something. So focus on that and zoom in on what makes you different. Positioning yourself in the market this way helps you stand out.
Taking the example of our existing app again, we specifically focused on “intranets for small-medium companies” there, and that has worked out great for us. Technically we could have positioned it as “note-taking” for consumers, or a “wiki” or enterprise software. Especially as technical founders with a very horizontal product, it would have been tempting to try to be “everything to everyone”, but it makes it harder to get traction (especially when starting out without network and choosing the bootstrapped route). We found a corner of the market which was ripe for disruption and zoomed in on that.
With Thymer too we focus on a very niche audience. If something catches on, you can always grow from there. Even something as niche as “people who have todo.txt files” in our case will probably be a good starting point to grow from (that includes plenty of makers and small creative teams we should be able to reach). We don’t bother competing against feature sets of large public project management companies.
There are many other ways of carving out a corner. Like taking a single theme, such as products focusing on privacy when their competitor doesn’t. Or launching in a very specific vertical you know a lot about and a solution doesn’t exist. Or by using any other aspect of your product, like a unique pricing model.
We use our small team size to our advantage
There are always things your larger competitors simply won’t be able to do.
For example, we have competitors where the growth and profit clearly comes from the enterprise segment. They can’t afford to focus too much on smaller-medium businesses, which works well for us.
We also focus on automating a lot, keeping costs low and run the company as a tiny team with no investors. That way we can charge prices in segments of the market which competitors simply cannot match but are super profitable for us.
You can also jump on new trends much quicker. You’ll make a change or publish something before your large competitor can say “circle back re- outlook meeting”. A canoe will turn faster than an oil thanker after all. That can turn existing popular products stale, which is an opportunity for a new small player. You’ll be able to expand in niches this way, which competitors will happily ignore.
Even aspects which might seem like a disadvantage at first can be a benefit. Take handling customer support with a tiny team. Especially when we just started out and didn’t have the social proof from larger customers yet, companies would email us from time to time and ask about our support structures, and whether we could support a company of their size. Well, how often does it happen that you can email the CEO of a large company directly, they will look into your issue personally, and reply with a fix within a day? So far customers agree that’s a real benefit!
We don’t worry about the competition
Finally, it’s important to just stay focused on your own vision and don’t mind the competition too much. We just build what we think and know our customers love. When we just pay attention to that, the rest will fall into place.
The internet is a really big place, and even with large competitors who will out-marketing or out-spend you, there will always be plenty of people you can find who will prefer your approach! Especially as an indie maker, you only need a small % to be successful (even more so in B2B, where a dozen or two customers might literally be enough to run your business).
Not saying you shouldn’t dream big though if that’s your goal! Here’s a fun thought experiment. Let’s say you would have launched just a bit earlier than a competitor, or the press had picked up on you sooner. Would your competitor have been unsuccessful? Would they have canceled their product and launch? Probably not, and neither should you. As long as you have a product that users love and you can reach them – and that’s where the real challenge is of course – the chance that you cannot coexist with (or even outgrow) large competitors is extremely small.
Technical debt is typically understood as the consequence of shortcuts programmers take to meet a deadline. At some point in the future this debt is repaid by cleaning up the code, or so the basic finance analogy goes.
Technical debt, much like debt in the real world, is not all created equal. Some types of technical debt come with a high interest rate and put serious constraints on what you can do in the future. Debt like this can easily ruin your startup. Other types of technical debt just exist, harmlessly, like a 30 year mortgage bearing a 1% interest rate.
You want to distinguish between the different kind of shortcuts you can take and the ways in which the debt can bite you. In this post I expand the use of ‘technical debt’ so all design choices that create future obligations are considered debt. You can accumulate debt to the point where you spend all day every day dealing with these obligations. You have to work longer and longer hours just to avoid drowning. Any additional setbacks and you’re going under. The financial analogy here is that you don’t want to get to the point where the majority of your income is eaten by interest payments. You won’t have a good time digging yourself out of that hole.
I categorize tech debt roughly like this:
Sloppy code debt. This can be anything from gratuitous copy-pasting to a hairball of dependencies between different parts of your stack. This is what most people think of in the context of Technical Debt. Harmless technical debt in this category is inside self-contained in edges of your architecture. Self-contained parts are easy to understand and easy to rewrite if you need to. The worst kind of debt in this category is at the core of your app. If the code you have to deal with all the time is a mess that’s going to slow you down and result in bugs.
Creative user debt. Your users will use your app in ways you don’t anticipate. Suppose you introduce a ‘tags’ feature then some users will inevitably try to add 100 or 1000 tags in places where you expected people to use at most a handful. If you’re in a hurry and don’t at least assert()[1] to put a cap on the number of tags that can be associated with a thing you’ll wake up one day to an email from a user about the app being slow. After some minutes of confusion and looking at some SQL logs you figure out what’s going on. Goodbye road map, hello long days of frantic repair work.
Not making a nice error message when a user adds to many tags? Harmless tech debt. Having the UI glitch when there are a silly amount of tags? That’s fine, too. Having servers melt down because you didn’t spend 10 seconds to enforce limits? Not worth it.
Package dependency debt. Software you write today will stop working sooner or later, and often much sooner than you’d think. Sometimes people call this bit-rot, as if software suffers from biological degradation. It doesn’t, of course, but the environments we write software for change and that amounts to the same thing. Server-side packages get patched for security updates, as does the OS itself. On the client browsers change and break your code.
When your app is large and has many dependencies this kind of debt isn’t just a chore to deal with. It can actually become a real problem, especially when you’re forced into version upgrades in order to get those security patches. It gets even worse when you compile your own packages or deviate from the packages that come with your OS. Have your app depend on 250 packages? That’s easy. Monitoring 250 packages for security vulnerabilities? Practically impossible.
To mitigate this we think it’s best to roll your own solution instead of adding dependencies to your app, whenever possible. It’s more work up front, but your code will solve exactly the right problem and once it’s done it will continue to work with minimal maintenance.
3rd party integrations. All integrations with 3rd party services create debt and debt of this kind is always bad. Every integration you make with a 3rd party is going to break, and probably at the most inconvenient time. There is a time for caveats, but this isn’t one of those times. Any 3rd party you depend on is either (slowly) going out of business or they’re growing so quickly that they have growing pains and need to make breaking changes to cope. In the past we’ve built integrations with Slack, Twitter, Google Maps, Google Analytics, Google Workspace né Google Suite né Google Apps, MS Active Directory and more. They have all completely broken down, at some point or another. The ongoing cost of integration maintenance is real and not to be underestimated.
Overengineering debt. When you overengineer you make something stronger than it needs to be. When you under-engineer you make something that you expect will collapse sooner rather than later. This might sound bad, but it isn’t. You can’t predict where the bottlenecks in your architecture will be in advance, especially in the face of exponentially growing traffic. Exceptions notwithstanding, the simplest pieces of architecture are the easiest to diagnose and improve.
If we have to choose between having extra package dependencies (debt of itself) and a brittle 100 line Python script we’ll go with the Python script every time. Sometimes the hacky solution keeps working for years with zero issues. Using your SQL database as a message queue? It’s not pretty and it requires polling, but it’ll work and your customers won’t know the difference. Do you want to wake up a script? Polling a file’s atime or sending a SIGUSR signal is no crime. Customizations for customers? You can hardcode them. It’s fine.
Feature debt. Sometimes features turn out bad and confusing. If at all possible, you want to get rid of those features right away. When you’ve just launched you can still delete a feature without notice. Once you have paying customers removing features from your product becomes a far more delicate matter. Sometimes two features are fundamentally incompatible, and by introducing one feature you can’t introduce another. For instance, if you promise end-to-end encryption you can’t also offer server-side search functionality (the inverse is also true). Once you realize your mistake you have to fork your code and you’ll end up with customers on both forks.
Make this mistake 5 times and you’ll struggle to keep the different versions of your product apart. This will slow your development efforts down to a crawl. Every feature has a recurring cost to it, in maintenance and in the space it takes up in the user interface, so you can’t afford to add features haphazardly.
Customer support debt: when you build a feature in a rush and don’t spend enough time making the interface intuitive you’ll also pay a price in customer support. This debt isn’t so bad because the cost of the fix doesn’t increase over time. However, if you find yourself repeatedly answering the same questions that’s a problem. Either make the feature good and self-explanatory or only enable it for a handful of users. If you allow poorly conceived features to accumulate you’re not just creating a lot of support work for yourself, you also alienate your users. A backlog of support tickets can also be considered a type of debt.
Every startup accumulates some technical debt. This is inevitable, and it’s not even a bad thing. When you start out you don’t know exactly what you’re making. By writing and rewriting your app your figure out what works. No point in creating beautiful code if you’re likely to rip it out in a week or two anyway.
Besides, before you have any users technical debt isn’t real. Anything can be fixed with the delete key at this early stage. The more users (or worse, customers!) you have the harder it gets to keep debt at a manageable level. Database migrations must now be planned carefully. Removing features becomes difficult or near impossible. 3rd party integrations break and will hijack your development schedule. Security updates and other maintenance work will slowly eat up a larger and larger percentage of your week. You can’t let these factors spiral out of control.
If at all possible, make the core of your app rock solid before you start charging people money. That way you can continue building on a solid foundation with little tech debt. If this means building a much smaller app, so be it. Smaller is better. You want few dependencies and few moving parts. Knowing exactly which corners to cut and which parts to rewrite until they’re just right is very, very hard. We still get it wrong all the time.
[1] Asserts abort a program when a condition isn’t met. The user gets a “server error” message and the programmer gets an automated email that a specific edge case has been hit. By adding many asserts throughout your code that check whether your data and inputs look correct you’ll save yourself days and weeks of debugging time.
With 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.
In this post I want to stress the importance of having an app that is really good. As good as you can possibly make it. Ideally your app blows the competition out of the water in a side-by-side comparison. This isn’t just about UI/UX design and features. It’s about whether your app solves a key problem much better than anybody else. Your prototypes and MVP won’t be that great, and that’s to be expected. You make those first versions to gauge potential. You have to work towards making a truly great app though, and in this post I’ll explain why I believe this is so important.
There are some businesses that do well without having great software, just by being great at marketing and sales. So why not just do that? You can hustle. You can buy ads, build a big following on social media, do cold outreach and email 10.000 people, write SEO pages, plug your app on youtube and do podcasts. That all works[1]. You can get many people to try your app with persistent marketing. Despite all that, if your app doesn’t provide enough value to people your startup will struggle and not really take off, no matter how hard you hustle. This is because the world is huge and the fast way to reach many people is by word-of-mouth. Your users have to be so thrilled about your app that they’ll tell their friends about it. Your app should have an R0 above 1, if you catch my drift :). That’s how you get explosive growth.
You can ignore what the market is telling you. You can just power through and hustle. Even with a mediocre app you’ll still find customers with persistence. You can even create a profitable business that does well year after year. This works best in markets where competition is weak and nobody has made a great product that users love. Those are markets just waiting to be disrupted. Just a matter of time until that happens.
For B2B startups having a great product is less important than for B2C. There are two reasons for this: 1) business software is more expensive which means you can just hire sales staff and 2) people don’t get as enthusiastic about business software which means your competitors are likely to struggle with word-of-mouth growth just like you. But even B2B markets get turned upside down by upstarts with wildly passionate users. Companies like Stripe and Zoom are unstoppable because of it. Business chat apps like HipChat and Campfire stood no chance against Slack. I don’t even remember the names of the businesses Zoom bulldozed. Webex meeting, maybe?
The necessity of making a great app applies to us as well. Every day we write code, design and redesign the UI. We try to figure out which features work and which ones just don’t. But we don’t know yet if our app will turn out good enough. Sometimes you swing and you miss. Occasionally you can pivot an app and turn it into something great, but that’s the exception to the rule. If reception to your app is lackluster it means your app is bad and you should go back to the drawing board. It could happen to us. Fingers crossed.
[1] To be clear, every business needs to do marketing. My point isn’t that marketing is unnecessary, but that it’s not wise to compensate for bad product/market fit by doubling down on marketing.
It seems binary thinking is not prevalent in just tech founders but when starting a business in general. Often people seem to think something needs to be done perfectly, or it isn’t possible. If that’s reason not to pursue your dream of building a product/business, that’s a shame because you can slowly work your way from 0 to 1.
All at once
At every stage in the business, you’ll deal with other issues and challenges. It’s okay to learn while doing and deal with them as they occur, otherwise it would become impossible to start. Thinking you have to do everything all at once means you can’t really start with anything.
In the beginning you don’t know yet whether anything you’re about to do will really matter. That’s when it’s best to worry about “bad problems”. That’s not a pleonasm, because there are “good problems” too. A bad problem would be not having any customers yet. Focus on that. A good problem is having so many customers that you can’t handle support anymore.
Spending time on fixing good problems you don’t have yet is a waste because it might never have been needed in the first place. Plus you won’t really understand yet what the best way to handle it is until later.
All in
Starting a business doesn’t mean you need to drop everything else. We started building our first software business when we were students. We did freelancing and work for university on the side. Admittedly it was a very busy time, and we promised ourselves to switch to full-time as soon as we financially could, but we managed to grow to our first product in this way and become ramen profitable.
Going all-in when it’s an option is great, but sometimes the timing isn’t right and starting up on the side is totally possible. See if you can get a first customer, then scale it up.
Doing less
Some things which need attention can also be fixed with a duct tape solution, and then revisit them later when it becomes really painful. For our first app we didn’t even have a password reset option. People had to email us and then we’d reset it for them, manually. We just didn’t have the time, and if we would end up with 0 customers it would have been a waste of time to invest in.
Technical founders also like to set up their perfect environment and tech stack. Kubernetes, CI/CD, Docker, Microservices, the list goes on and on. It’s all a waste of time if you don’t have a product with customers yet, and you just won’t need it. Duct-tape it together with whatever means necessary for now (that actually sounds worse than it is, I like to think of it as just going for a simple and elegant solution). Worst case it takes off and you get to improve it while being paid for it.
Copying the big league
Because big businesses are more visible, their approach sometimes seems like the only way to do anything. But just like when they were small, many of the challenges they have are not relevant to you.
Just because Netflix has servers all over the world doesn’t mean you can’t run your entire business from a single computer under your desk. Focus on getting some customers first. You don’t need to worry about a few minutes downtime yet (if you have any people noticing at all then that’s a Good Problem).
Just because Google is tracking the usage across their apps and A/B tests everything doesn’t mean you even have the numbers to make any of that relevant. Just get feedback on your product first.
As a founder you can (and have to, initially) do everything yourself. You are the sales department, the financial department, the technical department, the support department. Customers are not going to mind if you provide a good service. Besides, from which company you recently dealt with did you get a personal note from the CEO when you had a question. How amazing is that in terms of support?
Lots of founder also seem to worry about all kinds of legal paperwork being so complicated they don’t get started, and overestimate the problems they will get exposed to. You are not going to have the same responsibilities and issues as Amazon. Many exemptions apply to small businesses in the first place, but even the big players don’t have everything perfectly set up. Lots of things you can do yourself. For example, the entire GDPR framework is explained on a website which you can read in a day, problem solved. You don’t need expensive consultants for that. Same for accounting, just go with something simple or do it yourself for now.
How and where do you begin? If you’re justing getting started, the very beginning of the entrepreneurial journey seems the hardest. Those who have success have revenue numbers which seem out of reach, a follower count you can only dream of, and they seem to be everywhere.
The way I like to look at this is by acknowledging that Power Law is all around us. Probably 99/100 people reading this already heard it all before, but basically a power law describes a relationship between two quantities y and x such that y(x) = x ^ some power. When you plot a power law distribution it looks like this:
Another example of a power law relationship is the Pareto principle, or 80/20 rule, where 80% of the result is caused by 20% of cases. That’s the head of the graph. All the rest is in the long tail. You could put it even more bluntly and call it “winner takes all”.
It’s everywhere, in nature, life and business. From the distribution of crater sizes, the amount of food animals of a certain size need, the distribution of wealth across a society, pandemics.
Although you might want to call it the 99/1 rule instead. Inflation, a sign of the times.
So back to the beginning. What does this have to do with starting a business? Because so much in business follows this power law, looking at it in terms of power laws makes it simpler to understand why it seems difficult to start, and why success is in fact possible, and why certain routes are harder.
Audience, followers and marketing
For example, when looking at an existing large audience an established company has, it seems impossible to get there. You start out with 0 followers. Then finally you get your first follower or signup for your newsletter. Then finally another one, maybe 4 more. This will take forever! You’re at the end of the tail, and everything looks flat from here.
But. Power law! We see the same relationship in network effects, such as building communities, an audience or a following [1]. The value of a network goes up with the number of participants squared. So next time you send something to your followers, some in the network might notice it. Before you know it, people start sharing your content with some of their followers or friends. Slow at first, but the pace of new followers will pick up.
The important lesson here is to keep going. You shouldn’t look at the slow growth as it not working out, rather you are in the tail. This is the part where you shout in the void, and need to trust that it’s working. The network effect and power law are real. Similarly, you shouldn’t look at some other products following of 100K as unattainable, but rather see it as doubling only 16 times (of course it takes work, but that’s not impossible at all).
Content and thought leadership
The same applies to writing content and sharing ideas.
99% of all content is created by 1% of people
99% of the public debate is determined by 1% of the people (because they publish).
It looks like there is a lot of content out there, but related to the enormous size of the internet, there is almost none. That makes it way easier to have an impact on opinions, debates and establish yourself as a brand in a field you’re interested in.
99% of all traffic will come from 1% of your posts
only 1% of all total views for your content will occur at the beginning
Almost nobody reads any of your content at the beginning, and that’s normal and expected. It’s important to keep publishing because you need the numbers to get to that 1% post which will do well (and make the rest of the content work you did compound).
Launches, internet points and product-market fit
Just to name some well-known examples to many startup founders: 1% of launches on ProductHunt will get 99% of votes, only 1% posts of Hacker News will get any traction at all. When a submission to one of those sites gets traction, the long tail of upvotes will just be a handful. You need to get to the 20/80 inflection point of the graph where suddenly it takes off and starts collecting all the other votes.
Having a great post or product is completely necessary to do that, of course. But the difference between 1000 upvotes and 1 upvote is not 1000x. It’s a few votes at the beginning, after which you’ll get the 99% of other votes. Again, good to realize this and not get discouraged and take one launch of a feature or product which failed to get traction as evidence that the entire concept is flawed.
The same goes for product-market fit. It’s a lot of long tail small changes which can suddenly bring you to the 80/20 inflection point where things really take off. Once things grow really quickly, you haven’t put in 1000x times the work, but a few doublings in the tail (which are just small numbers) brought you to this moment. From there on, everything goes quickly (feedback, revenue, press, and so on).
Competition
You will only have heard of a few big players (1%) in the market. They seem to be everywhere, but in fact there’s an entire long tail of businesses which have customers! Depending on the market, that long tail can be very lucrative. If you want to build a nice lifestyle business, don’t overlook big markets because there are a few large players. Build in the niches of the long tail.
Looking to become a big player in the field yourself, but see a lot of players? Only 1% of those will become really big, so if you’re willing to go for it, there’s less competition than you think.
Customers, support, reviews and pricing
Let’s end with a few more:
1% of your customers will be your biggest fans and spread the word. That’s why your MVP needs to focus on getting those!
99% of support is going to come from 1% customers. Don’t be afraid to “fire” them if it becomes unreasonable.
Likewise, most revenue is going to come from a few customers and few price plans. Make sure your pricing plans follow the power law, and allow customers who see a lot of value to subscribe to a high pricing plan!
There will be features which are only used by 1% of customers. Likewise, the vast majority of customers will only use a few core features. The long tail of customers which those extra features bring in will be relevant over time, but no need to launch with those.
[1] Slightly related to the topic of audiences, I like this TED talk by Derek Sivers about starting a movement (https://www.youtube.com/watch?v=V74AxCqOTvg). I just watched it again, and without measuring the exact seconds, I’m pretty sure the number of people dancing along follows a power law.
The perfectionist needs to be told to ship faster. Because not shipping or having exhausted yourself by the time you launch is fatal. There is a critical difference between polish and wasteful perfectionism. Polished is an app that looks good and works well. Perfectionism is refusing to launch until every single bug is fixed, rewriting and refactoring backend and frontend code just to make it look nicer or cleaner. It’s wasteful work because large parts of your app and infrastructure will get rewritten anyway. Why seek perfection in something you’ll inevitably tear down?
The hustler needs to be told that making a really good product takes time so just sit down and do the work. Because you can’t grow a product startup if you don’t have a good product[1]. The engineer needs to accept that if nobody knows your product exists you won’t have any customers. If nobody knows what you’re building you won’t get any feedback. Having to face zero signups after spending a year on your beta is so demoralizing you’ll likely give up.
The spendthrift needs to stop squandering money. It’s the runway[2] you spend. Everything takes longer than you think and many startups fail simply because they run out of money. The miser should try to be less cheap. Sometimes you have to spend money to push your startup forward[3].
These are just some examples, but I think you get the idea.
In order to survive you want to embrace conventional and boring choices in some areas, because conventional choices aren’t terminal mistakes by definition. That leaves you with unconventional bold choices in those areas where you want your startup to stand out. Founders tend to be unconventional people, but it’s hard to be only moderately and selectively contrarian. That’s a problem because being contrarian and wrong can easily kill your startup.
People who are at one extreme need to shoot for the other extreme in order adjust their behavior enough and end up somewhere in the middle. 10% adjustments don’t cut it when your initial position is completely wrong. Your position is wrong because you are predisposed to believe facts that reaffirm your beliefs. To counteract your blind spots try to overshoot your goal and you’ll end up closer to the middle, where you want to be. This is counter-intuitive!
When you already have a reasonable middle position on any of these issues the advice you read and act on doesn’t affect you much. After all, it’s the big mistakes in startups that kill you. If you can survive until you reach product/market fit (= awesome product and accelerating growth) you’ll be fine even if you get all the small stuff wrong. You just need to avoid the terminal mistakes. Tautological, I know, but still easy to forget.
That’s the paradox of course correction[4]: when you at the one extreme aim for the opposite extreme to end up in a moderate position. If you’re an engineer with an inclination to do zero marketing, try to overdo your marketing and maybe you’ll do barely enough.
[1] You can build a different kind of business, e.g. where you provide some kind of B2B service manually that you’ll automate later, after establishing a market need.
[2] Your runway is the time you have before you run out of money. The sooner you can cover your living expenses the better.
[3] We’re pretty bad at this, admittedly, and have a tendency to reinvent the wheel..
[4] If this is a known concept I don’t what it’s called.
One of the most important decisions you have to make early on is whether your product is going to be for businesses or for the general public. There are significant advantages and disadvantages to both markets, and in this post I’ll touch on the major differences. You can easily see that the B2C column has more check marks, but that’s deceptive!
Advantages of consumer apps
With a consumer app you can get to market more quickly because you need less functionality. A consumer app that just does one or two things well can be a hit. Business users demand all sorts of long tail features. Think of single sign-on, permissions, audit features, integrations with other products. These are not features that make your product stand out in the market, these are just features you have to build to get and keep customers. This clearly favors the B2C app.
Consumer apps also sell easily. When you sell to other businesses it can take forever. Accounts payable. Requests for quote. Oh wait, you first need approval from the boss. Phone support. Product demos. Sales is a process and it’s real work.
If you make a cool consumer app everybody wants to try it. Consumer apps become viral hits in a way CRM software never does. Making software that is used by millions of people around the globe is a dream of many software developers, myself included. Happy customers tell their friends. That means that you can have explosive growth manifest from nothing. If you sell business software growth means hiring sales staff.
Consumer apps that look and work better tend to win. That means if you enjoy creating software that works really well you get rewarded for that in the consumer space. Business customers don’t care that much. Either your product saves or makes them money but they won’t care much beyond that. Tragic, but true.
Customer support for consumer apps is also a lot simpler. You can have some kind of self-service forum and some FAQ pages. You can automate almost everything for consumer apps.
That’s a long list of things that favor consumer apps. So what do B2B apps have going for them?
Advantages of business apps
Business software has two major advantages, and those two make up for all the downsides. You can easily charge money for B2B software. This difference is enormous. Businesses have effectively unlimited budgets if you can demonstrate your software is worth it. One B2B sale can bring in the same revenue as 100 or 1000 consumer sales. Would you rather provide customer support for one customer or for 1000? Easy choice.
In addition, your business customers will keep using your software for 5 or 10 years. More if your product is really sticky. When you sell consumer software you are constantly fighting against churn and new developments in the market. For B2B software boring is good. I put the UI/UX checkbox in the B2C column because B2C software is more meritocratic, and that’s good if you want to break into a new market. However, once you’re an established business this benefit turns into a disadvantage for you and an advantage for new up-and-comers.
The reality is that business software is where the real money is. Consumer software is all chasing after the same consumer dollars. It’s hard to compete with the free or nearly free offerings provided by the megacompanies we all know. In addition you’re going to compete with venture backed startups that will happily give away their products for free to get a dominant position in the market. Despite those challenges your consumer app needs to find a massive audience, think millions of users. That requires a small miracle.
The bottom line is that when you write B2B software you enter a far more forgiving market where there are plenty of customers eager to pay real money. If you decide to write consumer software regardless, you better have a few aces up your sleeve.
Let’s say your startup website gets some traffic. Maybe through social media, ads, a podcast, or from an article you’ve written. Some of those visitors won’t understand your product or just aren’t interested. A percentage will sign up for the free trial. Of those people some mean to “look at it tomorrow” but forget, others open the trial but get confused and quit. Some will actually try your product for real, those are your users. And of those people some like the product enough that they want to buy it. Yay.
The percentages used here are pretty arbitrary. If you have an SEO article that directs people with a specific problem to your website you get high quality traffic that will flow through your funnel nicely. On the other hand, if your product is covered in some (online) magazine your traffic will consist of people who are curious but who are not actually prospective customers. Trial signups from that audience are just noise.
At some point you want to optimize your funnel and figure out where you’re losing people. When you’re just starting out your splash page[1] won’t have much traffic (not enough for A/B testing) and you won’t have the time to get everything perfect. Your funnel will leak, but that’s fine. Your initial goal is to figure out if your product is good. You can always fix the website later.
Ultimately your app will only sell well if it’s really good. Ideally, your app is also original and stands out from the rest. A great app will get you passionate users that will spread the good word to their friends, after all. This is especially true if you’re making an app for a horizontal[2] market. Originality is not without downside: different is scary and alienates people. If your app is unique in a good way it might become a big hit. If your app is unique in a bad way you won’t make it. Back to the drawing board.
If your app is too conventional it’s hard to stand out. If you have excellent marketing you can do well, but you risk becoming a zombie startup[3], where everything seems promising enough that you don’t want to give up yet, but you’re not getting the kind of traction and growth you really want.
Let’s compare this with an “innovative” splash page. Maybe you’ve done something whacky where people have to solve a puzzle in order to read what your product does. Original? For sure. But good luck getting anybody through that funnel. Look at the risk/reward here, assuming you have an app that is original and good (good idea + good execution):
A great splash page can’t save a bad app, but a bad splash page can destroy your chances of success even when your app is good. This brings us to the title of today’s post: wanton (unprovoked/unrestrained) originality.
Limited upside + unlimited downside → conventional choices are good.
This is why the websites of so many startups look the same. Your website only needs to explain what your product does and what it costs. If you do more you’ll risk punishment for wanton originality. Yes, ideally you want a high percentage of people who visit your website to try your app, but a reasonable website will do a pretty good job at that. It’s way easier to 10x your website traffic (top of the funnel) than to 10x the conversion rate of people who visit your site. Traffic matters. A good app matters. A great website is just nice to have.
Don’t get me wrong. If you can make your startup website look great by all means go for it. Just bear in mind that you can’t save a bad product with a good website[4], but you can ruin your chances with an incomprehensible website even when your product is excellent. You can have a conventional billing process. Conventional, but excellent, customer support. You don’t need to reinvent the wheel here.
Be original where it matters and don’t be different for the sake of being different.
[1] Splash page. The website for your app that shows people what your app does to encourage visitors to sign up for a free trial.
[2] Horizontal apps are for a broad group of people and businesses. Think spreadsheet software or website builders. Vertical apps are for a specific niche or industry. Think software specifically made for tennis fans or architecture firms.
[3] Zombie startup. Not quite dead but also not really thriving.
[4] Enterprise software businesses excepted. If the people who make the purchase decision won’t be the ones actually using your product (“solution”) then everything changes. Enterprise software businesses are all about the sales process. It’s a totally different world.
@jdvhouten
