Standing up LaunchNotes

Before LaunchNotes, Tyler and I worked on a customer communications product. Downtime communication to be specific. We saw time and time again companies looking for a better way to communicate downtime to their customers. We built features for this product. We heard hundreds of stories on why it was important to them. It all boiled down to one sentiment "People depend on our product — they want to know when it breaks."

The same is true for product changes. People depend on your product — they want to know when it changes.

Software has eaten the world. It's wiping the corners of its mouth and promising the diet "starts on Monday." Restaurants use machine learning, Alexa is a household name, and most every company can be considered a software company. Even if they're not, they rely on software in some way. The average employee uses ~8 SaaS apps to get their work done.

Enter LaunchNotes.

LaunchNotes is about communicating changes at the right time to the people that depend on your product or service. This starts with the people inside your company that need to market, sell and support the product. And it ends with the people outside your company, like your customers.

It's the communication layer on top of where your work gets done.

We've worked on a customer communication tool before. But, we've also been on the other side. The side where we depend on products and services that are rapidly changing from underneath us. Sometimes it's a jarring design change where you can't find a setting, other times it's an update that breaks our entire integration.

A great example was with an integration partner. They released a version 2 of their API. They notified their end users three months ahead of the change, which was great! It wasn't clear, however, if our customers would be required to generate new API keys. When we contacted their support teams, we were assured that the V1 API keys would work forever, meaning no customer outreach on our end. We received a separate notice days before the change was supposed to take place saying V1 API keys would be deprecated.

While our partner did a great job of getting ahead of that change, it was clear that their teams weren't aligned on its details and how to communicate them effectively with their end users. And this resulted in a poor experience for everyone involved.

People aren't afraid of change, they're afraid of being surprised by it.

Teams that create software services are getting better. They're more efficient. Agile practices and continuous integration have unlocked a new speed for modern software teams. Updates, bug fixes, and new features are rolling out faster than ever. What you end up with is a bunch of people relying on products that are constantly changing. This results in last minute messaging, poor support, and confused users.

A one time comms blast when changes are live may feel like the right way to communicate product changes, but what do customers think? A feature update may seem like something everyone welcomes but it means unexpectedly learning something new. What do the people inside the company that need time to update help docs, create messaging, and learn and sell the product think?

Tyler and I worked on a customer communication platform for over 5 years. Now, we're ready to apply those learnings to LaunchNotes to build a world class product change communications platform.

Change log tools aren't new but it's the communication timing, context around releases, and single source of truth for product changes we're most excited about for LaunchNotes. Subscribe here to stay in the loop on the launch of our private beta: LaunchNotes: Private beta launch 🚀

Additional resources
Additional resources
Additional resources