Milestones for the Product Development & Release Process

One of the challenges facing product managers is how to manage the product development and release process so that other teams in the organizations are involved and informed. I have found that having scheduled "information" milestones coupled with a multi-discipline  product release team usually simplify this process.

Release Proposal Document

The purpose of the Release Proposal document is to define, at a high level, the objectives and scope of a given product release. It should be a business document, not a technical one, which states the business reasons for releasing the product e.g. penetrate a new market, create a differentiated products, close a functional gap with a competitor, etc. These reasons should have business goals (e.g. capture x% of market share, or $Y in new revenue, or prevent $Z losses to a competitor) so that the success of the release can be measured in business terms and not just timeliness.

The document should also define the resources and time frame of the release, so that the readers understand the costs entailed in releasing the product. This is the counterpart to the business objectives mentioned above. The costs frame the scope of the release and allow the business leaders to agree to assume these costs if they are going to achieve the stated business objectives. (Hopefully, now you will understand the need for measurable objectives - the costs are easy to quantify, so to measure the success of the release, the objectives also need to be measurable).

Finally the Release Proposal document should also highlight any technical changes to the product (e.g. support for new platforms, dropping older platforms for software products) and any areas of risk or dependency. These allow the company's leadership team to understand the challenges and risks to the release project.

The Release Proposal document should be approved by the leadership team - this gives the product team to authority to start the project with (i) the backing of the leadership team and (ii) a scope within which they must manage the release project. If the product team finds that they are exceeding this scope (e.g. the time frame is longer than expected, they require more resources, etc.) they should go back to the leadership team with a modified Release Proposal for ongoing approval.

Project Kick Off Meetings

I firmly believe that educating the rest of the organization is one of the key success factors for product managers. I find that if other teams (e.g. Sales, Marketing, Operations) understand the drivers behind a product release, they can (i) better understand your decisions and (ii) better prepare and align their own activities for the eventual product launch. Therefore, I have required my product managers to hold "project kick off" meetings at the start of a product release cycle (i.e. after the Release Proposal document has been approved by the leadership team).

We have two kick off meetings; an internal meeting and an external meeting. The internal project kick off meeting is for members of the product development team only - i.e. product development, QA, documentation, UI design, etc. This meeting is a more technical meeting, which is why it is restricted as such. The product manager for the product presents the release plans to the product development team. This includes the business drivers for the release, the release timeline, and any technical constraints that are being placed on the development team. Explaining the business drivers is key in this meeting - it is the responsibility of the product manager to explain why we are releasing the product and what we expect this release to do for us in the marketplace.For example, is the product release a defensive move to fill a competitive gap? Or is it adding differentiating capabilities? How is this going to affect sales? And so on.

The second project kick off meeting is for key product stakeholders e.g. Sales, Marketing, Professional Services, etc. This is called an "external project kick off meeting" because the audience is external to the product development team. This meeting is less technical and focuses more on the business drivers for the product release and how these will affect the stakeholders. The product manager also presents a high-level release plan - containing only the key milestones that affect the stakeholders' activities. The purpose of the "external' meeting is to inform the product stakeholders about the product release, the business drivers behind the release, and the timeline for the release. This information is then used to schedule the organizational readiness activities for the stakeholder...more about this later.

Agile Sprint 0

OK...so you have an approved Release Proposal document and you've held the project kick off meetings. Now everything is ready and the product team can start coding - right? Not so fast...before anyone dives in and starts coding, there needs to be some high-level planning and design work and the UI designers need to get started on creating the user interface prototypes. This is the function of sprint 0 in the agile world.

It is tempting for the developers to pick up the first user stories and start coding...but the development managers (or architects or whatever title they have) need to lay some ground work first. Sprint 0 should be used to investigate the technical risks of the project and determine how to mitigate these risks. Any overall architectural planning should also be performed in sprint 0. The testing team should also create test plans during this sprint.

At the end of the sprint, the product team will have a better understanding of the challenges in the release project and will have plans in place to cover all aspects of the project i.e. architecture/design documents, test plans, initial UI designs, etc.

Agile Sprint 1-n

After Sprint 0, the real product development work begins. At the end of each sprint, the product team will conduct a sprint review to get a view on (i) how the work planned for the sprint progressed and (ii) if they are still on track for the overall project.

If the team finds that they are falling behind the release project plan, they have an opportunity to adjust the plan to bring them back on track. If they find that they can't do this without changing the scope of the release (i.e. the time frame, resourcing, or planned features), they need to go back to the leadership team with an amended Release Proposal document. This gives the leadership team an opportunity to reassess the product release plans and decide if the release still makes business sense, given the changed scope.

Beta Programs

If the release is going to have a beta program, this is another milestone for managing the overall project. A well managed beta program has a number of 'internal' milestones, such as customer training and readiness, support training, system readiness, beta release, and ongoing customer feedback milestones (depending on the duration of the beta program).

Each milestone an informational checkpoint that confirms that the beta program is on track and getting the feedback required. The beta program also has the benefits of getting selected customers using the new version of the product (and hopefully becoming future evangelists and references) and also internal teams, such as customer support, working with the product as they provide support to the beta customers. This outflow of information helps when it comes to the organizational readiness and actual product release milestones.

Organizational Readiness

Organizational readiness is the stage of ensuring that the overall organization is ready to market, sell and support the product once it is released. This means that Marketing needs to prepare datasheets, web site updates, etc. for the new product. Sales needs to be trained and ready to sell the product. This also requires that the business systems are updated for the new product e.g. pricing in the sales ordering system, shipping pick lists and bill of materials are ready for fulfillment, and so on. Customer support and professional services must be trained on the new product features and any upgrade procedures, so that can support customers using the new product.

Each department involved in the organizational readiness process should have its own task list and manage its own tasks, but having regular status update and informational sharing meetings can ensure that the process run to plan. Using something like a RACI chart for the organizational readiness tasks can facilitate the sharing of information and task dependencies.

(Also, see my post on Product Release team organization)

Product Release

Finally, you reach the product release date. If everything in the organizational readiness process has been completed as planned, then the product release is really a milestone event rather than any real work. This, of course, assumes that tasks, such as prepare master shipping materials, update the web sites, prepare sales and marketing materials, create press release, etc. have all been completed as a part of the organizational readiness process. In truth, these tasks should have been completed and signed off as a part of the product release checklist - if they haven't been, then the product was not ready for release!

Release Postmortem

This final milestone is usually one that is not implemented correctly in many organizations. By this time, most team's focus has moved on to the next product release, or to selling the new product, and so on. However, an honest product release postmortem is a critical component of any product release cycle. The key word here is 'honest' - too often the release postmortem is simply a history of the release project milestones and is not a critical look at how the project went. This is an excellent opportunity for the product team - and the wider release team - to critically examine all aspects of the project to determine if things can be improved. For example, were the business requirement clear and unambiguous? Did the UI Designers create complete and usable user interface prototypes? Did Marketing have enough beta customers to use as references for the press release?

The whole point of the postmortem is not to 'point fingers' but to examine what didn't work and discuss ways to improve the process for next time...or you will repeat the same mistakes again and again.