Avoid The Traps in Demo Software Development
Convincing a prospect that a software solution is the answer to their productivity problems can be challenging indeed. If the proposed software is a new, custom-developed product, the conversation is almost entirely abstract. The inability to visualize the solution prevents the prospect from understanding the concept clearly. One seemingly obvious answer is to develop a prototype to demonstrate the proposed functionality.
A prototype can be invaluable whether selling a custom software development proposal to a business owner, or internally to corporate leadership or to investors to raise capital for a new venture. A ‘clickable’ prototype allows a prospect who struggles with abstract concepts to interact with and experience a conceptual solution. This can spark the imagination and often persuades them of the value of the proposed solution. Indeed, such demo prototypes are frequently used as powerful tools in converting a prospect into a paying customer.
Four comment errors can turn a persuasive demo prototype into an ugly duckling:
Rushing into development of a prototype as soon as you get an idea. You don’t want to miss the mark completely in your haste to close a deal. If the prospect is challenged with visualizing the solution, then presenting a demo that clearly misses their expectations can end the conversation abruptly. To convince the prospect that you understand the problem, take time to learn from the customer and any other stakeholders that will be influential in the process. If you are proposing to develop a software solution to a specific problem or business need, you must learn as much as you can to gain the confidence of the customer.
Overselling the completeness of the demo. Most software prototypes comprise an interactive user interface and simulated data. The risk is that the prospect may assume you have already developed most of the product they need. Meanwhile, the functionality is, by design, woefully incomplete and there is nothing behind the curtain to capture, manage, analyze, store and communicate information. Justifying the true cost of developing the actual solution can be severely compromised by expectations that are not set correctly.
Forgetting the true purpose of the demo is concept development and not product development. To keep development costs low, most demo prototypes are created using the simplest and least expensive technologies to allow functionality to be demonstrated in an interactive way. This usually results in throwaway code after the deal is signed. Developing a demo prototype that is too close to the actual product can be a costly and time-consuming affair. Use the demo to validate the concept and clarify the requirements for the actual solution.
Sticking to your own idea of the design and functionality of the solution. Even if you are proven largely correct, let the customer lead the process. If the customer has questions or statements starting with, “What if…?”, “Can we…?” or “I’d prefer…,” you are on the right track. Do not confuse these as challenges to your preconceived notion of the solution. Instead, it means that the customer is engaged with the concept and has begun analyzing their needs. Encourage this process and allow them to continue exploring without judging or denying any of their requests. The result will be a comprehensive set of requirements provided by the customer.
No matter how much your solution concept changes to meet these requirements, you will be developing a more optimal solution. The path to the best software solution must follow and overcome the twisty turns and obstacles presented by the customer.