Greg Meyer

If you'd like to read about the traditional way to communicate the product improvement process, I recommend reading about the product lifecycle process. Essentially what you are looking for is a regular (perhaps every 2 weeks or every 4 weeks) method of understanding what's new in the company and is the change notable, sellable, serviceable, and disruptive? Depending upon your answer you will have a different mix of materials you develop for internal and external consumption. Start with a method to communicate internally what's going on so that your team is on the same page (what's the name we've decided for a feature? what does it do? When does it launch? How do I use it). If you start with a feature brief containing the talking points for support and sales, a description or outline for external communications like a knowledge article or a press release or blog, you will have a good start. If the change is sellable, you might create additional sales enablement materials like a presentation, a few slides, or a data sheet for your sales team. If the change causes an impact to service you may bullet typical FAQs and write them up as knowledge articles. Finally, if the change is disruptive you may think about training and communication plans needed for external customers so that they are not surprised by the change and have a clear timeline to prepare.

A few ideas: * start by looking at your favorite company and see what they do when they launch products or changes * read whatever you can find about product marketing - https://blog.hubspot.com/marketing/what-is-product-marketing is a good start * talk to some product marketers and ask them what they do on a daily, weekly, and monthly basis 

Sales enablement changes when your company is "business to developer" to point at a different stage in the funnel: the charismatic, knowledgeable developer who probably already has a solution. When you are pitching to developers it helps to build a scientific, clearly logical and reasoned case for them to abandon their current solution and adopt yours based on a productivity or efficiency gain, or because you enable them to do something they simply couldn't do before. Keep it simple, explain yourself in plain english, and err on the side of less bs and more details and developers will respect your approach more.