A question I am often asked is what process I use to come up with software ideas. It is actually not as difficult as you might think. There are a few masterful moments of brilliance that occur in the software industry. Once in a while you will come across an idea so out of the box and so brilliant that you just say “WOW”! But for the other 98% of the time software creation is merely solving a problem, speeding up a task, or automating a task.
Most software that is created is a solution to a need they have in their own business. Once they realize how much time they saved or money is generated from the software they create they then are able to present it to the public for sale.
How can you do this yourself?
1- Think about a process that manually takes about an hour to accomplish that software could do in 10 minutes. – The answer to that problem will put you on the right track
2 – Always consider “Minimum Viable Product” – What is the least amount of features you need in the product to make it “viable” or functional enough to do it’s job. Every software out there could be better. It could have more features. Just as many users that a software has it will have that same amount of requests for upgrades and additional feature options. Software is never “perfect” for all users, but it can and must be viable. That is what you need to consider. You can spend too much money developing all of the bells and switches and interfaces needed to make everyone happy. But when you start out it only needs to be functional to go live… and build from there.
Casey Super Tip: Money loves speed, but so does development. Get the minimum viable product out into the marketplace as fast as you can.
3- Price the product – Start with a lower price and increase as you add more features. Don’t delay the launch because of wondering where to start the price. Overthinking this step can stop you from doing anything. Fear sets in that you might price it too high and not make a sale or price it too low and leave money on the table. Price it on value and the result that people get from using the product or the time it saves. If you don’t have test market results for your product then you have to do a beta first.
Pricing options to consider – start at a lower price then raise the price or make it an annual renewal
How do you know if your idea is good enough?
It should be based upon a pain point that someone is expressing or that you have. Survey your customers or friends. If it fills a need you have probably someone else has the same need. Does it speed up or automate a task?
4- The Idea Process – Start with a Google document for best interaction between collaborators. It will help you flush out ideas. You can share the doc with other thought leaders you trust or your team. Save yourself time by coming up with a “flow” concept in mind before your designers start. It will save you a ton of money.
5- Learn user interface – Look at other software you already have to get an idea of flow. You don’t have to a coder genius. Show your developers other examples you like and decide on a flow. Is the interface intuitive enough that you won’t need a 75-page manual to explain it. Can the concept be understood fairly quickly with a fast quick-start video and easy to understand labeling of the user screen? This is where the google doc comes back in. Be very detailed on the document you create. over-share. State on the shared document in terms of “I want this feature to do this… this is the benefit of the feature.” You will also want the coder to understand “why” you are creating the feature and the benefit to the audience and end user. If they don’t understand it they won’t get the logic in the first place.
6- Find a developer – Use UpWork or other freelance sites that make it easy for you to post a quick job.
What to look for in a developer?
a. Communication – Can the developer clearly communicate to you in your native language.
b. Test them by asking them questions – If you could build anything what would it be? See how creative they are. Do they possess out of the box thinking?
c. Don’t hire full time — Hire them on one job to test them. See how they communicate to you. Have them work on the minimum viable products. Before you commit to paying them for the full project have them build a few feature sets. Pay them a flat rate, not by the hour. By-the-hour payments can become a runaway train for a developer with limited skills. Tell them your expectations. Let them know you will hire for more of the job, but you want them to see how you fit together as a team. An example might be 3 weeks $1000 and we will evaluate your speed and skill level before we move forward.
d. Have them sign an NDA – A carefully written Non-Disclosure Agreement can protect you so they don’t go using your software and sell it for themselves.
e. Hire slow – fire fast. If you are cautious during this step you don’t have to make course corrections that can tarnish your reputation or cost you more money
f. MVP = $35,000 – Be ready to drop around $30,000 to $40,000 for a minimum viable product. You can save money by putting your software on the market as an MVP then turning some of that cash back into further development.