My 3-Step Process for Finding Profitable SaaS Ideas

Feb 20, 2024 - 4 min read
My 3-Step Process for Finding Profitable SaaS Ideas
Share

If you're thinking about building a SaaS product or have already started building one, this article will show you the three-step process I go through to find profitable SaaS product ideas.

This process helps you either start with the right product idea or pivot the one you've already started with and increase its chances of success.

Here's a video version of this article if you prefer to watch instead.

Understanding who's it for

Many founders believe that they need an idea to get started, but in my experience, ideas come later when you already know who you're trying to help and what problems they are trying to solve.

Unless I'm building a product that scratches my own itch (and that's a totally valid way to go, by the way), I can't start looking for ideas because ideas are solutions to problems. And if I don't know the problem, my ideas will solve an imaginary one.

So, I want to make sure I've picked a specific person first, then I'll move on to finding their problems, and only when I know the problem I want to solve can I start looking for ideas.

Building a lovable product

When I know what problem I'm trying to solve and what a potential solution might be, I start building a prototype.

And this is another area that different founders have different opinions on. Some believe that as long as you're solving a painful enough problem, it doesn't matter what the product looks like.

Others believe that everything has to be perfect before you launch.

I like to take a hybrid approach. I believe that a healthy business idea starts with competition. So you're almost always trying to beat the competition.

I also believe that spending too much time on making everything perfect is a form of procrastination that doesn't drive business results.

So, to me, the ideal first prototype has to be useful, meaning it has to solve the problem that the customer is facing, but also the user experience has to be good. Not perfect, but good.

I say this because I've watched myself walk away from too many products that seemed rushed, and I didn't even try them out. I knew that even if they did work, I wouldn't like using them, so why bother?

Getting the business model and pricing right

Before investing my time in building a SaaS product, assuming I found a person with a problem worth solving, I always like to ensure that the business model and pricing make sense.

Now, this isn't a very scientific method. It's just a back-of-the-napkin type of business model.

I have to do it this way, instead of coming up with a complex Excel spreadsheet, to allow my products the flexibility to evolve into something people want to buy. I want my products to be customer-driven, not the other way around.

At this point, I want to find out how to increase the value that my users get from using my products as much as possible. Then, I can price accordingly and decide on the best business model.

This flexibility allows me not just to build the product but also to create a sustainable business. So, if the business model needs to change or the price needs to go up, I should be able to do that.

Some ideas are completely unscalable, so I want to avoid wasting my time building the wrong thing. And that's what the back-of-the-napkin business model helps you realize.

To give you an example, about 15 years ago, I built a product that was targeted at the local market. So, my total addressable market was just a fraction of the number of people in my city.

That made the product incredibly hard to scale. And if I had thought of that before building the product, I would've saved myself a few years of hard work.

But you don't have to make the same mistakes as I did, because now you have this little framework to help you avoid a lot of wasted time and effort.

And if you want more tips on how to find the perfect SaaS idea, check this article here.

Idea Validation Playbook
Cezar Halmagean
Software development consultant with over a decade of experience in helping growing companies scale large Ruby on Rails applications. Has written about the process of building Ruby on Rails applications in RubyWeekly, SemaphoreCI, and Foundr.