During our release meeting, we strive to have clear context and real-world use case explanation and demonstration so as to maximize understanding and real world application of each feature request.  The following guidance for the presentations has been developed and will be used by the Technical Team members to aid in the presentation preparation and execution.

The presentation should be developed with the presentation’s purpose and audience in mind.  The audience will include sales personnel, marketing personnel, implementation project managers, support personnel, management personnel, tech team personnel, accounting and administrative support personnel.  Some of the personnel in each of these roles may be quite experienced with FullCount and some may be quite new and inexperienced with FullCount.

The purposes of presenting the changes being released include…

1. Supplement, and elaborate upon, the release notes that will subsequently be distributed.
2. Provide sales personnel with knowledge of new or changing features so that they are able to more effectively communicate business value to prospects and current customers with whom they are interacting.
3. Provide marketing personnel with knowledge of new or changing features so that they are able to identify opportunities to more effectively communicate business value to individuals within FullCount’s target market.  
4. Provide implementation project managers with knowledge of new or changing features so that they are equipped to understand when and how to leverage it in order that FullCount delivers the maximum benefit to the community.
5. Provide support personnel with knowledge of new or changing features so that they are able to quickly recognize and react to any fall-out from the implementation, efficiently assist customers in leveraging the features where appropriate, and identify newsletter, help/KB article, etc content add/change opportunities.
6. Provide accounting and administrative personnel an opportunity to better understand the product that we provide to our customers and to understand any accounting ramifications related to changes being made.
7. Provide tech team personnel with knowledge about changes being made in order to potentially spark other ideas to improve our product.
8. Provide management personnel with knowledge about changes being made in order to enable them to better support their team in performing their functions.
9. Give us all an opportunity to recognize and celebrate and feel proud about the continual progress being made on our product!!!

Practical tips and tricks to better fulfill these purposes include…

1. Requestor to be more thorough about documenting core and ancillary use-cases and business value in Redmine.
2. Triage, Product Review Board, and assigned Tech Team Member(s) all elaborating upon, as necessary, the Redmine documentation of use-cases and business value.
3. Release meeting presenter to review Redmine documentation thoroughly and prepare demonstration setup and plan in accordance to the use-cases, business value, and purposes of the presentation.
   1. Instead of impractical descriptions/names of things such as “Darwin’s Test Plan” or “sdlfkjsdf”, use more real-world examples such as “$400/Month Plan” and “Blue Cheese”.
   2. As part of the presentation, attempt to answer questions such as…
      1. What all sparked this request? (examples: During Kam’s recent implementation of community XYZ, he noticed that they were struggling with bla, bla, bla and he had the idea that we should bla, bla, bla.  We believe that many communities would enjoy this in addition to community XYZ because…)
      2. What stakeholders are affected by this and how? (examples: residents can have allowance plans that provide them more flexibility in terms of what they use their allowance for; wait staff are less likely to select the wrong customer; FC implementation/support personnel are able to more quickly build the modifiers for a modifier group; sales and marketing personnel have another bow in their quiver to spark interest in buying (or buying more of) FullCount.
      3. Does this feature have any effect on pricing? (example: this new scheduled reports feature is going to be free for the first 5 reports per community and then each additional block of 5 reports will be $25/month)

Other notes…
1.    We can’t take all of this too far as we will continue to have a limited amount of time during the release meeting.  So each change/feature’s presentation needs to fit within the overall agenda of the meeting’s allotted time.
2.    Marketing and Sales content changes/additions, Support documentation changes/additions, Newsletter content changes/additions, etc. can be touched upon during the release meeting, but extensive planning of these things are outside of the scope of this meeting.
3.    Solution design and/or prioritization questions/feedback/critique should be addressed directly to the Director of Product Development outside of the release meeting.
4.    Roll-out/implementation plan questions and concerns are appropriate to discuss during the release meeting.  For example: Brett might pipe up and ask… what about the communities who have “auto press OK when seats are full” turned on, should we contact them ahead of the release to give them a heads up?
5.    Audience participation supporting the purposes of the meeting is welcome to the extent that time allows.  For example:  Kyle might pipe up and say… this would also be good for Community X and others like them because bla, bla, bla.