I am facing very similar challenges and it's still work in progress, but here are few suggestions:
When, what and how to release:
In principal you should release incrementally either “smaller user stories” or “Epics” but more focus should be given to smaller stories that have bigger impact. In my opinion big bang releases misses a lot of opportunities where you could engage with your users and inform them of where things are heading.
How to best communicate releases
In-app messages VS Emails:
Establish a clear distinction between release messages and other in-app messages in way that attracts attention to enhancements and features. Compared to emails this has a clear advantage as the information is delivered in context along with any visual emphasis you wish to include.
Emails could be delivered in conjunction with above along with other communication material to enhance improve corporate image. So using email here has a much larger scope and should be treated accordingly. For example email would be better at communicating end goals with the caveat of course of not over promising and under delivering:)
When to communicate:
Consider current pain points in your user journey as a guide; when you have developed a feature or a functionality that solves a problem or enhances a frequently used but broken process there is enough reasons to celebrate it using both in app and email channels.
In line with the above, user stories in conjunction with kano model should give you an indication of the level of frustration encountered and the problem solved so you can decide weather it deserves to be communicated if at all, below is my take:
No communication required as these features are typically cosmetic and minor changes that will generaly go unnoticed. According to the Kano model these enhancements are an generally an:
These attributes provide satisfaction when achieved fully, but do not
cause dissatisfaction when not fulfilled. These are attributes that
are not normally expected, For example, a thermometer on a package of
milk showing the temperature of the milk. Since these types of
attributes of quality unexpectedly delight customers, they are often
These attributes refer to aspects that are neither good nor bad, and
they do not result in either customer satisfaction or customer
Communication limited to in-app messages as the feature or functionality developed results in removing user pain point.Below is how the Kano model describes these types of features.
These attributes result in satisfaction when fulfilled and
dissatisfaction when not fulfilled. These are attributes that are
spoken and the ones in which companies compete. An example of this
would be a milk package that is said to have ten percent more milk for
the same price will result in customer satisfaction, but if it only
contains six percent then the customer will feel misled and it will
lead to dissatisfaction.
Both email and In-App:
When the feature or functionality developed is a must have and will have a negative impact on the user if it wasn't implemented. here is what the Kano model has to say:
One of the main points of assessment in the Kano model is the
threshold attributes. These are basically the features that the
product must have in order to meet customer demands. If this attribute
is overlooked, the product is simply incomplete. If a new product is
not examined using the threshold aspects, it may not be possible to
enter the market. This is the first and most important characteristic
of the Kano model.