How To Find A SaaS Idea
March 20, 2020
This coming week, I’m running the Seven Day SaaS challenge, a coding jam for building an MVP SaaS within a week. It starts today!
In addition to running it, I will also be participating. That’s the whole reason I started it, after all: I wanted to build some software alongside some other developers.
There’s just one problem, though: I still haven’t decided what I’m going to build.
However, I do have a solid list of ideas that I’ve been compiling on the side in Notion, so it’s not actually as bad as it sounds: I just need to decide on one and plan it within the next two days to avoid wasting time (the latest I can start without wasting time is Sunday at 11:59pm).
So, where did I come up with these ideas? And how can you do the same?
Bullet points that we’ll expand on in this article:
- Why all of your startup ideas are doomed to failure
- The difference between an “idea” and solving your own problem
- Why it’s better to solve somebody else’s problem
- The best way to come up with a startup idea
That said, let’s jump in:
Why all of your startup ideas are doomed to failure
I’ve scoured the internet for a while, read a number of guides, and a good amount of the podcasts over on IndieHackers.com, and I think I have a good understanding of where successful ideas come from.
It turns out that there are two main routes you can go: either build a project that scratches your own itch, or build a solution to somebody else’s problem.
There’s also one way to absolutely guarantee that your idea will flop: come up with an idea that you think solves somebody else’s problem.
Having said all that, for the rest of this article I’ll stop using the term ‘idea’ and start using the phrase problem solution hypothesis. Yes, it’s a mouthful, but it’s really important to drive home the fact that an “idea” cannot be a profitable SaaS.
An “idea” by itself is useless. Building a profitable SaaS from an “idea” is like trying to create a puzzle by hand-painting a bunch of individual puzzle pieces and then hoping that the resulting completed puzzle is a coherent image.
Instead, what you want to is start with the problem – the image that the puzzle should solve – and then break it down into the pieces. Lay down the lines, not the overall image.
This trips a lot of people up, because it’s an easy trap to fall into: thinking that you understand a target market’s problem well enough to conjure up a solution for them with code and sheer creativity, without ever talking to one of your potential customers.
But it’s kind of thinking that is responsible for most of the failure cases I’ve seen: the reality is, problems people will pay for are way too complex for you to understand without having lived the struggle.
The difference between an “idea” and solving your own problem
Now, here’s the crucial difference: if you solve your own problem, you really have lived the struggle, so you can easily come up with an MVP that works. Of course, there are a number of important variables that need to be met in order to validate your solution hypothesis.
First, you need to ensure that the size of the problem falls within a sweet spot of being achievable for you to solve, yet also not so trivial that it has been solved a million times. You don’t want to build yet another todo list app, nor do you want to attempt to build a SaaS to generate an algorithmic cure for cancer.
It’s not a matter of the problem having been solved before, mind you: there are plenty of problems that have many solutions. There are also plenty of different burger franchises out there, and that doesn’t stop new ones from popping up all the time.
There are enough hidden differentiators that you might not be able to see going in between the product that you’d build and the existing options on the market that you really shouldn’t worry about an idea having competition.
In fact, if an idea has competition that’s a blessing in disguise, because that means other people have already done the work and validated the problem solution hypothesis for you. You know that you’ll be successful if you execute well: all you have to do now is execute well.
A parting thought on this topic: you don’t have to be best solution out there; you just have to be slightly better than the worst solution out there.
Why it’s better to solve somebody else’s problem
So, solving your own problem is one way to come up with an idea. Let’s take a step back though and ask a question: where do all of your (solvable) problems come from?
Mostly, they come up in the course of pursing the activities that make you money.
I.e., your job.
And what is your job? Well, if you’re reading this, I’m almost 100% certain that you’re an engineer. You’re in the business of producing software.
Ergo, the problems you run into on a daily basis are software problems… problems that an engineer is uniquely positioned to solve.
In fact, our industry is unique in that it’s the one of only industries where the target audience is actually capable of solving their own problems, and largely prone to doing so for fun.
For that reason, there’s a dearth of low-hanging fruit when it comes to problems to solve in the developer ecosystem.
If an engineer has a solvable problem on his hands, you can pretty much be sure that he’s built a solution to it already. I’ve done that before, and I’m pretty sure you have to.
Now, like I said in the previous section, the fact that there are existing solutions in a problem space doesn’t necessarily need to be a deterrent. However, it’s true that the more solutions there are in a space, the harder it will be to be noticed.
Therefore, it’s going to be easier to be noticed if you’re engaging in a problem space that isn’t saturated with solutions, or at the very least isn’t the place a bunch of wrench-wielding codemonkeys who exist only to solve problems call home.
So, expand your horizons: look at the construction industry, the dentist industry, the fishing industry, the graveyard management industry, the gym pool management industry (these are not made up, by the way).
Call around, talk to your network. I don’t just mean those ~300 people you’ve never met on LinkedIn, but your actual family, Facebook friends, etc. Money quote from the above link:
There’s a software company for every type of company in the world with white collar (or trades) employees.
There is a mini-ecosystem of companies for every… , in fact.
There are multiple companies competing for each niche in that ecosystem.
(If you’re not already following Patrick McKenzie, you should be)
Figure out what the problems that they’re having are. Solve exactly the problems they express (how do you do that? Read this book, no affiliate link I promise).
Of course, the same success criteria that I mentioned in the previous section apply here, too.
But let’s reiterate the big advantage you get from considering building a product in an industry outside of yours (software development): It’s just now you’re going to be operating in an industry which has software problems and isn’t particularly optimized to solve them.
So, this is probably a better way to come up with an idea than by just solving one of your own problems. But is there another, better way? Turns out, yes, there is.
The best way to come up with a startup idea
There’s one resource that I’ve failed to mention so far, that actually turns out to be quite critical.
How many times have you seen a post like this in Indie Hackers, r/Entrepreneurs, r/SaaS, r/Startups, Hacker News, or elsewhere?:
I’m just so tired, I’m sick of this problem and I feel like I need to just sell my company and try something else.
Easy fix, you say, just take a vacation for a couple of weeks, right?
Right. Sometimes, that actually is the solution. But most of the time, working on something that drains your energy will never get better.
Instead of doing something that slowly drains your money, you should be doing something that creates energy within you — something that you enjoy.
Taking that into account and also taking into account what I said earlier about it there being more space in fields far, far outside of engineering and product development, the best way to come up with a startup idea becomes clear.
Create a solution to somebody else’s problem, where that problem sits at the intersection of being genuinely interesting / meaningful to you and being something that you are reasonably capable of addressing.
Bonus points: you should be able to build a solution very quickly, even if it’s hacked together with spreadsheets and as much manual work as possible.
Following these heuristics as closely is possible as how I’ve come up with the list of startup ideas I plan to choose one from.
There are plenty of other bits and pieces to consider, to be sure, but these are the main guidelines you should follow and really represent the two schools of thought as to how to come up with startup ideas.
Next week, I’m going to do run some analysis on all of the Indie Hacker podcasts and come up with some hard data on who followed which ideation methods and how that went for them. Keep an eye out!
By the way, stay safe, stay healthy, and stay indoors.