How To Know Your Software Will Be A Hit? (Before You Write The First Line Of Code)

A lot of products, software included, fail to gain acceptance in the market, or user acceptance. If you want to learn a secret to make your software successful, read on.

A lot of products, software included, fail to gain acceptance in the market, or user acceptance. If you want to learn a secret to make your software successful, read on.

With most products, you need to really build it (like a car) so that people can test it. And the cost to go from prototype to concept is high. But with software, it exactly the opposite. The cost to prototype is the same as the cost to develop. That is, once you have a prototype with a software project, it can actually provide benefits that people will pay for – even though the application does very little.

So the cost to prototype can be zero, or even generate cash flow. In fact, many mocked-up software projects have generated enough revenue to go from no-cost demos to profit. SalesForce.com is a great example. It was open-source and free to start. Over time, customers wanted to pay for premium features. These customers were willing to pay to have the software developed further. So the company started generating review by letting customers pay for enhancements. Get this … the customers paid the company to develop features to resell to other customers. … some if whom paid for further development. And a virtuous cycle began.

And that’s the first way to know your software will be successful, make something and see if customers will pay for upgrades.

Even before that, there are ways to get customers to help you before you write any code. With free online mock-up tools like https://moqups.com/, a company can mock-up an app, or website. Once done, these interactive mock-ups let users try the software before any code is written.

Know as Model Driven Development, what you are doing is making the Model (the layouts, transitions and views). User can interact with this live, but faked, application. Users can suggest changes, all without any code.

If you’ve got a hit, then it’s time to make your version 1.0.

There are lot of ways to prototype an application and pre-test it. If the design does not fit well into a wireframe tool (as suggested above) all is not lost.

Some tools like http://cukes.info allow users to write behavioural based mock-ups. Which can then be turned into live code. BDD or Behavioural Driven Development asks a series of question, rendered into paragraphs, then code.

If each paragraph is right, the whole application will fulfil the expected user experience. It’s kind of like writing a story of the software or website from the users point of view. And after all, it users that determine the success of a website or app. If this sounds too high-tech, consider 3 by 5 cards. This is the old school method. On each card, you just make a small mock-up of the screen and give each screen a number. Any link, list the card number as the target of the link.

SalesForce was open-source and free to start. Over time, customers wanted to pay for premium features. These customers were willing to pay to have the software developed further.

Invite some users over to “run” your app from a deck of cards. Make sure you have lots of blank cards so user can make alternate cards and suggestions of alternate cards. If you do this right, you can get a good feel of how your application is going to be perceived in the market.

So before you write a line of code, consider making a mock-up, behaviour cards or story cards to pre-test your application.

An example comes from the boardgame industry. Among people who like boardgames, new games are made using coins and paper money until the game play is worked out. It’s not just the rules that are important. It’s the game play (in the industry called game-mechanics) – or how the game works. Once people are having fun, only then is it time to print the real game tokens. Play testing allows the designers to make sure the game is fun, and will get buy-in. Boardgames are literally sold by gamers trying, and playing the game with friends, who want their own copy to play with their friends.

So use any method you can to get people “playing” with your software before it’s written. Thinking this way will save you time, effort and the paid of massive rewrites.