Market Research and Product demand

[Drchainsaw]

Hello Everyone,

This is my first post on here. I've been busy away working on my startup for about a month now. I decided to take a problem from my industry(software development) and tackle fixing it . Source control has been a relative annoyance to most developers and newcomers to the industry for as long as I've been programming myself. So I have been working on a solution to completely overhaul the entire thing and make it user focused and push towards a more simplified solution for beginners and small to mid sized teams.

Unfortunately im on my 3rd or so rewrite of the software and I've hit a bit of a wall , I've started questioning whether or not the market has a real demand for my product or its just something I myself could benefit from , So i started to do some keyword lookups, research on reddit and the numbers are not really looking in my favor, on top of this my competitors are freeware , so I need to convince users to use my software over paying nothing ( once the software is complete i have no doubt that this can be achieved if the average user has my grievances and want a solution in the first place).
I guess my question is what are some good ways to prove to myself that this project is worth the many years of labor that will be inevitable to complete it ( to other people as-well). I really believe that my software can make an impact on any industry that needs versioning for files?

 

Dislike ads? Remove them and support the forum: Subscribe to Fastlane Insiders.

[Jobless]

Find at least one potential customer willing to cooperate, and provide them the earliest working version of the software. Then let them provide you feedback as you develop. Your perception of the problems will probably differ slightly from theirs, which is why it should not be developed in a vacuum. If you cannot find anyone willing to cooperate in exchange for free software and future updates, maybe the magnitude of the need truly is too small.

Since you currently doubt the viability of the project, it is not a good idea to look for confirmation and 'prove anything to yourself'. Ideas are not 100% useful or useless, the execution is far more important. Study the freeware competition and the potential market for 'weaknesses' you can exploit. Create a feedback loop where you execute great development / marketing, and in return gain more interest/traction for the product.

Set a deadline / goal as measured in paying users or revenue, that if not met, will mean you shift focus to something else. Possibly, even if you are forced to shift focus, you will have learned something new during the process that will benefit you.

If its going to take you years to make a working alpha version of the software, my advice is that you question the scope of the project, alternatively that you give it up.

 

[Drchainsaw]

Find at least one potential customer willing to cooperate, and provide them the earliest working version of the software. Then let them provide you feedback as you develop. Your perception of the problems will probably differ slightly from theirs, which is why it should not be developed in a vacuum. If you cannot find anyone willing to cooperate in exchange for free software and future updates, maybe the magnitude of the need truly is too small.

Since you currently doubt the viability of the project, it is not a good idea to look for confirmation and 'prove anything to yourself'. Ideas are not 100% useful or useless, the execution is far more important. Study the freeware competition and the potential market for 'weaknesses' you can exploit. Create a feedback loop where you execute great development / marketing, and in return gain more interest/traction for the product.

Set a deadline / goal as measured in paying users or revenue, that if not met, will mean you shift focus to something else. Possibly, even if you are forced to shift focus, you will have learned something new during the process that will benefit you.

If its going to take you years to make a working alpha version of the software, my advice is that you question the scope of the project, alternatively that you give it up.

Thank you very much for your perspective on this, i will be looking for a potential customer in some programming circles. and ill be reviewing the scope of the project and making sure to take just the important aspects .

 

[Drchainsaw]

Thank you very much for your perspective on this, i will be looking for a potential customer in some programming circles. and ill be reviewing the scope of the project and making sure to take just the important aspects .

Update , ive been doing some searching around and some querying and i havent realy gotten the reaction i expected from the market, most people seem to not realy be excited about the solution. Im going to keep at it a bit longer and do some more research but im starting to think my thoughts on the viability of this project were probably false.

 

Dislike ads? Remove them and support the forum: Subscribe to Fastlane Insiders.

[jobroz]

Update , ive been doing some searching around and some querying and i havent realy gotten the reaction i expected from the market, most people seem to not realy be excited about the solution. Im going to keep at it a bit longer and do some more research but im starting to think my thoughts on the viability of this project were probably false.

Hey, it's been awhile since your last update and I've just newly joined this forum. But I stumbled across your post and thought I'd share some 2 cents since I've went through the gamut of trying niches out before for ventures years back, before finding niches with paying clients involved.

I think a lot of builders, for instance developers like yourself, see a problem out there in the market and then get really excited about building the solution for it. Coming from a tech/engineering background myself, I get that it's exiciting BUT feels draining when it seems like no one gets the solution and there seems to be no demand for the solution.

What I've found to work more effectively is to get into the groove of speaking to lots of people - especially stakeholders of the problem you've identified. The key here is to confirm real demand for a solution before actually going all-out and building it.

You can do this via surveys, email outreach, conversations, etc. with the stakeholders you've identified. Personally, I very much prefer money in the bank as validation that the problem is real and that people will actually PAY MONEY for the solution. This is currently how I've done things for my coffee-masterclass business, in the sense that I get generate leads and get them to pay me first (to book their classes) before I went to create the materials and organise things proper. I scheduled the class date 3-4 weeks in advance so that if no one booked, that was fine, but if people started paying me I had a buffer period of those weeks to prepare all the materials and content etc.

Hope this helps.

tldr- validate demand first, ideally get people PAYING you first for early-access to your solution, and then go all out to build the solution. Don't reverse the order.

 

[miguelst]

Hey, it's been awhile since your last update and I've just newly joined this forum. But I stumbled across your post and thought I'd share some 2 cents since I've went through the gamut of trying niches out before for ventures years back, before finding niches with paying clients involved.

I think a lot of builders, for instance developers like yourself, see a problem out there in the market and then get really excited about building the solution for it. Coming from a tech/engineering background myself, I get that it's exiciting BUT feels draining when it seems like no one gets the solution and there seems to be no demand for the solution.

What I've found to work more effectively is to get into the groove of speaking to lots of people - especially stakeholders of the problem you've identified. The key here is to confirm real demand for a solution before actually going all-out and building it.

You can do this via surveys, email outreach, conversations, etc. with the stakeholders you've identified. Personally, I very much prefer money in the bank as validation that the problem is real and that people will actually PAY MONEY for the solution. This is currently how I've done things for my coffee-masterclass business, in the sense that I get generate leads and get them to pay me first (to book their classes) before I went to create the materials and organise things proper. I scheduled the class date 3-4 weeks in advance so that if no one booked, that was fine, but if people started paying me I had a buffer period of those weeks to prepare all the materials and content etc.

Hope this helps.

tldr- validate demand first, ideally get people PAYING you first for early-access to your solution, and then go all out to build the solution. Don't reverse the order.

Thanks for this post, I've been thinking about building a landing page first to gauge interest and even receive payment, but for software, the cycle is longer, so if I start getting leads or paying clients, it could take months before an MVP is released. How would you tackle this for software, instead of a course?