Millions of business ideas, SaaS, and startup ideas fail everyday. As a business graduate myself, I’ve learnt something quite important about recognizing the potentials of an idea before the costs to prove its worth overwhelms its true value.
Every idea sparks from a pain point and surrounds it to act as a painkiller. But what frequently happens is that we fall so in love with our ideas that we forget the problems they’re supposed to be solving. And just like bugs or inefficiencies in our programs, our obsession with these ideas often manifests and turns into wasted time and dollars.
Making up the problem
The #1 trap I fell into when I started my first hackathon project was exaggerating the problem. It was simple. The initial problem was that Slack workspace owners had to remove inactive or unused channels manually and one at a time. Since this is an incredibly time-consuming process for companies with huge workspaces, say 1000-1500 users, a Slack Bot can be built to 1. monitor all channels within a workspace, 2. set a threshold of inactivity, and 3. archive channels that have been inactive over the threshold.
So I started building the Bot with these 3 main features in mind. A few hours later, I thought, "What if the bot could automatically send messages to admins about channel activity, and flag any messages that contain data prone to insecurity or any anomalies like harsh language / vulgarities?" Now you may think that I'm only thinking these because I was done building the initial 3 main features, but I wasn't even halfway through the first.
Now I've got about another 6 features I want my bot to have. It's the following week with about 3 hours left before the due time and only 1 feature package passed release checks. I had to present my idea with a beautiful slide deck only to spectacularly fail at showing a working demo.
Now I know what you're thinking, if I worked with another developer or a team I’d probably be able to get them to build all the features within the time frame. Yes, that's exactly what I thought as well, until one of the lecturers hit me with this:
"Imagine you're a potential user of this bot. You're on Slack and you've got about 200 channels that are inactive and you want to archive them. Since Slack has no built in functionality to do this in bulk, you go to Google to search for a solution and you land on this bot.
You click on the webpage link, read the documentation on how to use it, and get overwhelmed with a whole bunch of features you don't need. What do you do then?"
Which was a really good point because as a user, I would simply tab back to Google and search for a better solution. I wouldn't have even given my slack bot a second thought or even another 20 seconds to look through. Yes it's brutal, but it’s true, because if I wouldn’t pick my own bot, I’ll assume that not many people would either.
Having gone through all of that, I just spend a half day on each idea I had from then on. Build one feature and get it to ship, as fast as possible. Extra features are like the sides of fast food meals. They might look really appetizing, but a whole lot of them would rack up in prices and make you too full for your burger which is the hero.
There's always someone doing it better
Now even though I gave up on the idea post-hackathon, I was still itching from the epic fail. So I Googled "archive slack channels automatically" and a whole bunch of well-built, simplistic, easy to implement solutions appeared. One of which was Channitor, which solved the problem immediately within 2-3 clicks of being added to a Slack workspace.
Of course there are hundreds of solutions to the same problem. Someone's always doing it better and someone's always got the better approach. But what really humbled me was that there is no one-shoe-fits-all approach. Every single thing has its own specific purpose, just like how a Mustang is to be driven with style, and a Toyota is to be driven with comfort. You wouldn't drive a Toyota to a drag race and you definitely wouldn't try to fit an entire family in a Mustang.
The lesson truly learnt here is that no matter what we're doing, building, or creating, there's always someone doing it better. But what really helps propel us is the things that make what we build different from the others. A product isn’t just the features it represents, it’s the feeling that people get when owning it. I've understood this very clearly from the music industry since it is as highly competitive as tech or maybe even more. Someone's always got a better voice, a better guitar hook, a better beat. But what sets me apart is what my art truly means and how I tell my stories through them.
What I’ve learnt from quitting early
Yes, just like nicotine and alcohol, it’s better and easier to quit early, and while the risks are invisible. A bad idea will never seem like one at the start. It might even seem like the best idea ever. But don’t fret, failures are never the end and there’s always a step up to a better application and an award-winning idea. Here’s what I’ve learnt mostly from my spectacular failures:
Clarity is key - be able to define the problem statement clearly, and if possible in one short sentence
Do proper research - talk to people who potentially have the problem you’re trying to solve and get their insights on how they’ve looked for solutions, what solutions they’ve landed on, what works for them and what doesn’t
Don’t fall prey to Shiny object syndrome - focus on the main feature instead of getting distracted with a million other potential features. Most of these probably wouldn’t even make a difference until your idea blows up anyway
Treat feedback like food - listen to your potential users! They’re the ones who are going to be relying on what you’re building anyway. How would you feel if the waiter taking your order gets it wrong twice or even thrice?
end
Well if you’ve made it this far into this read, please leave a comment and let me know what you think! As this is my second post do share some thoughts on my writing as well, remember I take feedback like it’s food :)
Top comments (0)