The ugly truth

In order to make an agreement on the terminology, let's start with a definition of a startup:

"A startup is a company working to solve a problem where the solution is not obvious and success is not guaranteed"

Taking a look at the definition above doesn't sound so good as your very secret startup idea. Success is not guaranteed indeed in the wild and you will find a lot of wannabe CEOs and new Zuckerbergs with a very high level idea that has almost nothing to do with reality.

As you want to present your idea to the broader audiences, you will need to build a so called 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.

Also it is still pretty amazing how investors are willing to give millions in cash for half-ass ideas and unknown development teams.

But let's not kill the unicorns and butterflies, THERE IS A WAY, and I will try to highlight some survival techniques that the team at Ministry of Programming has identified while building several startups with teams all over the world.

Define your MVP budget

Building startups is all about validating your business idea in the wild, and burning thousands to millions on an MVP ( Minimum viable product ) is not a good usage of your money. It is EXTREMELY important to define a budget you can afford to spend without getting nothing in return ( potentially ).

A good way to avoid a high burnout rate is to define and estimate features upfront with an Architect-level developer without going into the madness of daily development and paying per hour / fixed for and indefinite amount of time.

Ship early

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 your idea.

Avoid optimistic estimates

It has happened to many new startup founders to talk with cocky developers that said, yes sir, this feature is a piece of cake, I would say we will build it in a week and then you end up in a 3 months cycle trying to release the same feature, filled with excuses, fairy tales, interruptions and dev related issues.

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 like to use Agile techniques to properly estimate features, like sprint planning, story points, sprint retrospectives, velocity indicators, but they are seldom done right and applicable to everyone.

After the MVP, assumptions should be gone

Having an idea is about an assumption that something might work in the wild. That is fine, and your race to the MVP is something that will be powered by that assumption.

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 help you evolve your idea into something potentially different from what you initially envisioned.

How can I proceed without applying my ideas?

A quality product is one that the users want to use and potentially pay for, so your ideas are less important after you release the initial version of your 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. So using tools like Google Analytics, Mixpanel, Localytics etc. will give the right answers.

The problem is that the deep forest of analytics is getting quite thick and it is pretty hard to identify and correctly use the right tools. Since more .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 the 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 quick enough? if you don't listen to feedback? if you don't apply that feedback?

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 etc.

Success is about focus

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
  • dev 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 behaviors 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 commited

If you identify any of the above behaviors, 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