#business-general

High conviction, low conviction

Diederik • @jdvhouten • • Part of Day 50

We’re making a todo/planning IDE. Think Visual Studio Code for tasks and projects. For our startup to work we have to get three pillars more or less right: product, business model, and marketing. Marketing because you don’t get anywhere when nobody knows your product exists. The business model is the part where we figure out how to make money. Most importantly we have to make a product people love.

Product

We want to make Thymer text based. The design trend over the last decade has been towards shiny interfaces with lots of whitespace and poor usability. Software has gotten easier to use but also dumbed down a great deal. We want to go in a different direction. We want higher information density, a text based interface, extensibility, and we don’t want simplicity at the expense of powerusers. On these things we are high conviction.

We have a clear vision of what we want to build. If we deviate from this vision based on early feedback we’ll end up with a product that lacks cohesion and that nobody will get excited about. We can pivot somewhat, but we can’t change what our app is fundamentally about. If it turns out that people just don’t want this kind of software (or don’t want to pay for it) we’ll throw in the towel and build something else.

Marketing

These are some of the marketing channels we can use to get the word out:

  • Social media (reddit, hacker news, linkedin, discord, other communities)
  • Google ads, Twitter Ads
  • Youtube channel
  • SEO marketing pages to boost organic search engine traffic
  • Twitter
  • Magazines
  • Blogging
  • Guest spots at podcasts
  • Guest blog posts
  • Bulk deals (e.g. Appsumo)
  • Integration with 3rd party products or protocols
  • Viral features/word of mouth

We won’t know which marketing channels will work for us. Presumably one or two marketing channels will end up producing the bulk of the traffic. We’ve just got to try everything and we’ll discover what works in the process.

When it comes to marketing and distribution we’re low conviction. We’ll have to figure it out as we go. As long as we get traffic and trial signups I’m happy.

Business model

On principle we’re only willing to try a couple of business models:

  • Freemium (mostly free users; small percentage upgrades to paid)
  • Freemium + B2B SaaS (also have subscriptions for businesses)
  • One time fee for lifetime access
  • Pay for usage or flat fee?

We don’t want ads in our product, but any combination of free+paid we can try. We can make some educated guesses on what works, but ultimately consumers aren’t rational agents. How much users are willing to pay, if anything at all, depends on emotional factors that are hard to forecast. Can we charge based on the value we provide? Will customers price anchor based on competitors? Will customers feel strongly that software should never cost more than $X? We don’t know. Needless to say, with regard to pricing, we’re low conviction.

If we can’t drive enough traffic to our website to get trial signups in volume, then maybe we’ll pivot and introduce features that appeal to businesses. As we wrote about earlier, a business subscription is easily worth 30x a single user subscription. A B2B SaaS product can thrive on a trickle of traffic.

Marketing is the real bottleneck and biggest unknown. Given enough traffic and enough trial users I’m confident we’ll be able to fix all major issues in our product and the business side will take care of itself.

Most deals fail

Wim • @wcools • • Part of Day 49

One of the hardest parts of running a startup, next to doing the actual work, is knowing what to work on. There’s a seemingly endless list of things screaming “highest priority level”. One category in particular can be very distracting and time-consuming: deals and partnerships.

Especially when starting a business for the first time, all these deals can easily be mistaken for validation and important work, where in fact most of it is playing shop. The extra difficulty comes from the fact that you need just the right amount: you need to stay the course, but sometimes it helps to tack to beat against the wind.

The danger in saying yes to everything is that you just end up wantrepreneuring away your time. Most time should be spent on building your product, and talking to actual users. It’s very easy to spend all day jumping on calls with other startup folks, join in competitions, going to conferences, hang out with business networking groups, and not end up with a better product or a single customer. Trickier still are offers which actually look like they’re helpful. Especially when you just launch, you might see your inbox fill up with those very quickly, from amazing ad campaign offers to requests for collaborations.

One of those typical offers is a potential customer (or even an actual existing customer!) reaching out with an idea to get extra business. Wow, you just launched, and not only do you have a very passionate customer, but they’re willing to think along, have ideas of their own and spread the word for you!

What makes this difficult is that the common advice is to listen to your customers and use feedback to improve your product. But in my experience, anything more than getting feedback to learn more about the problem space, so you can then improve your product based on your own ideas, is a huge distraction. Proposals for deals or partnerships are cheap, and it will most likely be a lot of talk with very little result. Quite often you will end up becoming more of a freelancer building a solution which is only great for one customer. Stay the course and stick to your original mission.

We made this mistake too at the beginning. A customer reached out and thought our horizontal product would do especially well in their vertical. Perhaps we could white label it? They had a huge network in their market and were convinced they would be able to sell this easily to many of their customers and businesses in their network. Especially being technical founders, and only just having our first customers or two, only having to write a bit of whitelabel code and having someone do the sales to bring in even more, that’s amazing right? They just needed a few features which would be really critical for this market.

You can see where this is going. Only they ended up using the whitelabeling and extra features, for their own business. They never managed to refer anyone else or reach any other businesses. And of course why would they? Running your business is your job, not theirs. They aren’t as invested, it’s just a random idea for them. We all have random ideas, the execution is the hard part. Only as an owner of the business are you willing to do the actual hard work of building and selling, no customer is going to actually want to work as hard on that as you are.

Related offers to do affiliate marketing or marketing outreach for you will usually have the same result. Most of the time this just ends up being a way for a customer to ask for a discount or free plan in return for maybe telling others about your product. A better deal is to just not waste time on this and see if they want to pay so you have an actual customer.

Another very good example are emails from private equity firms or invitations to “chat” about investments or even potential acquisitions. If there’s a mother lode of distractions so large they can cost you your business, then this is it. But there’s so much to say about this (plenty of anecdotes there ;), that’s probably better for another post sometime.

The point is to remember with all these deals is that most of them will fail. They seem like a shortcut but they’re just be a distraction. What really moves the needle in the end is just improving your product and going to where your customers are to talk about it. The only caveat here is that sometimes saying yes increases your luck surface. Many good things in life can happen because of random connections, and business is no exception. As a rule of thumb that’s why I usually only say yes when the distraction is not too big and it’s either fun or to help someone and pay things forward. But time is limited so choose very wisely and say no most of the time to stay the course.

Your app needs a USP

Diederik • @jdvhouten • • Part of Day 44

Your app need a good answer to the question: “Why not go with the established competitor’s product?”. That’s what your Unique Selling Proposition (USP) is for. This is especially important when you start out, because a new product has fewer features than the competition. You also don’t have brand recognition. People buy Apple products just because they’re made by Apple. A startup doesn’t have that advantage.

Your product is also likely to have some serious shortcomings. It takes years for software to get good, so you need something to compensate for your lack of features, lack of brand, and other ways in which your product isn’t great.

You can try to compete on price. Just charge less than everybody else, right? Except, this can backfire on you in two ways. One, you send a signal that your product belongs in the “budget” section and is therefore worse than other products. And two, the cheapest products get the most difficult-to-please and most demanding customers. I’m not entirely sure why this is, but my hunch is that people who look for the cheapest products have a negative disposition. Maybe they’re afraid they’re getting taken advantage of, or maybe they resent having to pay for software in the first place. When you charge more you get customers that look at the value provided by your software and decide based on that to go ahead with a purchase. For the first kind of customer any price is too high. The second kind of customer will be happy if you explain in plain language what your product costs and what they get in exchange. You don’t want to be the most expensive product in your market and you don’t want to be the cheapest. Just be somewhere in the middle. Maybe somewhere the lower 3rd, that way you can easily raise your prices as your product gets better without pricing yourself out of the market.

Can you distinguish yourself with some really cool feature? Probably not. It might work in the beginning, but once you get some success your competitors will notice. Established businesses have more resources and most features can be copied. Usually competitors will make a feature that’s equivalent and not exactly identical, but it amounts to the same thing. The one feature that made your product unique has been commoditized and you go back to square one.

You also can’t distinguish yourself based on “universal benefits”. You can say your product is “fast”, or “easy to use” but every competitor will say the same. You can say your product is “secure”, but even competitors with the worst security practices (and the record to prove it!) can put any number of logos on their website that prove their product meets every industry standard. Ever noticed how companies with terrible customer support have these Customer Service awards plaques on their website? You should absolutely work your hardest to provide great service, but to really distinguish yourself you need more.

So you can’t compete by having more features, you can’t compete on price, you can’t compete with cool unique features. If none of these approaches are good, what can you do?

To differentiate yourself in a way that lasts your product needs to be something the competitors explicitly are not. Good products drive a wedge in a market where customers have to choose whether they want a product of Type A or Type B, but they can’t choose both. If you segment the market intelligently you’re the first and therefore best product in this new subcategory. This puts you as a new startup in a terrific position.

If you’re going to compete with Gmail you don’t want to be the product that’s cheaper (Gmail is already free) or the product that’s faster (Gmail used to be fast, too) or the product that has the most features. You want to be the product that is about privacy. No ads. You fight newsletter spam and email open tracking and other bad practices. What is Gmail going to do? Nothing! Gmail is an ad-based product, after all.

With Thymer we’re boldly choosing a text-based UI. Many people, like us, use text-based IDEs all day. It’s the kind of software interface we like, so odds are, other people will like it too. It’s not a feature our competitors can just copy, because it defines what our app is. If we succeed I’m sure people will try to copy us outright. That’s inevitable. If our app is good enough clones won’t hurt us much.

There is a final reason why it’s important to have a clear USP for your app. You want to be the best product for this new segment you’ve created. Any time you think about adding a new feature or adding some text to your product page you can ask yourself if it fits with your core theme. This helps you focus on what matters. You don’t want to dilute your vision, you want to make it stronger. It will put off many people, but those who like it will end up really liking your product. When you start out, that’s exactly what you want.

Reduce

Wim • @wcools • • Part of Day 43

The number one priority right now is to get the first version of our product out as soon as possible.

One advantage of time or budget constraints is that it forces you to really think about what the focus should be of your product. Spending a bit of extra time at the beginning to think about how you can simplify the product and reduce the scope saves a lot of time in the long run. The “If I had more time, I would have written a shorter letter” quote is applicable to code, UI, product and marketing as well.

The most obvious way to ship faster is to build less.

Every line of code we’re adding to the product is code we might not have needed in the first place. Maybe certain ideas won’t work out and we need to scrap them later. Or maybe nobody cares about the product in the first place. If the product does take off, we need to maintain all of it. It’s much harder to remove features than it is to add them, in terms of keeping users happy.

This is not the time for premature optimization in our code or being architecture astronauts: we need to ship. That said, spending a bit of time sketching out what screens should roughly look like helps us identity places for re-use.

For example, one of the main components for Thymer will be the editor. On top of that, we also want people to be able to schedule their tasks. If we would dive right in without thinking these features through, we might end up building two completely separate controls for them. Looking at it more closely, they can actually be the same component. We simply might have to make some parts read-only, and date headings will be like headings in a doc, but dynamically generated. And instead of spending a lot of time on a preferences panel, we might just reuse the editor again to show a configuration file or sorts.

Simple products are better products.

Reducing the number of “concepts” doesn’t just reduce the number of components to build. It also makes it much easier for users to understand the product. When there are only one or two core concepts, it’s easy to get a good “mental model” of what the app is and how it works.

For example, many text editors in the past had several modes. Different options were available in different modes, like a view mode and an edit mode. Not only would you need to build both as a developer, but users had to understand the two concepts and deal with working with both. Larry Tesler worked on the idea that interfaces should be modeless (and famously drove around with a “NOMODES” license plate).

Both a good and a bad example of reducing UI concepts is Windows. The Start Menu, introduced with Windows 95, is absolutely brilliant in that sense. Even the most technophobic users only had to learn one concept: whenever you want to do something or you get lost, just click “Start”. Simple to build, simple to pitch, simple to understand.

Windows 8, by huge contrast was a complete mess. There’s a bunch of different start menus, with completely different styles. You had to learn all those concepts and they had to explain why it was better. Same for Settings vs Control panel (and there’s probably more). It takes more time to build, and just confuses the user.

The Home screen and Home button on iPhone is similar to the simple concept of the start menu. I notice how explaining how an Android phone works to a family member without too much tech experience is much more difficult than explaining how to navigate an iPhone. With iPhone you just explain they click one button at any time to get back. Onboarding is way faster with products introducing fewer concepts.

Simplifying the USP and marketing

As a bootstrapped startup, you won’t have the resources to be everything to everyone and outbuild your competitors. You also shouldn’t, because it’s easier to pitch a smaller product to a specific niche than selling large integrated solutions to everyone. You need to build more, need to explain more, need to onboard more, and need more buy-in from more decision makers.

Focusing on just a few core concepts is also important when thinking about your USP and describing why your app is better. Competing against another product which does “A, B and C” by building “A, B, C and D” is typically a bad idea, especially when bootstrapped. So rather than a mix of features and concepts, narrow things down to one simple concept you can describe in a sentence. A lot of marketing is about repeating yourself, and if there are dozens of concepts you need to explain, it waters downs the message about what makes your product worth trying.

Basic strategies for validating startup ideas

Diederik • @jdvhouten • • Part of Day 42

You know you want to start a startup, but you don’t know what to build. Maybe you have notebooks chock full of ideas but you don’t know which ones are good. Maybe you don’t have any ideas, because it feels like everything exists already.

You’ve googled for tips but discovered that most articles on the internet about validating startup ideas are aimed at startups that seek Venture Capital. Startups with Venture Capital can throw money at problems. They can buy growth, features, and positive press. When you’re a bootstrapped startup you won’t be able to outspend the competition which means you need to be scrappy and strategic. It’s a different game.

Bootstrapping refers to the (physically impossible) trick of pulling yourself up by your bootstraps (etymology). As a startup metaphor it means building a startup without any resources. It’s possible to start a web business from nothing because your only expenses are web hosting, a domain name, and a laptop. You need technical and business skills, but you can learn for free. There are no real barriers to entry. That’s great for society but it also means you’ll have a good deal of competition no matter what you decide you build. Bootstrapping is possible, but it’s not that easy!

We haven’t written much about idea validation so far because it’s so subjective. What do you want to get from the business? Do you primarily want to make your customers happy? Do you want to solve interesting technical challenges? Do you just want to make money? Do you want change the world for the better? Do you want the freedom of working for yourself? Do you just want the excitement? The satisfaction of forging your own path? Everybody has their own priorities and the only thing that matters is that you know what yours are.

Also, everybody has a different skills, abilities, and resources. Do you have a lot of time to get your business of the ground or do you need to launch ASAP? Can you self-fund to a degree, or are you broke? There is a large personal component to this. What may be a good idea for you might be an awful startup idea for me.

I say all this because I want to stress how subjective this all is. There are very few right and wrong answers and we certainly can’t tell you what to build.

That said, I’m not a total relativist. Some startup ideas are brilliant and original and I feel foolish for not having thought of them myself. Other startup ideas are objectively terrible and founders would spare themselves a lot of grief if they thought their business through before they invested a lot of time and money into it.

Essentially, you want to figure out if your startup idea has legs before you commit a ton of time to it. That’s all validation is.

You have two things to validate:
(1) if people want to use your product, and
(2) if it makes sense as a business.

PRODUCT VALIDATION

  • What makes your product unique (USP)?
    • Why should people buy your product and not somebody else’s?
    • You can’t just copy a product and add 1 cool feature.
    • Do users care about your USP?
  • Can you build a prototype in a reasonable amount of time?
    • Can you get away with building just a few core features?
    • The longer it takes to build your first prototype the more confident you need to be that your idea is good.
  • Is the product scope reasonable?
    • You can’t win by simply building more features. That’s a game for VC backed startups.
    • Small products are better suited for bootstrapping.
  • Do you have the necessary technical skills?
    • Do you know where the technical execution risks are?

BUSINESS VALIDATION

  • Can you find enough users?
    • Do these people exist?
    • Do you know how to reach them?
  • Will users buy your product?
    • Do you have free competitors?
    • Is the market very crowded?
    • Do you have successful bootstrapped competitors? If not, why not?
    • Can you explain to users how your product is better?
    • Can the competition easily copy your product?
  • Can you charge enough money?
    • Figure out how many customers you need for your revenue goal
    • What kind of churn can you expect? This twitter thread has some good data.
    • Do you need to compete on price or can you charge a premium?
  • Can you grow by self-funding?
    • Can you automate your sales/onboarding/growth process?
  • Does this business suit your personal strengths?
    • You want to put your strongest skills to good use
    • Will you stay passionate about it in the long run?
  • Any legal liabilities/risks?

Yep, this stuff is prosaic. You need a product and you need customers. Not exactly rocket science, right? And yet, making an effort to think your idea through is vital. The questions are basic but the implications of the questions are subtle and can easily trip you up.

You can figure out roughly how much you can charge for you product by looking up what your competitors charge. When you start out you want to be in the lower end of that range. You don’t want to to be the cheapest product because the cheapest products attract the most price sensitive and difficult to please customers.

Some people will tell you that you can validate a business by slapping a marketing page together and asking some people if they would pay for the product if you build it. It’s just a matter of cold emailing some people (or LinkedIn/Twitter message) and you’ve got your answers. I don’t think it’s that easy. If people are enthusiastic when you describe your startup to them that’s a good sign, but it doesn’t prove much. If you make something for an established market then you already know customers exist provided you make a good product. And if you make something really original you can’t explain what it is — you have to show people. But you have to build it first (or a prototype at least) in order to do that.

You won’t know for sure if people will actually pay for your app unless you put up a credit card form. Words are cheap, after all. But before you get to this point you have to build the product and find users. No real shortcuts here, either. If you’re good at sales maybe you can convince people to give you money for a product that doesn’t exist yet, but that’s not my style.

You can work out how long the first prototype will take by starting with the hard parts. If you can outclass your competitors by solving a hard or hairy (or schleppy) problem that will give you a big edge. You don’t want to spend weeks or months building scaffolding only to discover you don’t know how to make the thing that would make your product great.

You can figure out if your USP makes sense by working on your hero message. The hero message is the big text at the top of your product website that explains what your product does. Try to capture what makes your product unique. For the thymer.com splash page we explain how we’re different: it’s an editor, and we explain in two sentences what it does (tasks and planning) and what the target audience is (makers/creatives). We collect email addresses at the bottom. If we have a few hundred people waiting to try Thymer by the time we got a first version going then we’ll be able to get a ton of valuable feedback that will help us figure out if we’re on the right track.

The bottom line is, the more answers you get to the questions above the more you “de-risk” your startup. Some answers you can get by googling. Other answers you get by talking to prospective users/customers. At some point, though, if you’ve thought hard about your idea and if you haven’t found any critical flaws, just go ahead and commit. Take the time to build a solid prototype and discover if the app works as well in reality as it did in your head.

Assert all the things

Wim • @wcools • • Part of Day 41

In programming, we use assertions all the time to make sure our assumptions about what the code should do are (still) valid. Whenever the resulting state is not what we expect it to be, the program stops and we receive some sort of error notification.

We’ve set up our systems to email us about it, so in the below example we would get an email if some_function no longer works as we expect it to:

offset = some_function()
assert offset % 4096 == 0, "The resulting value should be a multiple of 4096"

We use this concept of assertions everywhere in our business. Some of those are in code, but many others run as periodic scripts (cronscripts). They’re small bots if you will, constantly checking if all kinds of “business state” is still what we expect it to be. Those checks can be about all kinds of things: from accounting, to hardware, to invoices and security.

Rather than having to manually check if everything works as expected, we have our systems tell us when something is wrong. Push vs pull. It’s like the concept of a dark cockpit in modern planes. Rather than staring at dozens of lights and graphs and make sure they have the right color and right value, we keep working without distractions and get notified when a potential problem arises.

The checks don’t do anything other than informing us through an (email) notification. We don’t add “smart” logic to automatically try and correct the problem. The entire point of these checks is that the state doesn’t match our expectations, so those events will be rare and require investigation. At best it’s premature optimization to worry about a solution before, and worst case automatically correcting it based on assumptions which no longer hold cause even more problems.

Over the years we’ve added plenty of these checks in our existing systems, and we will definitely use them again this time. They’ve saved us a lot of headaches by catching issues early on, and quite often the fix was trivial. Some examples:

A loose network cable

We run several scripts on the server where we expect the output to be empty. For example, we run a command like the one below to check the status of the network.

$ ethtool eth0 | egrep 'Speed|Duplex' | egrep -v '(10000Mb/s|Full)'

When the output is empty everything is as it should be. When there’s output, we get an email about it. At one point we got the following email message:

Speed: 1000Mb/s

Because we found out right away it was easy to trace the problem down to a bad cable which was causing network errors in our data center.

Server configuration

Just like the example above, we have many more of these little bots checking all kinds of configuration. Sometimes we hash the entire output to make it easy to check if the output still matches. For example, this command checks if all services are running with the exact status we expect them to have:

$ systemctl -a | md5sum | grep -v 36adc2b4e6a5798c9a8348cfbfcd00e0

When there’s output, something’s off. We do the same for all kinds of other configuration (maximum number of open files, kernel modules, IPv6 support, firewall rules etc). This has especially saved us time when updating packages or the OS itself. Even when you read the changelog, some subtle changes in defaults or configuration file locations might break your assumptions.

We also have scripts checking configuration files against typos or security issues (such as constantly checking our web server config for common misconfigurations). If we would ever edit the config and make a mistake, we’ll get an email a minute later.

Stripe webhooks

Many APIs have a tendency to change over time. Of course you try to keep everything updated, but there’s no guarantee you’ll catch all unexpected behavior or that you have time to look into every new change.

We use Stripe to process our credit card charges. Obviously it’s important this works correctly. To make sure we’re not missing any important billing state or changes we didn’t even know existed, we automatically send ourselves an error message whenever we receive a webhook we didn’t know about at the time we wrote the code.

Manual invoices

Although we process most invoices automatically using Stripe, many larger B2B accounts often pay using wire transfers. Automating every last bit isn’t always the right trade off, but we’re also not going to have staff to waste time on making sure invoices get paid. So we have a simple bot which notifies us every week if an unpaid invoice has a due date in the past. It keeps emailing us every week so we can’t forget.

Accounting

In 2020, some EU countries temporarily lowered their VAT rates for a few months because of the pandemic. Who knew? We certainly didn’t. Luckily, we didn’t have to, because our VAT-rates-bot told us on the 1st of the month that something was off.

All our other accounting is code, too. We can calculate down to the cent that the balance of our accounts should be equal to the sum of the opening balance and all transactions and invoices we’ve recorded since. The strangest error we’ve discovered this way is that someone on the other side of the world accidentally paid their speeding ticket to our account instead of the traffic authorities. You can’t make this stuff up, but luckily our bots told us about it.

Feature limits

Sometimes you introduce a feature where you have to make assumtions on how it’s going to be used. For example, we allow users to create workspaces when they work in multiple teams. For the first version, the UI won’t be very advanced. Will it work well with 5 teams? Sure. Will it work with 100 teams? Maybe not. But why worry about something that might never happen. We put in a “soft assert” (which warns us but lets the user continue), and investigate what to do about it when we start seeing people go over limits.

~~~

And of course the list goes on. Sometimes new problems come up, or we read about issues which might be relevant for us too, and we add a little check. Set and forget. Assert all the things.

Randomness is a perspective

Diederik • @jdvhouten • • Part of Day 40

For many founders the whole process of building a product and bringing it to market is stressful and anxiety-inducing. Founders want confirmation that they’re on the right track. But is this a reasonable thing to want? And does it matter?

Startups are an unusual environment where you’ll succeed if you focus on the things that truly matter at the expense of everything else. Not many things in life are like that. In college, for instance, you can “cheat” by picking easy courses or by studying for the test instead of for comprehension. College is artificial and all the metrics can easily be gamed.

It’s not just college that’s artificial. Consider these occupations that never leave the make-believe world:

  • Tax advisors game metrics for a living. Government makes the tax laws and the tax industry figures out ways to skirt them. It’s an endless game of cat-and-mouse that provides no particular value to society. It’s basically a boring competitive video game where you get points according to some byzantine rule system and also the points are money.
  • Many, but not all, charities fall into this artificial category. They raise funds for causes that deserve our attention, but then what happens? Being good at fundraising and being good at making the world better are two entirely different skillsets. It shouldn’t surprise anybody that when charities optimize for their ability to tug on our heartstrings they get good at that, and only that. Charities don’t need to be good at improving outcomes in order to be considered successful, they just need to look like charities and play the part.
  • An employee in IT that works hard to keep everything running smoothly might get no credit because all the value provided is invisible. Another employee that works weekends to put out fires of his own creation gets lauded for his work ethic. You’d think that businesses, because they want to make money, actually get really good at making something people want to pay for. But you’d be wrong because a businesses isn’t a person and it doesn’t have a singular will. It’s an organization first and foremost, made up from individuals who have personal goals often at odds with the goals of the business. An established business can survive on momentum for decades, churning out low quality products with poor customer service.

Disconnects like these are the default everywhere, not the exception. I’m not making a point here about misaligned incentives. The point is that these artificial environments provide simple benchmarks for success for the people in them. At work and at school your boss/teacher will tell you what to do and whether you’re doing a good job. You might still be working on pointless projects (see Graeber’s bullshit jobs), but it doesn’t really matter, because you don’t get judged on efficacy.

From this perspective it makes total sense that people feel scared and anxious when they start a startup. They need to transition from an artificial environment to one where they have to sink or swim. The complete freedom and apparent randomness of startup life feels scary and unstructured. Nobody tells you what to do or if you’re doing a good job, and the outside feedback you get feels totally random.

Some weeks you’ll get many thank you messages. Other weeks people say mean things about you or your startup on twitter. You’ll never know what triggered the positive and negative reactions, but you can easily lose your mind trying to figure it out. We assume these fluctuations are just noise, unless we see clear contrary evidence. You want to focus on the things that matter at the expense of everything else, which means you can’t let outside forces hijack your day.

If you work every day to make your app better and if you work every day to get the word out there, what do you have to be anxious about? Traffic goes up, traffic goes down. Customers come, customers go. Competitors come and competitors go. Much of this is completely beyond your control. The process is what matters and the process is extremely simple:

Work on the product in chunks until you believe it’s good. First make the most basic solution that works. Then refine it until it’s good enough to ship. Start with the hard parts and work your way back to the easy stuff (registration, login, documentation, etc.). Work on marketing with an “all of the above strategy”. Finetuning is for later, after you have established your startup is viable.

What is under your control is the work you do, and there is nothing random about it. Luck still plays a major factor of course. You can’t know in advance how many people want the thing you’re making. Sometimes you swing and you miss. And if we keep swinging we’ll hit a homerun sooner or later. But hopefully sooner :).

PS: It’s day 40. We’re half way through! And we have 20% of an app! Oh boy.

Viral Loops

Wim • @wcools • • Part of Day 39

Getting new users for any new product is no easy task. There are endless channels to try: paid ads, search engine optimization and content marketing, integrations with other products, cold outreach, social media posts… the list goes on.

Of all those options, the holy grail is word-of-mouth marketing. When running a business, it’s hard to imagine something better than your customers recommending your product to others. You don’t need any pushy sales tactics (not everyone likes those!), users will trust recommendations from other people over your marketing material, and it scales really well!

Simply deciding “word of mouth” is going to be your strategy is a variation of build it and they will come, and is unlikely to work. Unfortunately there is no way of guaranteeing in advance whether people want to tell others about your service. But that doesn’t mean we shouldn’t try to increase the chances of that, especially if it’s relatively easy to do so we don’t need to give up other (marketing) work for it.

The low-hanging fruit when it comes to improving the chances someone will find your product by existing users sharing it, is to think about viral loops in the product. They’re called viral loops because using the product will cause users to share the product with others, which will then drive new users, and so on.

One example you’ll often see is a “Powered by X” link when you’re interacting with a widget on some website. Another classic example is the “Sent from my iPhone” signature under many of the emails you receive. Or even more basic, the email address itself. Back when nobody had heard of GMail, and you received an email from that domain, existing users were spreading the word for them.

And speaking of GMail, another simple tactic is to try to make the service invite-only at the beginning. The “artificial scarcity” of the invites makes it more interesting for people to share them and ask around who wants any, and makes it more interesting for others to ask around for them. As most of this happens online, it will bring in more users who see this, and get codes to share in turn. At the same time it allows you to slowly ramp up the launch, so you can process all the feedback and fix any initial glitches.

As Diederik wrote yesterday, it’s hard to get significant revenue from very small consumer accounts, and it might make more sense to keep it cheap or free for these users. One advantage of being able to have a free offering is that it might be possible to ask some social media exposure in return. For example, we could experiment with something like mentioning us in a tweet to get free access. Large B2B accounts aren’t going to do this, but word-of-mouth to find those in the first place is helpful too.

A specific features might also lend itself to create some sort of viral loop. To stay with the example of a tweet: for a previous product we tried a feature where you could interact with the app over Twitter. People saw those tweets scroll by in their timelines which drove more traffic to the app. Another feature we might consider is being able to make a part of your Thymer document public. That way people can share things like roadmaps or ideas with others, who will then also get to know Thymer that way.

Finally, it can help to add easter eggs or other fun components to your app which people might want to share. As we wrote about before, we think it’s important an MVP sparks joy in that respect.

Like many attempts to market a product, some of these can be very hit-or-miss. There’s no guarantee it will work, but if they’re easy to do and don’t cost much time, these viral loops are a good way to increase our luck surface in getting more traction with word-of-mouth.

Calculating SaaS pricing in reverse

Diederik • @jdvhouten • • Part of Day 38

Instead of asking what kind of revenue you can expect with your product, we like to turn the question around. Start with the kind of revenue you need to consider the product viable, and then work backwards.

These are the kind of exercises we do when noodling with possible pricing models for Thymer.com. 

Let’s keep it simple and pick a round number: one million in annual recurring revenue. What does it take to get to that revenue with different business models?

Option 1: free with pro upgrade

With consumer software you want people to try your product before asking for money, and the easiest way to accomplish that is by offering a generous free version. We can then sell a Pro upgrade for $50 (one-time fee).

1 million divided by $50 = 20.000 customers per year. 20 thousand. That sounds like a lot.

But not every user buys your software.

Maybe 10% of trial users do.

Trial users = customers * 10 = 200.000 trial users.

How many website visits do you need for that? Maybe another 5x, if the signup process is good.

Unique visits = trial users * 5 = 1 million visitors.

One million unique visitors per year, or 20k per week. Not an impossibly high amount, but it’s not peanuts either. Where is all that traffic going to come from?

Ads? That’s hard to pull off when you’re bootstrapping. Funded competitors will outbid you the moment you get traction. Besides, when you already have the expense of many free users you can’t afford to throw money at opaque ad systems.

Organic search traffic? Maybe, but it takes a long time to build traffic like that with articles and other content.

Twitter? Interviews? Youtube? Magazines?

You’ll need a massive marketing effort to get that kind of traffic going. And you need to do this every year, just to keep your revenue from collapsing. Let’s see if we have better options.

Option 2: prosumer subscription

Okay, let’s see what happens if instead of charging $50 once we use a subscription model.

The big challenge for consumer subscriptions is churn. Also, repeatedly charging a credit card will lead to a much higher customer support burden, plus you only get maybe 24 months of revenue on average from each customer. Maybe your product will have best in class net retention, but 5% monthly churn is typical for consumer subscriptions and at that rate you lose about half your customers every year.

That means you can charge $50 once or $25 per year for two years. The rest of the math will be the same as in scenario #1 which shows that subscriptions are no panacea. You still need a ton of traffic to get new trial users to get new customers to replace the ones that have churned.

Option 3: subscription for teams

The problem with scenario #1 is that you need a ton of traffic and awareness that we don’t know we’ll be able to get. The problem with scenario #2 is you add a bunch of complexity (subscriptions, renewals, cancelations, unpaid/overdue subs) but the LTV (lifetime value: the total amount paid by a customer for the duration of the subscription) of a customer won’t be much higher because of churn. The entire point of running a subscription service is that your customer base can accumulate over the years, but you won’t be able to do that when your customers leave in droves to chase the next cool thing. The harder you work at growing your business the more relentless churn will be in dragging you back down. 

We can kill two birds with one stone by introducing a subscription for teams: churn and volume. Team subscriptions are automatically more sticky than individual licenses because moving everybody to a different product is a hassle. This means dramatically lower churn. If your product is for small businesses or teams within larger businesses your churn will be maybe 2% per month (= 20% annually). And when you sell to a team you’re selling multiple licenses at once. That’s much faster than selling individual licenses!

If you charge $50 per month for a Teams subscription with 2% churn your LTV is 20x-30x that of individual prosumer subscriptions. That’s a huge difference!

Now, you only need find 400 customers for 1m in annual revenue. That’s 2 new customers a day and you’re golden. That sounds way easier than the 20.000 customers demanded by scenario 1.

You might have noticed that 400 customers @ 50 a month is only 200k and not 1m. That’s true, but you only need to compensate for churn, here. If you have 2000 customers at 50/mo and you lose 20% of those each year, then you need to find only 400 new customers to retain revenue. Any sales beyond that will grow your business. The math checks out!

—

Unless Thymer becomes a smash hit, our revenue will have to come from team subscriptions. Right now, I don’t see any other way. The bright side is that we should be able to keep the single user version of Thymer free or cheap because it won’t bring in much revenue anyway. The downside is that we might end up serving two different audiences, and that features that make sense for a Thymer Team make no sense for a single user version of Thymer (and the other way around). I’m sure this will turn into a careful balancing act. 

Work on what you need to

Wim • @wcools • • Part of Day 31

Starting a business is always a gamble. I still think the odds are better than many assume (not starting one is a gamble too, in a way), but in the end you just won’t know for certain if it will work until you try.

To reduce the “risk”, a lot of advice focuses on making smaller bets and getting quick wins.

It seems a lot of this advice is taken to mean you should always try a “safe idea” to maximize the odds. Try to interview people and see what their problems are. Maybe do some consulting or freelancing instead (vs building a product). Perhaps start an info-product, something easy to make, make sure it doesn’t take too much effort to build. Instead of thinking about a problem, think the other way around: what could get you “rich quick”?

I think this narrow focus on these “safe ideas” is a mistake.

It’s totally okay to have a small scope for your initial idea. It’s very important to be able to launch relatively quickly, because you have no idea whether your product will really work. But that’s always the case, “safe idea” or not.

The biggest problem with reducing the space of ideas people think they can work on is that you stop working on what you feel you have to. It’s great if you really love one of those “safe ideas” of course, but if it feels uninspired or it becomes so much about the quick win, then we we stop dreaming about what we actually want to build. And I believe it’s working on what you feel you have to that really increases your chances of success, even if that’s a harder problem than the “safe bet” easy-win get-rick-quick idea.

You’ll automatically know when you’re working on something and your heart isn’t really in it. In fact, your customers will know it too. Your product won’t stand out, it will feel bland, look the same as the rest, uninspired.

You know that problem that you just have to work on, because it’s where your mind drifts when thinking about solving problems during a walk/shower. It’s the thing you can still work on even if you’re tired (not that you should, but you could!). That means you’ll be able to keep working on it, which is important if you want to succeed. Especially because in every startup there will be many dull and boring tasks which need doing, and it’s hard to stay motivated enough to do all the parts which are boring to you if you don’t really want to work on this problem.

Another advantage of working on your dream idea is that will want it for yourself, so you know exactly what to build. Or maybe it describes yourself. Or it’s a trend you’re part of which is starting to emerge and you think more will follow. It’s hard to time the market anyway, and just coloring within the lines and building similar things to what’s out there is not going to make it easier. Might as well work on your dream and make it stand out enough.

Another important reason to work on your dream idea rather than a “safe idea” you don’t really care about, is that if it actually succeeds, it will become a relatively big part of your life. We can only work on so many ideas after all.

Many of these ideas are discarded because they might feel too unrealistic (or the complete opposite, they might feel like a “hobby”). But those are actually the most interesting. Yes they can completely fail (the advice of finding out quickly is still very important!), but they can also really push things forward. A lot of really interesting and successful things wouldn’t have existed if their creators would have stopped dreaming and just stuck to something “safe” instead.

Work on something you have to, get a V1 out to customers as soon as possible for the type of product, and see if they love it. Worst case you’ve worked on something you had to anyway, no regrets, and move on. Best case they’ll love it and you’ve really added something new to the world.