Solving the Problem: Today’s Billion-Dollar Startup Problem
What was created to solve a problem, became a problem itself.
What is a startup to begin with? Well, what’s defined as a startup today has evolved from what was considered a startup a few years ago. The startup mindset is an interesting thing; for most of us, it reminds us always to be lean and keep it small until it’s necessary to expand. But the basis of starting a startup was and has always been, to solve a crucial, immediate user need. Startups were created (in my opinion, at least) because they could take risks that established companies didn’t and couldn’t. There was little to nothing to lose, no big costs involved, and a focused team to bring the idea to market, as fast as possible.
However, what was created to solve a problem, somehow became a problem in itself. Hear me out:
So, as we know by facts, 90% of startups fail:
- because their product failed to make a profit,
- because they didn’t do enough research,
- they targeted the wrong market,
…which, when they’re all drilled down to the core, you’ll find the main issue: they don’t solve an actual problem.
How the modern process goes
An idea is born, a prototype is made, and taken to investors (usually before the target customer even hears of it). These investors and shareholders add a few more features they want to see before they even consider investing in it. More often than not, the primary problem that the solution sought to solve is now third or last in line.
It’s important for entrepreneurs, founders, and product owners to shave away the many layers of what is today’s ‘industry-standard’ product design process and focus on what starts it in the first place: solving the problem.
The problem is the most important thing. Find and solve it first, and everything else falls into place. Don’t get lost in the arguments that lead nowhere. Coding standards and design guidelines should be decided very quickly when they come up, but teams shouldn’t spend 2 weeks just deciding between pointers or references. Using the industry standard or the best framework will encourage cooperation among team members but will not guarantee the success of your product. Put necessity over preferences.
Nothing else is more important than building a product that users need. Nothing. It’s not a successfully planned startup story, having 50%-90% shares in your startup, or a 30–40-page, pea-cocked pitch that investors ‘want’ to see. Build for quality. Build because people find the problem frustrating and would do anything to have it go away. Build and give it to them to test and tell you what they think.
The simple things don’t have to be that complicated, at least in the early stages. In the beginning, it should be just about the problem worth solving, the problem that keeps people up at night. And it is on those nights that valuable startups are born.
Summary
Just keep it super simple, then scale.
