5 Simple Secrets to Creating Successful Software Application that Exceeds Customer’s Expectations

We all have worked on different aspects of software applications. Some are big hits and others are not so successful. We all want ours to be the killer software application people love to use and talk about. How do you build successful software application one after other? Do you have to kiss a lot of frogs, or stage an American Idol for applications? Not really, the secrets are very simple. When practiced every time they will help you create successful software application that exceeds your customer’s expectations.


Let me tell you the 5 simple secrets to creating killer software applications, and here they are:


We all have heard it many times, “It’s a very small project and everyone knows what needs to be done”, or “We don’t have time to write things down; we need to get it out tomorrow!” One might as well say, “We are just going to start programming and eventually we will create something we can use.” This is risky, to say the least. Unless you can describe what your software application will do in plain English (or Spanish, French, German, Italian, or any other human language), then how can your programmers be expected to “say it” in Java, C++, C# or VB?

You don’t need to have a complete software specification before getting started with development. You should create a major portion of your specification before development begins. This is critical. You cannot rely on word of mouth and informal communication entirely. Even if you have a complete team of internal engineers, your product specification should not exist as rich folklore passed on as part of a grand oral tradition amongst members of the team. This is especially true when using an outsourced team. In fact, a good outsource firm will help you with the design process to ensure it is complete and ready for development.
Risks involved if you don’t follow this step: Each day not spent creating specification early on may cost you at least 15 days delay in development in average 6-month project.


The “requirements” for your software application are usually such a long list, that it will be a never-ending process to create it. The solution is to schedule baby-steps releases of the application, each with an increasing number of features. The first release should contain basic enough functionality to provide value to the customer. Regular releases can be scheduled every week, every two weeks, or monthly up to 12 to 18 months out from the first release. This provides engineering team with consistent workload and helpful feedback early on.

Risks involved if you don’t follow this step: Last minute surprises like integration issues with other systems, frequent rollbacks, and failure to meet deadlines.


Not just in mind, develop with customer physically sitting next to you. Show them tangibles and spell out the intangibles. Do it early in the development process and do it frequently. It gives your customer a chance to get their hands dirty, understand the technology and become your advocate in the process. It also helps smoothen the change management process when the scope creeps, since they understand your “language”.
Risks involved if you don’t follow this step: Communication gaps, less attention to details, loss of rapport with customer that may affect your quality and schedule.


When you have a stable release of the application, ask customer’s top executive to give it a try. Your engineering team sure can find anomalies, but executives tell you the lifesavers. Do it soon and do it often. It builds value, removes risks, and it makes the executive feel good about hiring you. Just like a picture is worth a thousand words, using the application still under development beats reading weekly status report.
Risks involved if you don’t follow this step: Missing “WOW” factor, reduced overall utility and lack of bird’s eye view (reporting) of the application.


Ask everyone who will use this application to accept it, unless there are hundreds or thousands of users. Have your funniest and knowledgeable engineer do the formal acceptance and training session preferably in the morning. Set user expectations well in advance about the time it will take. Ask everyone to come prepared with data, scenarios, and/or information from the field. Provide them with notepads, pens and food. Make sure everyone gets a working set of chair, machine, and login etc. Pay attention to what users are saying, alleviate their fears, and answer all their questions with a lot of TLC. They will be your first line of defense against resistance for a change. If they discover issues (not bugs) with how they interact with the new application, do some handholding. Ask how they would like to change it and promise to suggest it to customer.

Risks involved if you don’t follow this step: Resistance to new approach, longer transition requiring support for both old and new applications, missed quick ROI opportunity.


Software application design and development is part science and part art. If you master both the technical as well as the human aspect, your applications will become killer applications that everyone raves about.