Shipping a large feature, or major release involves many important considerations.

Creating a release plan

Ahead of the release we create a technical release plan. This release is far bigger than usual. Joyous V3.0 comes with a major architectural re-write. This means we cannot release our chunks separately.

Here are the basic elements for the plan:

• Eventually you have to set a hard release date. We started with a two week release window, and then a month out, we announced the hard release date.
• Determine the precise timing. We are a cloud based SaaS product. So a release as major as this one requires some thinking. We chose a Saturday afternoon in NZT to deploy the release. This is the day with the least activity across the globe for Joyous. It also gives us a Sunday to roll back the release in a worst case scenario.
• Carve out a window for end to end testing. We were able to keep this window narrow by testing things as we finished building them.
• Run a test deployment. We test the deployment, so we understand the potential downtime. This also helps ensure the real deployment runs smoothly.
• Document the plan. We have a document that outlines our release steps, timing, and roll-back plan.

Communicating to key stakeholders

With a release as big as Joyous 3.0 we have been communicating the coming changes months in advance. We created a What's Coming page. The plan and other updates are included in our monthly product updates.

We also shared working prototypes with customers and users throughout the process. This helped us to validate and improve the outcome. It also helped us take many key stakeholders on the journey.

Future improvements may not be immediately available to everyone. Our V.30 changes are not hidden behind feature flags. This release will be live for everyone from day one.

As we got nearer to a final release, we updated our customers on the final release plan.

Messaging users

With a release this major we decided that it would be important to message users ahead of time. So, one week ahead of the release we send a notification inside of the tool. This is a short message that lets users know a change is coming, along with a link to what's coming. We have a different message for different types of users.

After the release we send another notification inside of the tool. This includes a link to showcase the changes we have made, and how they benefit the users. This message also encourages users to ask for help and send their feedback to us.

Our customers are large enterprise organisations. So we created internal release comms for them, rather than sending out mass emails on top of our internal app messages.

Help

We have a pretty comprehensive Help Center at Joyous. This includes detailed articles on how to use Joyous. It also includes a library of videos.

We plan ahead and ensure that our Help Center content is updated at the same time as the release. This falls under the responsibilities of our product folks, so we made sure to set aside the time and plan for it.

Product marketing

As we near the end of this release our product folks team up with our marketing folks. This release comes with some game changing functionality. It is a huge opportunity to market the items that differentiate us even more from the market.