Cross-team Product Development & Delivery Process: Go-to-Market & Release Phases (Part 6)

Table of Contents

• Intro & Definition
• Pipeline Success Metrics
• Context Initiation Phase
• Discovery Phase
• Development Phase
• Go-to-Market & Release Phases

At this point, you should already have something tested and shippable. But there is still plenty of work to be completed before actually deploying the product to your end-users. First, you have to engage the audience, let them know of your new features, educate, and train them. Second, you have to plan the deployment, meaning you know how you will deploy changes, how you will notify users that changes are about to be deployed, and decide to which exact audience you will give access to features.

All this work can be split into two phases: Go-to-Market and Release.

Go-to-Market Phase

The following phase is initiated by the product marketing manager (PMM) role, who has to do all the prep work together with product and project managers. Usually, the items that PMM works on are the following:

• Identify the target audience. Either this is an alpha user or beta user, or should you be just releasing to the general audience.
• Prepare the release plan for approval. The plan should consist of the release schedule, target audience description, and features that will be included in the release.
• Marketing materials. Articles, blog posts, walkthrough materials, education videos, and so on. Everything that will help to deliver the product into the right hands with the corresponding efficacy.
• Release announcements. PMM should prepare both colleagues and end-users for the upcoming release. Internal company statements, emails, global meetups, PR materials, newsletters for end-users, and so on.

The release plan should be approved by key stakeholders. The release manager should be notified upon approval so that he or she can kick off the deployment plan execution. An announcement of the release is usually made the week or two before the actual release plan execution.

When all the materials are completed (this might take a bit of time, especially for enterprise solutions, where a horde of tech writers is doing lots of writing for the release preparation phase) the PMM reaches out to the release manager to proceed with the deployment plan.

Exit Criteria

To be able to proceed with the deployment, the PMM should produce two pieces of work:

• Marketing materials package. A set of deliverables that will be spread using marketing and advertisement tools, influencers, blogs, etc.
• Release plan. An approved document where the schedule, audience, and list of features are stated.

The release plan is then handed off to the release management group to define and execute the deployment plan.

Release Phase

The last and the most exciting phase of the whole process. First, the release manager should define the deployment approach based on the PMM target audience definition. Second, feature flags (if you use ones) should be configured according to the release plan.

The biggest question during the release phase is how to ship your product. There are several deployment strategies to execute based on the release plan:

• Seamless (shadow) deployment
• Ramped (rolling) deployment
• Canary deployment
• Blue/Green deployment
• Standalone package deployment

This is not a complete list, of course, so let your release manager handle that. The product deployment may also require the maintenance window to be announced, depending on the type of the release.

Whenever the release date comes, the release manager should gather the release group that consists of the product manager, project manager, engineering lead, and development operations lead. You need these people to constantly monitor the state of the release to be able to respond quickly to any issues that may arise during the deployment.

After the deployment plan is executed, the release manager should also provide the changelog documentation both to internal company stakeholders and to the end-users.

Exit criteria

Of course, this is all about the product running in the production environment. But not only. Deploying is only half of the job to be done. The release manager has to prepare the following documentation to be able to close the release phase:

• Changelogs. A list of features delivered to the audience and version changes to the product sub-systems, libraries, packages, etc.
• Validation reports. The documentation about the status of the current release. It should include the health metrics, recent KPI numbers as per the release plan, status reports on the number of issues encountered, and actions taken to mitigate the latter.

What’s next?

The work does not end after the release, of course. You still have to validate whether real KPI numbers meet expectations, monitor the health state of the product, respond to any concerns raised by end-users and provide support.

But, you take a glass of champagne and give yourself a credit for this accomplishment. Take some rest and get ready to move again back to phase one — initiate the context and get ready to ship more added business value to your target audience.