It's been said that ideas don't matter, and that only execution does. I wholeheartedly disagree. You need both to succeed, but you can only get so good at execution. A great idea gives you much more leverage.
Below is my framework for coming up with great business ideas.
Most people equate product ideas with business ideas. That's wrong. Your product is only one part of your business. There are at least four parts in total:
Great business ideas are strong in all of these areas.
Notice that I listed the problem first and your solution last. Your product should be the last thing you think about. In fact, this is the #1 rule for coming up with business ideas.
Why? Because your product is the most flexible part. You can build anything. But the other three aspects are constrained. You have to choose from a limited set of viable problems, channels, and models. Always start with the constraints.
Seth Godin puts it nicely in his book This Is Marketing:
It doesn't make any sense to make a key and then run around looking for a lock to open. The only productive solution is to find a lock and then fashion a key.
It's easier to make products and services for the customers you seek to serve than it is to find customers for your products and services.
When you find yourself trying to think up product ideas, you're putting the solution first. Not only is this backwards, but it's harder!
It's impossible to design a great tool for a job before you even know what the job is. So how exactly are you supposed to think up good product ideas out of thin air?
At best, you'll trick yourself into thinking you have a great product idea. Then you'll spend months building it, only to eventually discover that it doesn't solve a valuable problem, it doesn't fit snugly into any marketing channels, and it doesn't lend itself to any lucrative monetization models.
You'll make your life easier and your business ideas better if you put the problem first and your solution last.
It's important to recognize a good problem when you see one.
A good problem is one that many people have. Otherwise you won't have enough customers. For indie hackers, this number doesn't need to be too big. Usually a few hundred thousand people is enough. In some cases, much less.
You want these to be people you genuinely like talking to, because they'll be your customers for years. Don't serve people who make you miserable. And ideally you have the same problem as them, too, so you can empathize with what they're going through when building a solution.
It's best if the people who have this problem hang out together and identify as a named group. For example, "developers" or "teachers" or "NBA fans" or "YouTubers." That means they're likely to make all sorts of recommendations to each other, including products, which makes word-of-mouth growth possible for your business. It also gives you channels where you can reach lots of your customers at once.
It helps if the problem is a growing one, meaning more and more people have it every year. This sets the stage for your business to grow. And you want it to be a problem that people encounter frequently, so they'll seek out your solution on a regular basis.
Finally, and arguably most importantly, you want it to be a valuable problem. In other words, you want it to be a problem that people pay money to solve. Preferably lots of money.
Armed with this knowledge, it's time to find a problem. You're going to have to brainstorm. Some people recommend that you just sit around waiting for inspiration to strike. I don't. That might take years, if not forever. Be proactive.
It's hard to say where the best place to start brainstorming is, not because there are so few, but because there are so many. There are thousands of good problems out there, and practically anything can trigger you to stumble across one.
What's more important is that you recognize a good problem when you see one, and vice versa. If a problem scores poorly on the guidelines above, don't waste your time. Keep brainstorming.
For that reason, it makes sense to start with one of these guidelines in mind, and let that be your trigger. For example, since it's helpful to solve a problem that you have yourself, why not take a look at your own life and see if you can spot any problems. What worries you, exasperates you, or annoys you?
The other guidelines also work well as brainstorming triggers. Who do you like spending time with? What groups are you a part of? What are some problems you notice people solving frequently? What's something that seems to be growing into a bigger trend?
My personal favorite is to start by looking at where people are already spending lots of time and money and go from there. Money changing hands is almost always a sign that there's a valuable problem being solved. Who's spending tons of money, and what problem are they solving by doing that?
Founders typically have already made one or two huge mistakes by this point. If you can avoid these, you'll be way ahead before you've even started.
Some of these points are a bit counterintuitive. That's why so many generations of smart-but-uninformed founders are repeating the mistakes of their predecessors.
But it's simple to avoid these kinds of mistakes once you know them. It's a matter of knowledge and discipline, not genius and hard work.
Once you have a good problem, you need a distribution strategy. You need an answer to the question, "How am I actually going to reach my customers?"
The number one mistake here is skipping this step entirely. Especially if you're a developer, a designer, or a creator of any kind—you're antsy to get to the product. Growth-related activities probably seem boring, perplexing, or even nefarious to you. You'd rather just build something so great that it grows on its own.
Sadly, that almost never happens. Relying on it is akin to playing the lottery. Sure, you've seen some stories. Some people win. But probably not you.
Remember that even though artists like to complain about the record labels, they do record deals regardless. It doesn't matter how great your music is if nobody ever hears it. Your business can't make money if your product doesn't reach your customers.
Don't put this off. Don't leave it to luck.
Fortunately, brainstorming about distribution is easier than you might think. You're limited to a small number of channels that you need to investigate. From the book Traction:
After interviewing more than forty successful founders and researching countless more, we discovered that startups get traction through nineteen different channels. Many successful startups experimented with multiple channels until they found one that worked.
We call these customer acquisition channels traction channels. These are marketing and distribution channels through which your startup can get traction: real customer growth.
For example, channels include things like SEO, press, content marketing, social media, sales, partnerships, ads, etc.
I won't get into testing traction channels, because that's beyond the scope of this post. But the first channel you start with should almost always be direct outreach. In other words, 1-on-1 conversations with customers, either via the phone or in-person.
That's usually the easiest way to get your first few customers. You don't have to be a marketing genius to send some emails or make some phone calls. You just have to put in the work.
It's also the best way to interact with early customers. You'll be much more persuasive in conversation than your website will be on its own, and you'll learn crucial lessons from listening to what your customers have to say.
The only reason big companies don't do this is because it's expensive and doesn't scale. But that doesn't matter for you. You don't have to care about scale when you're trying to go from 0 customers to 1, or 1 customer to 10, or even 10 customers to 100. Don't copy what big companies are doing when you're a small company, or you'll throw away your natural advantages.
Later, however, scalable channels are important. It's not enough just to do a glitzy launch, because you can usually only do that once. You need to put some thought into long-term, repeatable channels.
Luckily, since you started by thinking about the problem, you have some hints. You know who your customers are, right? So ask yourself: What channels are they already making heavy use of?
For example, if I was solving a problem for software engineers, I'd be looking at GitHub, SEO (developers do tons of Google searches), Hacker News, conferences, code-related newsletters and podcasts and YouTube channels and communities, Twitter influencers, bootcamps, etc. These are all potential channels.
If you can't think of anything decent, that's usually a sign that you don't know enough about your target customers and how to reach them. It's possible that you need to go back to the drawing board and pick a different problem or set of customers.
Finally, think about your solution. How are you going to solve the problem for your customers?
Don't just copy what competitors are doing. Yes, I advised you to pick a straightforward, proven problem that people are already paying to have solved. But you shouldn't abandon creativity with your solution.
If anything, you want to solve the problem in the exact opposite way your competitors do. This is where you stand out. This is where you innovate. Inject as much of your unique personality and ideals as possible. It can even be simple things. I made Indie Hackers blue because every other blog was white.
More importantly, your solution should be built from first principles. You should be taking everything you learned about your customers and working backwards to build the best solution that fits their unique experience of the problem.
This is the essence of product-market fit: tailoring your product specifically to your customers' needs. You want to make it such a good fit for these specific people that it's a no-brainer for them to use it. Stripe, for example, knew its target customers were developers, so in the early days they focused heavily on great API design and stellar documentation—the things that developers care about most.
This is the kind of advantage you can only get if you've identified a customer and their problems before you started on the solution. Otherwise you'll build something generic.
You also want product-channel fit. Find a way to build your product so it perfectly fits into your chosen distribution channel. Wes Bos, for example, tweets out educational tidbits from his upcoming courses, and it's some of the best content on Twitter. Indie Hackers' #1 distribution channel was Hacker News, so I specifically modeled the interviews I conducted after posts I'd seen succeed consistently on HN. Again, this is the kind of advantage you can only get if you've identified your channels before you started designing your product.
(Hopefully you're beginning to see why the #1 rule is think about the problem first, and the solution last.)
If you can't think of a good solution, or if it's too hard or expensive for you to build the solution, or if the competing solutions are completely unassailable due to things like network effects or economies of scale, then you may need to go back a step or two.
Commonly, what you need to do is take the problem you identified in step 1 and shrink it a bit. Make it more specific, so it affects slightly fewer people (a niche), and then try to think of a channel and solution specifically for them.
The final mistake to avoid here is attempting to start too big. You are not Google, or Uber, or Airbnb. You're an indie hacker, and you're just getting started.
Big, successful companies looked completely different in the early days. Trying to copy what they look like today is a huge mistake. You have to work your way there one step at a time by starting small, accruing small wins, and building off of those.
For example, egghead.io started with the founder, Joel, finding a bunch of videos on YouTube, putting them in a ZIP file, and offering them to someone else's mailing list for a price. That's a far cry from what egghead does today. But he couldn't have started where he is today, any more than you can jump from the ground floor straight to the top of a staircase.
Take it one step at a time.
When you're thinking about the problem you're solving and the size of the market; when you're thinking about the distribution channel; and when you're thinking about the product: think small.
What's the simplest thing you can do? Great, now go even simpler than that.
The one exception here is your monetization model, where you want to do the opposite. Charge more. Indie hackers should not compete on price. That's for huge companies like Amazon.
This guide is longer than I initially planned, but once you internalize the lessons, you can run through this process quite quickly.
True idea validation is going to require rolling up your sleeves, talking to people, and maybe even releasing a product. But you can make it pretty far at just the theoretical phase by thinking about some of the concepts above.
As a sanity check, try reverse engineering a few other successful companies by running them through this process. I've compiled a huge list of founder interviews, podcast episodes, and profitable products for this exact purpose.