I’ve been chasing the startup dragon since 2017, and now 6 years later, have decided to reflect on the most important learnings of that time.
Some may seem obvious, some not. Not may be specific to industries in which I’ve opereated in, but can be extended to others by analogy.
This serves as a remind for myself, and hopefully a guide for the next generation of founders.
The advice here is roughly sorted by both my experience over time, as advice for the age of a startup.
There is nothing worth skipping or skimming here, everything here is immesely valuable and has been learned the (very) hard way. Please do not learn this the hard way as well.
Every move you take should have a goal and have actionable evidence for why this process or action is in place.
A fatal mistake I made in the first year being a founder and leading a team was to copy what I had learned from other companies. These companies were far larger than I was, moved far slower than a startup needed to, and had very different product requirements.
As a 2-person development team we spent far too much time on testing, building internal frameworks, making everything a microservice, arguing about structure and architecture, and more. Part of this was having the wrong team for the job, but part of it was my mistake in putting too many processes in.
- Jira had uncessary complexity
- Spent far too much time on CI/CD
- Microservices caused more harm than good
- Overengineered far too much
- Used additional technology for any reason I could find, rather than optimizing for less
- Hire people because it feels right, only hire when it hurts
The solution here is to slim down as far as possible, remove as many meetings and processes as possible, make sure that everyone is aligned, nobody is doing anything for processes’ sake. Also known as “a founder mindset”.
While this conveniently is the slogal of YC, it’s 100% true. This goes in hand with “playing business”, as many people will just build a startup and pour resources into building a company that makes something nobody wants.
A solution in search of a problem is the #1 killer of startups.
You not only need to have conviction that the world wants (or needs) what you are making, but you need to have proof. You need to have identified a want or need that people are extremely eager to throw money at, and you need to have a solution that satisfies that.
Talk to 25+ potential customers, look for patterns, build for that. If you cant find common ground between them, then your solution is not worth building.
This will also help you gague the market size and potential size of your company.
Shoutout to Diana, Dalton, Rich, and Nicolas. Every time they said something it was correct. Whether they thought we should pivot for X, Y, or Z, whether they thought reaching X would result in Y, etc.
They know what works, just listen to them, trust me. Their time and advice is the most valuable thing to a startup.
I only have 2 regrets from the S22 batch:
- I didn’t move out there for the batch
- I didn’t take Dalton seriously on pivoting 2 months earlier than we ultimately decided to for the exact reasons he predicted
And they aren’t just lucky in their words, they’re consistently correct.
Dalton (my GP) and Michael post videos all the time on YouTube, and I often find it spooky about how correct they are. Looking back at my time in the batch based on what I hear them say now, it’s absolutely mind-boggling how right they are, especially when they talk about things founders mess up.
Just seconds in to https://www.youtube.com/watch?v=IdwYMfM2QMs when they talk about founders thinking they know about customers problems, but actually don’t… just @ me next time: https://twitter.com/Dan_The_Goodman/status/1652090727642349570?s=20
Vaulting off the last topic, video https://www.youtube.com/watch?v=IdwYMfM2QMs tells it well, specifically with the AirBnB example.
It’s absolutely true that really caring for your customers gets you info that you wouldn’t have in casual conversation.
With Tangia, some creators were making immensely meaningful income. Upwards of full-time salaries, by (multiple) creators that has <600 live viewers, sometimes far lower. By caring about their issues regarding engagement, abuse of streaming systems, streaming as a career, we learned more about what’s wrong with the industry (and our product) than we would have if we had only done manual onboarding and touchpoints for feature releases.
Often founders think that they need to seem like a big company, sticking a helpdesk in front of their customers and more, just to look successful. But being able to DM the founder of a company on Discord is the biggest retention tool anyone can have, and that only works at startup scale.
In that video, when Dalton talks about AirBnB’s story as a “story about people”, ours is the same way. I keep in touch with our earliest customers, large and small, outside the topic of Tangia. I’ll definitely remember their names (both channel and IRL) for the rest of my life.
Paraphrasing Dalton: “The more layers you have between you (the founder) and the customers, the less you learn”.
If we needed to learn something, I went and personally asked tons of streamers. I scoffed at the idea of a survey or mass email. That would have been horrific, I would have been mortified if we did that. Think about it, when’s the last time you felt important or appreciated by filling out a survey?
Make your customers feel special. Make them feel like the prom queen. Like Cinderlla at the ball. They’re the most important thing in your world, so treat them like it.
Whether you hate him, adore him, or anywhere between, the man knows how to rally a team. The following principals are how I broke out of “playing business”, and vaulted into 30-150% MoM growth in all categories for many consecutive months. These pillars should be followed in order of decreasing importance.
- Make requirements less dumb: do you really need X? Do you need to automate this edge case? Are you thinking as a user or engineer?
- Delete the part or process: The best PR is the one that removes more code than it adds. More code, processes, etc. add more complexity which means more problems. Always prefer to remove. Chances are you can already cut 10-20% of your code or processes you have.
- Simplify or optimize: Can you make existing systems simpler? Is there
- Accelerate Cycle Time: We reduced our dev cycles from 2 weeks to 1 week. We now get far more done in a month. People will take as much time as they are given for a task, so give them less time and they will give you more concise solutions.
- Automate: You don’t need to automate every case. Many failure cases can easily be handled manually, or telling people to reach out to support. Stop spending hours on an edge case that 1/10,000 customers have until you are hitting it every other day, or it’s so unbelievably painful to your business that the time to recover from 1 instance is less time than preventing it in the first place. An example of this would be for handling failures when setting up payout accounts, tell them to contact support rather than automating every possible failure case.
I’ll repeat this again.
Through our first venture, Ultimate Tournament, we hired to a team of 4 (including founders). By the Ultimate Arcade (what we got into YC with, before pivoting in late July), we were at 6. Come 2023, we are again at 4 and are moving faster than ever.
You should have multiple glowing reviews, all paid nearly exactly the same price per hour.
Fixed rates are BS, their predictions are always shorter than actuality.
Any “discounts” they give you just mean that they will give you an inexperienced team that will consistently fail in every way possible. You get what you pay for, there are no real discounts.
In the case of Tangia (YC S22), we built a tool for viewers to send “interactions” like on stream. This included AI TTS (with characters or your own custom voice!), AI Image gen (Stable Diffusion), Overlay Memes (videos), drawing on the stream, and more.
Some of these learnings could be extended to mobile apps building for their respective stores, but it is clear that Twitch’s policies are far more restrictive, and processes are fatally flawed.
This can work both ways.
The giant can use their vague and ambiguous wording, or “Reserve all rights” to pick and choose how they apply policies. While this is unethical, anti-competitve, and probably illegal, what are you going to do about it if you don’t represent a signficant portion of their revenue? You won’t be spending millions over 2 years so sue them certainly.
Sometimes you have to maliciously comply back.
- Inconsistent policy enforcement — or “dart-board policy enforcement” as I like to call it
- Obscenely long response times from support — you are stuck to moving as fast as the giant. Startups benefit from their immense speed.
This can only mean one of two things:
- The company has not seen bad things yet and they will enforce things they haven’t written down yet
- There are lots of unwritten rules that you will only discover through painful interation that they refuse to write down (pick any corporate sounding reason you like)
All of these pains compound, and are exponentially amplified by incompetent management and compliance representatives. The experience will be obscene, and should probably be classified as anti-competitive. But again it doesn’t matter to them, they are too big to fail at this point.
I thought it fun to bring AI into the mix, so here’s a summary:
Click the arrow to reveal
- Avoid copying larger companies and focus on what's essential for your startup
- Streamline processes, reduce meetings, and maintain a "founder mindset"
- Identify a problem and create a solution that people are willing to pay for
- Talk to potential customers and analyze the market size
- Trust the advice of experienced partners, as they have valuable insights
- Follow these principles: make requirements less dumb, delete parts or processes, simplify or optimize, accelerate cycle time, and automate
- Maintain a lean team to move faster and more efficiently
- Seek multiple positive reviews and avoid fixed rates or "discounts"
- Be aware of inconsistent policy enforcement and long response times from support
- Short policies and terms can be a red flag for unwritten rules or inexperience