Product Plan

Product Plan2017-10-12T22:05:26+00:00

What is the Product Plan?

The Product Vision provides only very high-level information that tells the team very little about how the product will actually come into existence. In most cases the product won’t all be delivered in a single release; rather, it is likely to evolve through a sequence of increasingly complete versions.
So the questions the team need answering are:

  1. What needs to be delivered?
  2. How and when does it need to be delivered?

The first of these questions is largely answered by the Product Backlog. To answer the second, the Product Vision needs to be translated into a Product Plan. It is the Product Plan the organisation uses to identify and schedule the releases through which the product will pass on its way to fulfilling the Product Vision.

Product Planning in the Agile lifecycle

As this diagram shows, Product Planning comes at the very beginning of the Agile lifecycle as a whole.

Product Planning in the Agile Lifecycle

  • However, it is also a recurring process, which should be repeated at least every three months.
  • This will keep it realistic, without causing so much change (much of it probably unstable) that decision-making becomes impossible.

Creating the Product Plan

For general principles of Agile planning, click here. The detailed process for creating a Product Plan is defined here. As with the Product Vision, organisations will generally have their own unique approach and outputs for Product Planning. But from the Agile team’s point of view, it needs to specify:

Release number
  • An unmodifiable, arbitrary reference number.
Release title
  • Descriptive name, code name, etc..
Target release date
  • Typically a month or a quarter rather than a precise calendar date.
  • Outcome the release will achieve (a new market segment entered, a major product upgrade, new user type supported, etc.).
Key stakeholders
  • Who has a special interest in this release?
    • Apart from the product’s ‘normal’ stakeholders.
Release scope
  • The major items the release will include.
    • Epics, features, themes, stories.
    • Major technical changes (platforms, architectures, etc.)
  • Collectively, the items for a single release should satisfy the requirements both for a Minimum Viable Product and for Minimum Marketable Features.
Critical non-functional attributes or metrics
  • Only include if they are important for explaining what the release needs to do –
  • – or understanding how hard it will be to implement.
Critical Success Factors (CSFs)
  • What unusual or exceptional factors must be managed for the release to succeed?
  • For each CSF, what are the Key Performance Indicators (KPIs)? That is, how good is good enough?
Contingency (%)
  • For defect remediation.
  • For long-term repayment of technical debt.

What’s the right format for a Product Plan?

What should the Product Plan look like? A simple table is often perfectly adequate, but a ‘roadmap’ can also be helpful, showing:

  • The major destinations (i.e., releases).
  • The major milestones (typically external events such as seasonal dates or times of user involvement such as UAT).
  • The ‘road’ each team will take (e.g., swimlanes showing the sequence in which features will be completed, new platforms supported, etc.).
  • Intersections between different ‘roads’ (e.g., integrations between neighbouring teams).
  • The overall timeline.

But like the Product Strategy, the Product Plan should not be more detailed than necessary, and should be presented in whatever minimal format is needed to communicate with its audience. A detailed Gantt-style picture is unnecessary and unrealistic at this level.
Nor should the Product Plan be too prescriptive. It will help neither the team nor the organisation as a whole if false certainties or unsustainable expectations are created. The Plan should define only what is really necessary and really predictable. It should certainly not include pet ideas that may never be implemented!

How is the plan validated?

Before the Product Plan is finalised, it should be subject to a two-way validation:

  • Is everything in the Product Vision traceable to & implemented by the Product Plan?
    • Including all the ideas, epics and features in the Product Backlog.
  • Is everything in the Product Plan traceable to & justified by the Product Vision?
    • And thus achieves the organisation’s wider objectives?

Without full traceability in both directions, there’s a serious risk that the team’s work will become divorced from the organisation’s goals.
Then no matter how good a product the team builds, from the organisation’s  point of view it will have failed.

Who owns the Product Plan?

To prevent the Plan from becoming chaotic (the very opposite of Agile), it needs to be owned and managed by a single individual, with exclusive authority over what it contains and how it is interpreted.
From the point of view of the organisation as a whole, the Product Plan may not be owned by the Product Owner. However, from the Agile team’s perspective, it is best if they treat the Product Owner as its owner.

  • This will create a single authority over all decisions about the Product Plan.
  • … and a single point of contact with the group that does in fact own the Product Plan.

Of course, anyone should be able to propose improvements to the Product Plan – stakeholders, marketing, subject-matter experts, and so on. The Agile team should be expected to provide technical insight and experience that enrich the Product Owner’s understanding of the Plan and how it might be implemented.
It’s also critical for the Product Owner to manage the Product Plan effectively. Product Owners sometimes focus too much on the details of stories and the current Backlog. It is at least as important that the wider issues of product strategy are fully addressed and translated into an effective release programme:

  • Product strategy.
  • Release strategy.
  • Business value.
  • Stakeholder management.
  • … and so on.

How does the Agile team use the Product Plan?

By showing how the product is expected to change over time, the Product Plan allows the team to visualise the product’s future, think strategically about the architectural aspects of the product, and ask questions like:

  • What are the major change points?
  • Which parts of the product are transitional and which have a long-term future?
  • What is likely to become a priority in future?
  • What large technical decisions do we need to make to ensure that we don’t make development harder in future?
    • E.g., optimising our architecture in order to minimise technical debt?
  • Will the same technology apply throughput?
    • Or will we need to change direction at some point?
    • Does this make sense?
    • Will this be more costly than the Product Owner realises?
  • Can we realistically maintain the expected cadence of development? If not, what do we need to do about it?
    • Challenge the Product Plan?
    • Or change the way we work?

Knowing the answers to questions like this will make it much easier for the team to anticipate change and avoid making bad, short-term decisions. Conversely, with this kind of insight, what might have been no more than a series of uncoordinated projects can be turned into a smooth, well-structured programme.

How do you display the Product Plan?

So now that they have a copy of the Product Plan, what should the team do with it?

  • The most basic thing the team can – and should – do is to blow it up and hang it on the wall where the team – and visitors – can see it every day.
  • With the Product Plan constantly in the corner of their eye, the team will continue to think about what, ultimately, they are trying to achieve.
  • It will also inspire them in a dozen small ways to think about how their own work can be adapted to suit the Plan better.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?