Top learnings from my own start-up

Introduction

In 2015, I co-founded Xtonomous LLC. There were two major endeavors as part of this company:

• Bot Land: a multiplayer automated strategy game
• Adam Learns: a course-selling site

(if you're interested in the technical background of these projects, here's a super quick overview that I made for my portfolio)

This blog post contains the most important learnings from my last five years. As such, it's all over the place, so I suggest skimming it to see what's interesting to you. 🙂

The MVP is king

A minimum viable product (MVP) is generally the smallest vertical slice of your product. For example, if you wanted to make a site to compete with eBay, you'd probably only allow users to register, list auctions, and place bids. That's it. You wouldn't start with storefronts, categories, search, private messaging, etc.

The point of an MVP is to figure out whether your idea has legs without fully committing to it. By pursuing the overall goal incrementally, you'll be able to make changes as you realize exactly how a particular piece is perceived. If you're not pivoting at some point, then you're either a genius or you're incredibly lucky to have stumbled on the right idea the first time.

I spent more than four of the last five years working on Bot Land. I wish I'd condensed that time into an MVP so that I could learn what wasn't working more quickly.

I did end up taking that learning about MVPs and applied it to Adam Learns, which was originally supposed to focus solely on the learning process. After a month, I discovered that it wouldn't be sustainable, so I pivoted to teaching. It may sound obvious to make that shift, but I thought my first idea could have gained momentum and wanted to see it through. It's easy to rationalize a failing idea by saying that it just needs another few weeks or a major breakthrough, so I was proud of myself for moving on so quickly.

If you're currently working on your own personal project or business, ask yourself: "if I had to launch this in exactly one month, what would I be working on"? If your answer doesn't align with what you're already doing, then you may not be pursuing an MVP.

Know your audience

This advice applies to so many areas: marketing, public speaking, product design, etc. The two major ways I try to know my audience is by listening to them and by looking at metrics. By combining both, you'll hopefully hear two sides to the same story.

This is where feedback comes into play. In my opinion, all feedback has some nugget of truth in it, and it's why I agree with the adage that the customer is always right. There's a famous Henry Ford quote: "if I had asked people what they wanted [before making the Model T car], they would have said 'faster horses'". The quote is sometimes used to illustrate that customers have no idea what they want since they were clearly pleased with the car that Ford made. However, the nugget of truth is simply that customers wanted something faster. If he'd found a way to make horses run safely at 60 MPH, he would have had just as big an impact!

As someone who receives feedback, it's your job to find that nugget of truth so that you know you're proceeding in the right direction.

Ask those with knowledge

Consulting with other people can have benefits that you can't necessarily predict. We all have blind spots. By pooling your knowledge with others, you'll greatly reduce the risk of being burned by these unknown unknowns.

To that end, I suggest making it as easy as possible for the other person to help you. Rather than providing a 10-page design document for review, perhaps an outline could suffice, or maybe you could highlight specific sections where you're feeling unsure.

Learning is free

Learning is one thing that you can do for free that will almost always be helpful. I struggled with marketing since I always felt that the biggest barrier was monetary in nature. However, I could still learn about networking, proper targeting, video production, and negotiation without spending a dime.

Prioritization

Prioritization is crucial for projects of any size. It's especially important when you have the very limited resources of a start-up. At any given time, I had many tasks that could reasonably be approached. For example, Bot Land's infrastructure cost $300/month, which most people were surprised about. The reason? It simply wasn't a high enough priority to address—if the game was going to be successful, then $300/month would have been a drop in the bucket, so it was more worthwhile to pursue feature work or marketing. As a result, I mindfully opted to save time and spend money.

Founders

Pursuing a start-up on your own is tremendously difficult:

• You have sole responsibility of every aspect of the company.
• You're more susceptible to tunnel vision since there may not be anyone else to double-check your decisions.

Both of these are addressed by having a co-founder. The most valuable quality to look for is that you're equally invested, and I don't mean monetarily. One of you could be spending 30 hours a week working while the other puts in $25k of capital, or you could just be splitting tasks 50/50. The point is that you'll both equally want to see it succeed, that way it doesn't slowly fall off of one person's radar. I've seen several of my friends' start-ups fail because the co-founders varied too much in either investment or direction.

Business vs. side project

There's a huge difference between treating an endeavor like a side project versus treating it like a business. Side projects are generally supposed to be fun, so you may end up tackling the parts that you find interesting rather than what's valuable for making money. This misprioritization leads to complacency and scope creep.

With a focus on eventually making money, you can have a north star to guide you through decision-making. It can help you plan an MVP and allow you to pivot quickly and gracefully.

With that said, it's completely fine to do something for fun with no intention of ever making money. Many of my projects fall into that category, but I try to make sure that it's a mindful choice as opposed to a cover-up ("this business may fail, so I'll just say it's a side project so that I don't have to face my fear of it not working out").

Save the rationale

Including context or an explanation is valuable for anything you find yourself revisiting. For example, looking back at my very old notes, I have some cryptic life lessons like "realize when you're falling into addiction". It's ostensibly good advice, but it would resonate with me more if I'd included the context.

For design work, I've found it valuable because requirements can change. For a contrived example, suppose you're making a site where users can purchase copies of your artwork. At first, you only have two pieces to sell, so you write in your design document "no need for a shopping cart feature". That's likely a good call at first, but you may be puzzled when you come back to it a year later and wonder what you were thinking. It's not much extra work to include "...because I only have two pieces to sell right now".

(as a side note, this is also why version history is nice in programs like OneNote or Google Docs; you can see what the document looked like back when you wrote any particular line into it, that way you can get a more holistic view)

Communities require resources

Over the last five years, my Discord server has accumulated nearly 2000 members. On any given day, only 10-15 people would actually chat in it. I never prioritized fostering my community outside of Twitch, so my Discord never "took off". In addition, I was given many offers for help on things that I couldn't reasonably accept due to the overhead that comes with delegating tasks.

This section is more of an observation than a place for me to give advice, but I do have one helpful note: celebrations are important, even for arbitrary reasons (e.g. 5000 followers, 1 year of streaming, etc.). People just like to get together for something positive!

Streaming was beneficial

Live-streaming isn't for everyone, and it certainly had some downsides (e.g. it's distracting, it takes energy, and it's one more thing to manage). Here are the top benefits I felt it provided:

• Accountability: I was on-task most of the time, and I wouldn't randomly play games or go on social media
• The social aspect: I didn't go crazy working in a room by myself for five years
• Learning: ask a question aloud and get an immediate answer from an expert—what more could you ask for?
• Marketing: this wasn't as big as I'd hoped, but I did promote my endeavors through Twitch

TODO avalanche

I had to be very careful about generating too many tasks for myself, especially tasks that came up while I was streaming that couldn't be handled immediately. For example, it happened many times that people would link a video or blog post that they wanted me to check out. Linking it only takes a second, but consuming it takes upwards of an hour. I couldn't get to all of it.

The most helpful thing I learned was to be pickier about what entered my TODO list. The only reason to add something that you know you're going to drop immediately is if you save your finished TODO items, that way you can archive why you dropped it (remember to save the rationale!).

Networking isn't an evil beast

Networking with people originally struck me as somewhat nefarious—you have a particular need in mind when you approach someone, so the conversation will eventually steer toward that need and you'll be outed as disingenuous. I absolutely hate it when people network "at" me, so I shied away from networking myself.

I eventually realized that networking can be as simple as just being nice to people, ideally with no immediate goal in mind. When a need does arise in your life, you can examine your network to see how people could help out. Likewise, when someone else needs something, you should see if you can rise to the occasion.

The grass is greener where you water it

At many times throughout development of Bot Land, I would think about how the grass is greener on the other side:

• I wished that I was making a more traditional game so that I wouldn't have to convince people to like both the genre and the game.
• I wished that I'd had a co-founder still after the first year.
• I wished that I wasn't making a game at all.
• Even with streaming, I was envious of people who streamed just because they wanted to, not because they thought it was best for their product.

The only productive thing to come out of those thoughts is that it made me more mindful when I was done with Bot Land. I analyzed what I wanted, what I thought worked, and what I was willing to do. I felt less envious while working on Adam Learns.

I can do it!

This is sappy and personal, but I truly feel empowered after the last five years. I tackled some really difficult challenges, learned a billion things, and got to share what I loved with the world. If nothing else, it taught me that if I put my mind to something and persevere, I can do it.

Conclusion

At least personally, it takes me a while to internalize common advice or proverbs. For example, I'd heard about failing fast, but until I actually saw first-hand why it was important, I wasn't as inclined to do it. You don't necessarily have to be the one who made a mistake in order to learn from it, but it certainly hits you much harder when that's the case!

I often wonder if I would have ever internalized some of my own learnings from this blog post if I hadn't failed how I did. I'll never know the answer to that, but that's why I leave you with two pieces of advice:

• Consider keeping track of your own learnings as you go. You never know when you or someone else will find them valuable!
• Going out there and doing something will teach you more than you could imagine. Don't ever be afraid to make mistakes.

Thanks for reading, and thanks to those who joined me on this journey. I feel like the next chapter in my life is about to start, and it'll be a great opportunity to prove what I learned over the years. 💪