Tech moves fast. It seems like just yesterday companies like Robinhood, Coinbase, DoorDash, and the like had never been heard of. Now we hear about them constantly. New rounds of investment, IPO's, and whatever the hot new kid on the block is are all the rage.
It's tempting to want to jump right and be a co-Founder. Maybe you have some COO experience at a tech company. Perhaps you have access to capital. Or maybe, you just have an idea that you think the world needs, and believe there is a great opportunity to build something special.
In today's article we are going to outline 6 things you need to know, or be familiar with, before you try to go and found your startup.
#1 - Get to know software and technology lingo
You may or may not be surprised to find out, but most technology founders aren't particularly adept at technology. Now, don't confuse this with successful technology founders, many of which are incredibly technologically savvy. We say most in the same sense that we say “most new startups fail in the first year." See the correlation there?
If you're fairly non-technical, here's the good news: It's really not that hard to get a basic understanding of software development terminology.
You're going to need to understand terms like:
- Client (not a customer)
- Server (not a waiter)
- … and the list goes on
If you don't take the minimal time to learn and understand these terms, you're going to wind up either utterly confused most of the time, or worse, taken advantage of by people you hire.
It pays (very literally) to know the lingo of software development.
Understand how to validate product / market fit
One of the huge mistakes we see over and over again in founding a new company is a complete lack of validating their product / market fit. A common story is:
- Founder raises money
- Founder spends all money building a product
- No one wants the product
There are lots of ways to validate product / market fit, even ways to do so without ever building a product.
Noah Kagan, founder of AppSumo, wrote a great article on super simple MVP's (Minimum Viable Product) validation, using examples like AirBnB.
Another great story of product / market fit comes from Rahul Vohra, the founder of blazingly popular Superhuman, which is a re-invention of email for power-users.
In this wildly popular post, Rahul explains how he built a product / market fit engine to center his entire product team around.
Doing this requires building enough of an app for users to actually interact with and use, but is a great centering piece for taking your next steps once you have even a small (100 person) user base.
So, which method of MVP is for you? Build something small, or build nothing at all?
Establish your true MVP for validating product / market fit
As we've seen above, there are a couple of options for validating your MVP for product / market fit. So should you build something small, or try to not build anything at all?
Building Something Small
This would be like the AirBnB example we used above. Basically, you're building the bare minimum to test the market.
- Getting Beta or Trial users is some indication of initial product / market fit
- If no one wants it, you're out less time and money
- It's cheaper and easier to spec
- It still costs money
- If your idea is big, it may cost a _lot _of money
- It's obviously much higher risk than building nothing
Building Nothing at All
This is more like the Noah Kagan approach of simply putting your idea on a super basic page, then seeing if people sign up for a Beta, etc.
So, pros and cons…
- It's fast
- It's cheap (or free)
- So, it's virtually no risk
- It's harder to truly validate (see below)
- You could reasonably get false positives (sign ups that don't really want your product)
- For these reasons, it's harder to formulate a strategy that works (validates with the right potential customers)
When you build nothing at all, you're not really validating a product / market fit. You might be validating that a market has a specific need or desire, or you might be validating that 50% of the internet signs up for every ad they see in their feed.
So, coming to a conclusion here really points us in the direction of How much money do you have?
Make sure you have enough money in your coffers
Unless you can code, software ain't cheap, even if you're only building an MVP. So here's our advice:
So what does money mean? Generally, for a super-scrappy MVP on a good idea, $200,000+ dollars. That may seem like a lot, and if it does, check out our basic guide to estimating software. Again, unless you code, software ain't cheap.
For you people rolling in cash connections, your best bet is reading further. Building an MVP is definitely feasible, but if you've never done it, there are some important tips you need to follow, or all that money could be gone before you blink.
Have a trusted advisory team (that isn't your investors)
If you've never built software, or a software startup, you need people around you that know what they are doing. If you have investors that have bought into your idea and management capabilities, it will be tempting to look to them for guidance.
Find an advisory team that has experience with these problems, are experts in software development and product / market fit.
If you can't find them in your network, budget to hire them.
This advisory team will be able to understand your idea, your market, tactics for building a perfectly “thin" MVP. Getting this critical startup advice in the early stages will help steer you away from overspending on a product that has little chance of resonating with a market.
And by the way, if you're in the market for one, Take2 can definitely be your advisory team. (We know, shameless plug)
If you've never built an engineering team, don't do it yourself
Last, but definitely not least, if you've never built an engineering team, don't attempt to on your own. The reality is, unless you're a software engineer, agile product developer, or CTO, you're unfamiliar with most aspects of building a performance engineering team.
Think of it this way…
Inadequately matching engineering talent with build requirements (or put more simply, hiring people that can't do the job) is one of the most common reasons for venture failure that we see in the wild.
Leave your engineering hiring to someone who knows how to hire the good ones. Do this until your startup feels too large for you to still be doing it. Then do it some more.
Hiring good engineers is an incredibly difficult (and opinionated) venture that is part art, part marketing, and part data science. Unless you have a lot of experience building engineering teams yourself, you'll be better off getting professional help.
And… shameless plug… Take2 can help. We have been building high performance engineering teams for over 20 years, for everyone from Series A and pre Series A startups to Fortune 50's.
Subscribe to 🎉💪 content!
Get our tech articles once a week, free of spam.