How to Find Micro-SaaS Ideas: The EBIG Framework

Once upon a time, I was a slender, thin little software developer with no ideas, just like you. For real though, a few years ago, I was in search of the perfect software idea permanently.

I would constantly look at successful websites or apps and thought, "Technically, this is something I could've done too!". If you can identify with my past self, I'll teach you how to come up with ideas that actually will attract users.

EBIG stands for environment-based-idea-generation, and the gist behind this method is to ask people in your environment for problems that they have and work on a solution-draft together with them.

Because that's where most developers go wrong. It's not having an idea and then searching for people who have the appropriate problem. It's finding a niche audience that has a specific and painful problem, so you can build a perfectly tailored solution for that problem.

Starting a Conversation to Find Problems

You start out with people in your environment. You'll always have people in your environment that have problems. Make a list of friends and family and write the niches they work in or have hobbies in.

Now comes the hard part for us developers. I know this sounds awful, but it won't be, I promise: You have to talk to a few of those peoples about problems they have in their niche.

Also, there are companies that are too large to sell to without enterprise procurement (which you really don't want, trust me). My dad for example works at a really huge parcel delivery service, and they wouldn't buy or even consider anything that one person produced.

So, you choose the first person you want to talk with and schedule a call or hang out with them. In the conversation itself, ask them (casually, nothing formal please) what their pain points in their job/hobby are. Try to control the conversation in a way, so they tell you about problems that could be solved by technology.

You could start out by saying, "I can't really visualize how your typical work day looks like. Can you summarize for me?" - this way you can get a conversation about this topic started, and they'll tell you about their workday.

Extracting Problems From the Conversation

There is a good chance they'll tell you about some problems already. If they didn't mention specific problems, ask them, "when was the last time you had a painful problem [at work/with hobby X]?".

The important thing here is to understand the why. It's very hard actually to ask the correct questions here, but there is a very helpful book, it's called "The Mom Test" by Rob Fitzpatrick.

As a founder, you really absolutely must read this one, it'll save you a lot of trouble finding and especially validating ideas. Except if you are into building products for 9 months just to find out no one needs them. In this case, you are a masochist by definition, I am sorry you had to find out this way.

The super-short version of some questions you could ask: Let them explain

• why the problem is painful
• who is affected by the problem
• what happens if they wouldn't solve the problem
• what they currently do to solve the problem

If for the question "what happens if they wouldn't solve the problem" they respond something along the lines of "well, I'll just do it later" or "We'll have to file a document.", this problem is not suited! This response means that the problem is not painful enough.

If you ask them what they currently do, and they'll respond, "Well, I just invest the extra 15 minutes to do this monthly task", this is a clear sign that this product is not suited either.

I think you get the gist of what to look for. If not, the book linked above will teach you.

There is also the possibility they will point out how this old rusty software they use is so slow, has bad UX and could be so much better. Take notes! Try out the software if you can and build something better that targets the pain points they complained about. Be sure to check what requirements you'd need to fulfill before they or their company would use your software. In some industries, the requirements are way too high for a solo-dev.

Magic Button

Many people can't imagine what software is capable of and what not - this is where the magic button comes into play. It's a technique that poses a question in a way that opens up people to talk about problems, even if they don't seem particularly solvable for them.

Ask them, "If you had a magic button that, if pressed, would do a part of your work for you, which part of your work would that be?"

Their response will often be something that can be solved either with normal software or machine learning. It's so efficient because most people will not think software can help them with their work. Magic can, though. Additionally, magic sounds so absurd, the barrier to responding to you with a problem is much lower.

Requirements for a Successful Micro-SaaS Idea

When you have a list of problems that you think could be solvable with software, start vetting the list. The questions above should help you with that.

If you want to build a Micro-SaaS, be sure to check if your idea additionally fulfills these requirements:

Big Enough Market

The market should be big enough so that if you can capture 1-2% of it, you should be able to make a living off of it. Make sure there are enough potential customers or people searching for a solution to that problem.

Small Enough market

The market can also be too big, so make sure that it's small enough. If it's too big, you'll have to compete with bigger companies that have more budget for development and marketing than you.

Market Fit

You should make sure that your target audience are people that have enough money to pay you. They should be in a market that is growing or at least staying steady.

A bad market, for example, would be to serve the hobby-painter market. A good market, for example, would be to serve the professional-photographer market.

Drafting Solutions

After vetting the different problems, start drafting solutions for them together with your friend or family member that introduced you to the niche. This will be very individual depending on the type of problem.

After designing a first high-level draft of the solution, you have a person who can check if this is technically viable to build (you) and someone who can say if this would actually be useful (your friend / family member).

Example from My Life

I am writing this article because a few days ago, I was talking with my girlfriend's father about his job. He does general inspections for car safety, and he was complaining about how the appointment-scheduling and payment were really unorganized.

With some precise questions, I could find out all the details and what could be done better. For example, customers can only make appointments by calling. How cool would it be if you can use an interface similar to Calendly? See which dates / times are free and book something and pay online via PayPal, card or your favorite payment method.

At the moment calling is the only option + there is no payment possibility other than cash or normal bank transfer which can take days.

At the moment (mainly because of Minervabooks) I don't have the time for a new project, but I added it to my idea-list. Feel free to steal this one btw, I'd love to see someone succeed with this idea.