I’m sure most programmers out there have their own ideas, their own projects. I know I do. For years now, I have a dream – my own company, my own employees, and earning my life with my own projects.
There has always been one problem though. I never had enough capital to even start that dream. Add to that the mental cost of spending most of your time programming, the problem becomes two fold. I never had enough capital AND enough energy to do so.
I still don’t. But I have to start at some point. Otherwise, this dream will never come true. If you have an idea, any idea, start now. Otherwise, your dream will always stay a dream.
I had to do something. This itch eventually became so unbearable that I had to act.
But then, I had multiple ideas. Which one to do? How to decide?
Throughout the years, I have seen multiple project plans, action plans, selection matrices, swot analyses.
But being a little nonconformist, I always preferred doing things my own way. So I came up with something different that I understand better.
I came up with a list of questions for each project, each one affecting the decision a little less than the previous one. I answered these questions for all my ideas and decided the project I will start working on.
- Does it really solve a problem?
- What is the potential monthly revenue?
- What is the potential market size?
- How quickly can we take it to market?
- How saturated is the market?
- How much effort would each customer require?
- How easy is it technically?
- What is the expected monthly cost?
Does it really solve a problem?
The first question is a different version of “is it a medicine or a vitamin”. This is a crucial question because it literally decides your marketing efforts.
I believe it is much easier to sell a medicine than a vitamin. A product that solves a problem is much easier to market than a product that just causes temporary joy.
I would consider creating a vitamin only after I have built all the medicines in my mind.
What is the potential monthly revenue?
Next comes the revenue expectation. This is the limiting factor that decides how much you can spend on the project and when.
If the project needs a lot of upfront spending with little potential revenue 2 years later, you can safely say goodbye to that idea. If it will earn a lot of money after 6 months of grinding, you can safely move that idea upwards. Remember, we won’t know the actual revenue until months after we start selling. So we have to be very careful and realistic with this.
What is the potential market size?
I know, market size is a hard topic. You could either be optimistic or pessimistic about it, and the difference between the two would be like night and day. But this is a decision point that defines how much you will have to charge for it.
You may be solving a small problem for cheap for thousand of people, or solving a big problem for a few companies that pay a lot. Are you selling to individuals, or companies? At the very least, you should be keenly aware that selling to companies is a lot harder than selling to individuals, but also much more lucrative.
And comparing “how much you have to charge” to “how much you can charge” is what makes or breaks a product. At least for people like me, who has no practical access to capital.
So -obviously- choose the product with the bigger potential market size when choosing between two.
How quickly can we take it to market?
Since I (you?) don’t have much capital except your sleepless nights, you must be as quick as possible to create a somewhat usable product. It doesn’t have to be perfect, it just has to be working correctly.
I see a lot of people thinking about the colors, the sentences (the technical term is “copy” I think), the placement of buttons; and spending hours and days on these.
Yes, these are important, but not as important as the problem your product solves. You may spend countless hours in meetings thinking about how to say something on the users’ panel, but your users will not care what is says, only what it does. If you are solving their problem, they don’t care what the title says. That is, until your product is mature enough that every feature you add only affects %.1 of your users.
When deciding between two projects, choose the one with the quickest path the phase 1 (a useful product).
How saturated is the market?
While market size defines the total size of your balloon, market saturation defines how much air you can get out it.
If you have ever seen a product grow from zero to one, you know it is not easy entering a saturated market. Most such projects start with competitive pricing to steal some customers, and then get stuck with those customers for the rest of the product’s life.
So, comparing two projects, the less market saturation, the better.
How much effort would each customer require?
This mainly depends on if your product is for companies or for individuals. Also, if it is for companies, are you targeting big companies or SMBs.
For me, this includes acquisition time and support time. The amount of effort should be at least as low as the amount of revenue you get out of that user.
If you are targeting individuals, the amount of effort to acquire and keep a customer should be as low as possible. If you are targeting small companies, your prices will have to be on the low end, so it should be easy to onboard those companies. If you are targeting bigger companies, it will take a lot of time to acquire and support them, and your revenue must reflect that.
Let me give you some examples, and it should become clear. Let’s say your customers are all individuals and you have only one support personnel, costing you 5000 dollars a month. All they do, all day and every day, is support your customers. A scenario where you earn 50 thousand dollars a month would be preferable to one that you earn 10 thousand dollars.
SAAS businesses targeting individuals should be especially preferable for this. As long as you have an intuitive interface and enough documentation, your users will rarely need your help and that is a very good thing.
Basically, the lower effort the better.
How easy is it technically?
This is a complicated issue since each phase of a product has different needs.
In its infancy, a product needs to deliver only one or two features, which (should) make it easy to implement and simple to manage.
In its youth, it will need to add more features, both domain-specific features regarding the problem it solves and non-domain features like logging, billing, notifications, and more.
When it is mature, it will need to have many more domain-specific features and an advanced management panel for oh-so-many needs of the product.
Domain-specific features should be as easy to implement as possible.
Think of it like this: A product that solves a boring problem with 100 lines of code is much more preferable than a never-before-seen product with 10 million lines of code. The first one is much easier to implement and keep running.
What is the expected monthly cost?
The monthly cost of a product, taken into consideration alongside monthly recurring revenue, is the most basic indicator of how profitable it really is.
We could go with fancy calculations and deep explainations about this but I think the basic logic should be easily understandable by everybody: Your revenue should justify your costs.
Think of these two cases:
- You have spent 100 thousand dollars total and you are spending 5 thousand dollars a month to keep your company running but earning 20 thousand dollars a month. It has begun running practically on its own without much effort on your side and no extra personnel.
- You have spent 1 million dollars total and you are spending 50 thousand dollars a month but earning 100 thousand a month. It needs constant supervision, and you are actively working full time on this project with a full team of people.
Putting aside the fact that I’m a solo developer and have practically no leeway, I would go with the first one before moving on to the second one. I don’t of course have a project fitting the second scenario, but you get the idea.
Conclusion
You will notice that the questions I ask myself when considering a project (or comparing projects for that matter) are centered around two aspects: profit, and market.
Since I’m a technical person (from app coding to server management), I already possess the expertise to handle all the technical things, and I learned that profit is what keeps a company afloat and market (not marketing) is what determined the size of your pool.
There are all these canvases and matrices designed to help you organize your idea or project. You could find 10 different canvases with a quick search. They give you boxes with predetermined sizes to fill. I don’t like that. They force me to think a certain way, putting positives and negatives on different boxes. I don’t like that either.
I prefer a free canvas -like that of a painting- where I can think freely and focus on whatever I want. That is why I came up with these questions.
I will soon write up about my current project and compare it with another one, showing you a practical use of these questions.