How to survive a startup
Let’s first establish the basics, what is a startup?
“A startup is a company working to solve a problem where the solution is not obvious and success is not guaranteed” — Neil Blumenthal
At the first glance, the definition above doesn’t seem as good as your own secret startup idea du jour. There is an increasing number of wannabe CEOs and fresh Zucks with abstract ideas that have almost nothing to do with reality. Success is not guaranteed in the wild and the road to get there is quite rocky.
As you want to present your idea to broader audiences, you will need to build a so-called Minimum Viable Product — MVP:
“The version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort” — Eric Ries
It all starts with an amazing pitch about success, opportunity and chests of gold. Soon you find yourself in a maze of challenges and problems you don’t know how to solve.
It is pretty amazing that investors are willing to give millions in funding for half-ass ideas and unknown development teams.
But let’s not kill the unicorns and rainbows right away!
In this article, I will highlight some survival techniques that our team has identified while building startups.
Define your MVP budget
Burning hundreds of thousands of dollars on an MVP is not a good usage of your money. It is EXTREMELY important to define a budget you can afford to spend without getting anything in return ( a pessimistic outcome ).
A good way to avoid a high burnout rate is to define and estimate features upfront with a senior full stack developer. This will prevent going into the madness of daily development and paying per hour / fixed amounts for an indefinite period of time.
Ship early
Building startups is all about validating your business idea in the wild as early as possible.
You have heard this one a hundred times, but it is indeed one of the most important things a startup founder can do.
Perfection is a myth, ship early and validate, validate and iterate.
Avoid optimistic estimates
Take developer estimates with a grain of salt!
Many of them will say: yes sir, this feature is a piece of cake, we will build it in a week max! After this you end up in a 3 month cycle trying to release the promised feature, filled with excuses, delays and dev related problems that you never wanted to know about.
A good way to avoid this is to offer optimistic, normal and pessimistic estimates on every chunk of functionality. The pessimistic ballpark is where you will end up for 80% of the features.
Some teams use Agile/Scrum techniques to estimate features. Standard techniques are sprint planning, story points, sprint retrospectives, and velocity indicators. But those are seldom done right and applicable to everyone. In our house, we like to hover in the realm of Kanban and continuous delivery instead.
After the MVP, assumptions should be gone
A new feature for your product is actually an assumption that something might be enticing for the end users. That can be fine ( with some luck ), and your race to the MVP is something that will be powered by those assumptions. A recommendation here is to validate each feature and collect feedback early.
Once you release the MVP, there is no more space for assumptions and they should be completely gone. The initial group of users will validate your ideas and they are the source of truth all the way till the end of the journey.
The customers will help evolve your startup into something different from what you envisioned.
I feel my ideas are valuable, why would I listen to some random customers?
A quality product solves real problems, and users might want to even pay for that. So, initial ideas are less important, especially after the release of the initial version of the product.
How do I know what users want?
Talk to your customers, collect feedback and analyze data.
The realm of analytics will give you all the answers you need. Hence using tools like Google Analytics, Mixpanel, Localytics etc. will give the right answers.
The deep forest of analytics is getting quite thick and it is pretty hard to identify and correctly use the right tools. Many .io related products are popping out every day. Seek for help early and learn, learn, learn.
The guys from http://www.segment.io are doing great stuff that will help you on the experimentation front. Make sure to check it out.
Customers are the most important aspect of your business
Every single customer that comes into your platform needs to feel like an important person, especially in the beginning!
So, having a customer service strategy is something that is essential. Most new founders decide to reply themselves to customer emails or to not reply at all until the product is perfect :)
What is gonna happen if you do not respond quickly enough? if you don’t listen to feedback? if you don’t apply that feedback?
The answer is simple: the users are gonna go away with all their friends and networks.
There are many ways to interact with your customers, from traditional communication channels & social media, so that’s not gonna be so hard.
Focus yields success
Building yet another feature into your product is not gonna lead you to success. That is gonna be one more thing to think about with the following:
- translations
- maintenance
- development time
- monitoring and computing resources
- documentation
- testing
Pick your battles wisely: A small set of features is more than enough to validate a business idea.
Avoid toxic team member behavior
The success of a startup will be defined by the team that is building it. Toxic team member behavior need to be identified and removed as early as possible.
What is toxic behavior?
- not sharing information
- not following best practices
- not communicating and delivering daily
- not being accountable for the executed work
- not being absolutely committed ( part time anyone? )
If you identify any form of the mentioned behaviour, you have a cockroach in the fridge.
Let’s keep in touch
Hopefully some of the above can help in identifying and removing some issues along the way to success. Feel free to reach out anytime with questions by dropping an email to: resad@ministryofprogramming.com
