When you are a software developer wanting to sell your own software product, finding the problem to solve might sound easy, but in many instances, it really isn’t. Why do you need to understand the problem your application is solving? Well, because regardless of how well you code a product, no one will buy a solution to a problem that they do not have. However, simply knowing roughly what their problem is is not enough either because you might just turn your product into something that customers do not want. I will give you a few tools and frameworks to use in this blog so you can make sure that you develop a product that customers really want!
Make sure to also check out the video we made on this topic:
Finding the Problem to Solve
Let’s start off with an example. Let’s say that your prototype is an Excel add-in that checks for errors in an Excel document. Without looking too far into the problem, you might spend a lot of time developing a very advanced feature that gives a thorough description of why the error in a particular cell occurs. When you eventually begin to sell your product, you might be faced with rather depressing data. No one actually reads the advanced descriptions you worked so hard to code. Why is that? We’ll come to that part in the story a bit later, but the root cause is that you did not understand the problem early enough.
So how do you avoid ending up in a situation like that? Well, I would suggest using a simple framework called “The Problem Statement Framework”, because it forces you to clearly focus on a singular problem and helps you to put yourself in the customer’s shoes. The framework consists of 4 steps, and the output of this framework is usually a short paragraph that clearly states The Problem, Target Audience, Impact, and Success Criteria.
For our previous example, the paragraph would be as follows: “Advanced Excel users spend too much time fixing errors in their documents. This affects Excel users with big documents because the errors can then get out of hand. As a result, they waste hours each week on correcting errors. A successful solution would enable the user to solve the errors in just a few seconds.” Let’s now dig a bit deeper into each one of the steps together!
1. Fidning the Problem
The first step to finding the problem to solve relates to the problem itself. It is important to find the root cause of the issue. A handy method to make sure of that is to keep asking the question “why”. It looks something like this: Why do Excel users waste so much time? Because they have many errors to solve. Why do they have many errors to solve? Because they have big documents and do not check for typos. Why do they not check for typos? Because they create the documents under time pressure. You get the idea. So the underlying problem is then that advanced Excel users spend too much time fixing errors in their documents!
2. Finding the Target Audience
The next step is figuring out the target audience. This can be done by asking “Who is affected the most by this problem?” For us, Excel users who are under time pressure and create big documents are likely to get the most errors, and they would also highly value an add-in that can save them some of their precious time.
3. Finding the Impact
Now actually, that just so happens to be the next step in the framework – the impact. After digging a bit deeper into the problem, we know that the errors themselves are not necessarily the biggest pain point for our future customers, but rather, it is the time it takes to fix them that is the impact. We have now come a long way to finding the problem to solve!
4. Finding the Success Criteria
The last step in the framework is to find what success would mean to these time-pressured Excel users. The success criteria is most likely a rather simple add-in that gives an overview of the errors and a quick button to fix them. As we have now found, time is indeed the root cause of the problem. Can that be the reason why our customers did not use our advanced descriptions feature that I mentioned earlier? It definitely could be, because they probably do not want to waste any time reading a long description, they just want to solve the error and move on to the next document.
My Personal Tips when Finding the Problem to Solve
Now that you know about the framework, I want to share some tips on what I would do next. I would first look at available data to make sure that the problem is there, and then I would define how a successful product would improve that data. Using our Excel add-in, I would try to find data regarding how much time an average person in my target audience wastes on checking errors. I would then try to estimate how much quicker my product should be able to make the error-checking process, but crucially, I would also try to turn that time into money.
For example, imagine being able to tell your future customers: “My addin can help you save thousands of dollars each year by reducing the time spent checking Excel errors”. Now that can be the foundation of a pretty good sales pitch. If you instead find that fixing your unique problem can only save an average company a few pennies, the problem might not be worth solving at all. I now hope that you know more about how to create a product that customers really want. Please feel free to read some other blogs we have on the topic of launching and scaling a software startup. The process is not easy, but together, we can make it a bit more effortless.
We at Cryptolens are dedicated to helping software developers license and sell their software applications. Previously, we have covered how to choose the best pricing model for your application, and how to create interactive software demos to put on your website. Our easy-to-use software licensing system is also a crucial part of selling any type of software application.
Thank you for reading, Stay Humble!