The first thing I posted on this blog is how I miss working on side projects and the excitement that brings. When I was a teenager I was programming websites and was really thrilled by seeing the number of users going up on those websites. I created several of them, including a website for emulator & roms, multiple ones in the web hosting directory space and also a few related to games. I also made a text-based website game and programmed a 2D online game, heavily inspired by Graal Online. The text-based website game was probably one of the most satisfying projects in terms of users and it was very fulfilling to watch the number of users growing. I don’t know if I’m romanticizing this too much but I really miss that feeling.

I think because most of the projects I made during my childhood were so influenced by games, most of my side project ideas now also mostly involve ideas relating to games. Lately however I’ve been growing increasingly interested in a different kind of side project. What if instead of just being another side project, what if it was actually something that could develop into a small side business? Even if it fails, it will still have been a cool experiment and I’m sure there’s much to learn from it. So before jumping head first into this, I decided to start reading up on Startup School.

Startup School

Startup School is a program started in 2017 by Y Combinator, which is perhaps the most successful startup accelerator in Sillicon Valley. The curriculum consists of a mix of videos and also text articles. It covers a very wide range of topics: helping you decide if founding a startup makes sense for you, how to get ideas, planning an MVP, how to talk to users, splitting equity, hiring, pricing your product and raising money.

I’ve now completed a few of the lessons and one of the things I realized is that what I want to do is not really a startup. The startup definition that Y Combinator uses are companies that are designed to grow fast, 100x a year. That involves a lot of blood, sweat and tears and I’m not really ready for that. What I’d like is to start small and most of all, I don’t mind at all if it only grows slowly. I’d be already thrilled if I get any paying user at all.

Below I’ll share a short summary of the lessons I thought were most interesting and helpful for me, from the perspective of what matters for a small side business (so this means I skipped all lessons relating to hiring, raising money and so on). I’ll link to text transcripts instead of videos whenever possible. I’ve organized them in the following order:

1. Should you start a startup?
2. How to get and evaluate startup ideas
3. Planning the initial product
4. How to get your first customers
5. How to talk to users

Should You Start a Startup?

I started with a lesson from Harj Taggar on Should You Start a Startup?

Harj mentions how in the beginning your ideas will be more like a gut feeling, blurry and unclear. You’ll go through several versions of it before it becomes a potential project. To speed up this process he suggests discussing the idea with other smart people.

He then moves to what makes a good founder. The main quality that you need to bring is resilience. It’s an uphill battle from the beginning, you need to convince users to use your product and push through a lot of rejection to get there. You may have built the wrong product and need to pivot it to something else. So how can you know if you’re resilient enough? Unfortunately he seems to have no good answer to this question. From his experience confidence, motivation, talent are not good proxies. He suggests not introspecting too much and instead gives some practical advice:

I also think that simply being curious about what it’s like to found a startup is a fine initial motivation to start one. Actually doing a startup is the only way to know for sure if you’ll enjoy it. If you are curious about what it’d be like to start a company, start by asking yourself, what do I have to lose? Figure out what the worst case scenario looks like if you started a startup and decide if you can live with that.

The most interesting part of the lesson to me was that he suggests to quickly turn the ideas into side projects. Build a first version over a weekend, pitch it to users and see how they react. Repeat this until the project takes shape, however small it is. The objective is not to create the next Unicorn company, but to get the experience of turning ideas into reality and feeling the thrill of launching something. I really love this lightweight approach to side projects!

Regarding if or when you should quit your job to work on a startup, Harj recommends to think less about how the side projects are going and more about if you’re enjoying this process of making ideas into reality. If this energizes you and feels different than your day job, it may be a sign that it’s time to quit.

How to Get and Evaluate Startup Ideas

In this section I’ll be mixing the thoughts from both Jared Friedman and Kevin Hale on how to get and evaluate startup ideas.

Jared starts with a list of four main mistakes that founders make:

1. Not solving a real problem, often this happens when you work from a solution backwards. You think, machine learning is cool, what could I solve using this? This is called a “solution in search of a problem”. Instead, first fall in love with a problem and then think about what would be a good solution for it.
2. Tarpit ideas: common ideas that are much harder than they seem. They seem easy, but there’s usually a structural reason why it hasn’t been solved. E.g. an app for coordinating meeting friends. A common idea but no real solution exists so far.
3. Going for the very first idea without thinking if it would make a good business.
4. Waiting for the perfect idea. Better is to be somewhere in the middle between 3 and 4 instead. Your idea should have enough interesting qualities so that it can morph into to the right idea.

So how do you identify a good startup idea? Jared gives 10 pointers:

1. Do you have founder market fit? I.e., do you have experience to work in this idea? This is both about having experience with the tools you plan to use to solve the problem as well as experience in the field itself.
2. How big is the market? Obviously, big is better. However, markets that are small but growing quickly are also good markets.
3. How acute is this problem? Is this a problem many people have and for which there is no good solution in the market?
4. Do you have competition? What surprised me here is that competition is good. Most people, myself included, believe that if you have competition this is bad. Instead see competition as an indication that you’re solving a real problem. If there’s no competition it’s either a really hard problem or no one has this problem. However, if you’re going into an entrenched space you need a new insight that others don’t have.
5. Do you want this? Do you know personally someone wanting this? These questions are trying to understand if you’re solving a real problem people have.
6. Has this only recently become possible or recently necessary? Eg. a new technology or new regulation that requires new solutions, e.g. GDPR.
7. Are there good proxies for this business? A large company that does something similar, but not direct a competitor.
8. Is this an idea you want to work on for years? Often an idea morphs, or it could also be boring. As it becomes successful, it tends to grow on you over time.
9. Is this a scalable business?
10. Is this a good idea space? An idea space is a class of closely related ideas, e.g. tools for managing hotels. There’s many other tools in this space, e.g. for upselling, revenue management, dynamic pricing etc. This also means you have more adjacent ideas that you can drift into.

So how do you come up with new ideas? While a made up idea is possible, this is not the best way as it’s prone to not being a real problem. Ideas that you come up organically are better. Think about what kind of problems you face on your day-to-day and at work. These are likely problems that other people have too. Jared recommends playing the long game. Become an expert in your field, work at startup or at a large company, build things until you’re inspired enough to have your own ideas on what to solve. Concretely, his suggestions are:

1. Think about what you’re solving at work and start with what you have expertise in. This grants automatic founder market fit.
2. Start with a problem you have personally encountered. The example given here was that veterinarians had to spend a lot of time to order products and a startup created an easy platform for making orders.
3. Things that you personally wish existed. E.g., Doordash, the food delivery company was created by someone tired of picking up their food orders. However, beware of tarpit ideas.
4. Things that have changed recently, either due to regulation or to a structural change. E.g. Covid. In Switzerland you were entitled to 5 free self tests per month. A startup made it convenient to get those regularly per mail.
5. Think of new variants of successful companies. Some solutions only exist for certain countries, could a specific country need a tailored solution?
6. Talk to people and ask what problems they have. Downside is that it requires a lot of skill, so start with an idea space and talk to a lot of users to understand their problems.
7. And finally, if you have don’t have any idea, find someone else to work with you who has an idea you believe in.

How to plan an MVP

I then read How to plan an MVP from Michael Seibel.

Michael again advocates for a very lightweight process, your minimum viable product (MVP) should not involve deep user research nor require long industry experience in the field your project is in. It should be as basic as possible. It should be the very first thing you can present to users to understand if it’s useful for them. It can also be helpful to talk to users before starting any development.

You should launch quickly, even if it’s bad. Get initial users interacting with it as soon as possible. You need to understand if anyone is getting value out of it. Talk to your users and get feedback. Resist the temptation to thinking you know what you have to build and waiting until it’s done to show it to users. You may end up building something customers don’t want at all, so get feedback early.

Hold the problem you’re solving tightly, hold the customer tightly, hold the solution you’re building loosely (redesign/rebuild if needed).

What I really like here is the fast approach. You should opt for a very lean MVP, built in the order of weeks not months. Michael mentions that for software products it’s even easier, you can start with just a landing page and a spreadsheet. Your functionality should be restricted to the absolute minimum and avoid addressing all of the users’ problems at once. Cut your spec and cut even important things if necessary.

The goal here is just to get anything out in the world. Once you get anything out in the world, the momentum to keep anything going is extremely strong.

How to talk to users

Eric Migicovsky shares a framework on how to talk to users. Eric answers the questions on how to run user interviews.

According to Eric, a great user interview should focus on extracting information that will help improve your product or marketing. The objective is not to sell your product, but rather deeply understand what problem the user has. This is a user interview, not a sales call.

Avoid talking in hypotheticals about what your product could be. Resist the urge to ask “if we built this feature, would you be interested in using it?”. Instead, you want to learn more about the user’s life: how did they arrive at this problem, how much time it takes from them and how they are currently solving it. The interview is about the user, not about your product, so do not fall into the trap of trying to pitch your product to the user.

You should ask questions such as:

• “Tell me about the last time that you encountered this problem”: get context around the circumstances in which the user encountered that problem. How often are they having this problem? You can then think on your own if your solution is helping solve this problem or not.
• “Why is this hard?”: how long is this taking to solve, how much does it cost them? You’ll hear many different things from different people.
• “What, if anything, have you done to try to solve this problem?”: this question is two-fold. If potential customers are not bothering to find solutions to this, it may not as an important issue as you thought. If they are, it helps you understand who’s your competition and how they’re approaching the problem.
• “What don’t you love about the solutions that you’ve already tried?”: this gets the insight that you need to have an edge over your competition. It describes what features you should build.

Eric makes the case that talking to users is useful at all stages of a project, however there are three stages where it’s most beneficial: at the idea stage (i.e. before you even started developing your product), at the prototype stage and after you’ve launched and you’re iterating towards product-market fit.

Keep your user interviews casual. 10 to 15-minute long interviews should be enough for you to get the bulk of the information you need and enough for an initial chat.

How to Get Your First Customers

One of my favorite video lessons was How to Get Your First Customers from Gustaf Alströmer.

The lesson is largely based on Paul Graham’s post on Do Things That Don’t Scale. Most technical people want to avoid doing marketing or sales themselves, however Gustaf advocates that it should be the person building the project the one doing the calls, as you are the expert in the product and the process of making a sale forces you to know your users. To recruit your first users you need to really go after them and you can’t just wait for them to come to you. Specially the first users tend to be the most difficult to find and you need to do things that won’t scale in the future. What does this mean concretely? This means spending a lot of time thinking about how to find the potential customers and then on pursuing them: cold emailing, phone calls to demo the product and trying to delight them. Paul Graham even mentions a startup that was sending each new user a hand-written thank you note.

Your first users should feel that signing up with you was one of the best choices they ever made. The feedback you get from engaging directly with your earliest users will be the best you ever get. […] you can and should give users an insanely great experience with an early, incomplete, buggy product, if you make up the difference with attentiveness.

The video gives a concrete recipe on how your first e-mail to potential users should look like:

• These users do not know you, so it should be brief. 6-8 sentences.
• Clear language, no jargon, no buzzwords.
• Write in plaintext (no HTML).
• Describe the problem the users have and how you solve them.
• Say you’re the founder and describe why you’re impressive (“show, don’t tell”; include social proof e.g. companies you have worked for, what your experience is).
• Obviously, include your website. The website needs to be simple too: screenshots of your product and bullet points of what it does. Alternatively a brief, to the point YouTube video of how your product works
• Ask for a call to speak to the customer and present a demo.

Your first customers should be your easiest (no special features required):

• You should have a big pipeline of potential customers - prioritize accordingly.
• Most of people are not early adopters - avoid them. Send hundreds of e-mails to find the right users.

Very surprisingly to me, Gustaf says that you should resist the urge to offer your product for free to the first customers. You should charge them because it’s an early sign that it’s providing value. If you already learn they don’t want to pay for this, it’s a sign that you should move on to the next customers (“fire” the complicated users). Instead, offer a money back guarantee.

Gustaf mentions that it’s very important to understand and keep track of the conversion rates for each phase of the sales cycle, e.g.:

1. You start with 500 outreach emails.
2. 50% of those emails are opened.
3. 5% reply rate (20 replies).
4. 50% agree to setup a demo (10 demos).
5. 20% become paying customers (2 customers).

Using the numbers above, to get your first 10 customers you’d need to send 2500 e-mails! It’s normal to face a lot of rejection. It’s important to make sure you’re reaching enough people, as otherwise you may not have enough data to understand all your conversion rates. Sales is a numbers game.

Idea: Dynamic Hotel Pricing

And I actually already do have a first idea of what I think could potentially be worth trying: dynamic pricing for hotels. Rather than always selling the same flat rate, dynamic pricing accounts for changes in demand. When demand is high, dynamic pricing allows you to charge higher rates. And when demand slows down, rates drop to try to capture as much demand as possible.

I’ve reserved a few hotels over booking.com that always had the same price for every day, so they are not profiting from seasonal movements, or days where demand is higher (typically weekends or holidays). I’m confident I’m experienced enough with machine learning to be able to train a great model for this and also the web app. I think this is also good idea space, as there’s many neighboring ideas I can go into such as front-desk software, reservation management, upselling or channel management.

The dynamic pricing space seems actually quite crowded, I found many good solutions such as Beyond Pricing, smart pricing and even a swiss one called roompricegenie.com. Additionally all large booking portals such as booking.com or AirBnB already offer their own solution for dynamic pricing. However what I didn’t find was someone offering a solution for this in Brazil. I think Brazil is a market with many peculiarities and a tailored solution with market specialists could potentially be an edge.

The challenge will be how to get hotel reservation data at scale. From my short research there’s no single source of data and large portals such as booking.com limit how much data you can scrape. I think there are many interesting challenges and I’m excited about learning more about this space.

As next steps I want to understand how to scrape hotel data and then estimate how many hotels in Brazil are using fixed pricing. I think those would also serve as the best potential first customers.