Five Startup Red Flags
Early Signs Your Project May be in Trouble
I’ve worked for a number of startups in the past ten years. Some of them soared to success while others never managed to get past the tipping point. Over time I grew curious why some startups become successful and others don’t. As I started reading books about startup management and digital entrepreneurship, a number of patterns emerged that confirmed my experiences. Here are some of them.
Not Running Analytics
Data is the new oil. Your product, no matter how well-researched and planned, may still fail because the reality of the digital market is often not how we imagine it or how common logic dictates it should be. But even if your product ends up being unsuccessful you can still gain some valuable insights from its data. Those insights can guide you on your next venture or even help you to timely pivot and save a failing startup. But not collecting data or running analytics is likely to leave you none the wiser.
Arbitrary Tech Stack
If your stack is mainly determined by the skills currently available within the team—and not by it being the best fit for the job—it may create some serious issues down the road. It can be argued that it doesn’t really matter in the early stages of a startup, since the goal is to test an idea and do it quick. But issues like performance, scalability, and the availability of relevant skills on the job market may pop up sooner than you expect and slow you down while time is still precious.
Not Following the 80/20 Rule
This goes for both features and their implementation. Trying to deliver a polished feature before it’s been validated is a waste of time. According to research 80% of features are rarely or never used. The same goes for trying to catch every edge case no matter how rare. In the early stages of a startup, anything you build must be validated by data. Build the absolute minimum you can get away with and demand tangible proof for anything that comes on top of that.
Not Removing Unsuccessful Features
This dovetails into the previous point: most features end up unused. But new features also add complexity to the code that has to be maintained and increases the chance of bugs. Once you’ve found out a feature is not being actively used, it becomes a good candidate for removal. If you have compelling data you may even opt for early removal based on prototype testing or experiment results. Also, the earlier you remove a feature, the lesser the chance it will annoy some of your users
MVP Taking Too Long
There’s a reason Marty Cagan calls it Minimum Viable Prototype (not Product). If it’s taking months to build without something to show your users and stakeholders, it’s probably way past the Minimum phase. Remember, an MVP is a product discovery tool, not the actual product. There’s no way of knowing when it’s complete because you haven’t discovered what it has to do yet. During the product discovery phase there are other things to worry about rather than delivering a slick piece of software. So don’t wait too long!
