It's rather common, especially with side projects, that we start programming software by solving a pain that we have ourselves. While this can help build insanely profitable and successful companies (like Slack), you also have to be very careful that you're not solving a pain that no one else has.

Do you even want to solve other peoples pain?

Before we dive into building a serious product that solves your own pain, let's talk about solving your own pain for the heck of it.

Sometimes, hackers gotta hack, and problem solvers gotta solve their own problems. It is absolutely okay to build a side project with no desire to monetize it or even have people other than yourselves use it.

This type of project is actually the best possible option when you want to learn a new technology.

You don't have any requirements or pressure on shipping things super fast, you don't have to listen to feedback other than your own, so why not take your time and learn a new piece of technology!

However, if you do want to build a serious software product that other people will pay you for, I find that there are a few main questions that you must ask yourself.

Do other people feel this pain?

The number one thing you have to figure out is whether or not other people are feeling the same pain that you are. I'm going to pull a few examples from some side projects I've worked on in the past:

Building remote collaboration tools for developers programming live on servers

Very very early in my career (don't judge what you're about to read), I was a rather novice and renegade developer. My primary method of programming was booting up a LAMP stack server and programming live on the server. No source control, and everything was tested live in production.

Once I started working with another developer (who had the same mentality), we found that collaborating on our software was rather difficult. We'd overwrite eachothers changes, we'd break parts of code so that the other person couldn't work anymore, etc.

I'd love to say that we stopped working on the server and started working locally utilizing source control like Git. Instead, we built one of the first realtime online collaborative code editors ... that connected directly to your server.

We launched to over 2000 pre-signups, and got roughly 0 longterm users of the product. It turns out very few serious developers programmed in the completely unreasonable way that we programmed at the time. Meanwhile, a competitor who had a much better philosophy than ours (only focusing on being an online IDE) added realtime editing to their platform and subsequently destroyed us.

If we'd done even a small amount of research or validation (besides pre-signups) in advance, we would have discovered that what people really gravitated towards was our realtime collaborative editing, and not our on-server functionality. In this case, we should have interviewed several other developers we knew in advance to determine if they'd use our solution to the collaboration problem the way we were going to build it, before actually building it.

Making morning routines with kids easier on parents

My daughter (who has ADHD) has a very hard time with her morning routines. We constantly need to keep her on track, repeat ourselves, and guide her to the next step in her routine, especially before her medication fully kicks in.

In order to solve this pain, I did two things much differently then above:

• I built an extremely small prototype that my children could use in a matter of days, wasting no time.
• Instead of adding more features, I began researching the problems that other people faced with their morning routines with children and how they solved them (I even asked ChatGPT for advice, which led me to more research).

If I had found no results of other people trying to solve this pain, I would have stayed at my small prototype state and not gone any further. However, there is A LOT of content online, especially surrounding childhood ADHD, on how to create effective routines for children and keep them on task.

Many people use rewards, gamification, checklists, visual lists, and more. So I came up with an initial feature set that I'd like to build, and continued to test it with my children.

kangaroutine was born, and I'm currently working closely with several friends who have young children to continue to build out an initial featureset alongside immediate customer usage to determine if I'm going in the right direction.

Not only does this help make sure I build a product that works for other people, but it also helps give me new ideas on what to build next to make the best product that I can.

We'll go over tools and techniques on how to validate ideas in later blog posts, but the important thing is you don't build the product alone in a vacuum. You have to work with potential customers early and often in order to make sure you don't build something that no one uses.

Are you solving a one time pain, or a recurring pain?

In order to build a succesful product with a recurring revenue business model (a monthly or yearly cost), you have to build something that users get value from every month.

Another side project I'm working on is a simple app that helps board game and miniature game players find local groups and events that they can participate in. While many gamers that are having a hard time finding local groups might find this valuable, the biggest question I need to answer before dedicating any more time to the idea is:

Will someone continue to use the application to find new events or groups after they've already found one group they wind up participating in frequently?

If I solve someones pain, and then they no longer have that pain at all, there is no way to build a large monthly userbase or membership as the product will have constant churn.

The best products continue to solve a users pain that they feel frequently, not just once.

Are you solving a "Hospital Pain" or a "Tylenol Pain"?

The severity of the pain is also important when you're going to charge for your product. I like to think about different pain levels when I'm building something new.

Would a simple pill of tylenol solve this pain? If so, it probably isn't strong enough for someone to pay for. Does the user feel like they need to go to the hospital if they don't solve this pain? That's a good bet!

While chances are your product isn't in the healthcare industry solving for hospital incidents, that pain can still be very strong in an emotional way or in something that takes a lot of time for your users without your product.

Ensure that your product isn't just solving something small and painless, and is instead focused on solving a major pain.

I talked about my favorite question that can help you find out if the pain you are solving is large enough in a previous post that you should definitely read as well if you are looking to build a serious pain-solving product.

Until next time,