Get Your Customers On Board – Continuous Feedback with Demos
Posted by Patroklos Papapetrou on May 14, 2011
Some simple rules and guidelines
Frequent demos for immediate feedback are extremely imporant and come to fill the gap between the development team (what is implemented) and end users (what they really want from the system).The fact that from the early stages of the project, the customer participate at regular intervals in such meetings, ensure that critical requirement changes and misunderstandings are identified as soon as possible. Thus the implementation cost is far lower than the scenario where the same change is “discovered” much later when the project would be in advance.As for each agile practice, however, frequent demos should follow some rules and guidelines in order to get the maximum of the. The following brief instructions are mainly focusing to projects where there is a single customer.
- Since the beginning of the project, therefore, describe in details the practice you intend to follow and try to explain its return of investment. Make clear that these demos have a single purpose. To understand early in the project what are the actual needs of end users and get as soon as possible feedback on the track you follow, so if something is extremely wrong you have adequate time to fix it.
- If there is some kind of dissatisfaction about the large number of releases, it is good to clarify that these are not real releases, but internal demos, which will be not available to all users. There are nevertheless valuable for the early diagnosis of requirements misunderstandings.
- Respect customers’ free time. Try to find an approach that will make everyone happy. If the customer can not attend a demo at the end of each iteration (for example every two or three weeks) try to make it at the end of each month. This, IMHO, is the maximum allowed period between two demos.
- Try to ensure that you really have to show something. New features, modified or redesigned screens are essential in a demo and should work with no problems. If the customer is frustrated by a non-working demo, then it is most likely that he loses confidence in the development team and distrusts any attempt for future meetings.
- The demo should be done only by development-team members so that he/she will show the customer features that need his/her attention and feedback. Do not let the customer “play” with the release. Politely remind him the purpose of this meeting and that the demo version of the system is not suitable yet for beta testing.
- Remember to make clear before each demo that the product/system is still under development and that this is NOT what the end users will get. Try to focus on core and critical business requirements so you can get important feedback, but this does not mean that you ignore proposals for the usability, the user interface, etc.
- Try to create videos that demonstrate the new feature of the upcoming release- several days before its official announcement. Something like a pre-release announcement.The main advantage of this approach is that with minimum cost, we can briefly show (the duration of the video should not exceed 2-3 minutes), the core features for that we would like to get feedback and comments from our customers, before the new version is actually released
- Try to provide a try-it-live demo site where customers (existing and potential) are allowed to test the new upcoming version (Beta versions, Release Candidate versions) and send with a predefined way comments and feedback.
- Try to gather some of the customers (if they are located in some or nearby places) or a webinar for long distance-customers and perform a demo session instead. Although this will not have the same results as if you would showing the product in a single customer, but you may get some important feedback.
- Early detection of misunderstood requirements.
- Correction of the project “path” at a very low cost.
- Continuous communication with the customer.
- Increase confidence between the development team and end users.
- Creative collaboration to achieve the same purpose (meaningful and working product)
- Most critical and core features are delivered first and complete without having to reach at the latest phases of the project.