Scheduling Product Releases

planning calendar

When you define a product roadmap, you also define the release dates for your product. Change happens. Your market changes, your customers change, your requirements change. Unpredictable events happen. Your competitors release a new killer feature, your developers have an epiphany (or run into a roadblock). Should you change your release schedule?

Jeff Lash has a good article, Set the Right Release Date. Jeff’s style is very distinctive, and you’ll enjoy the way he presents his point-counterpoint positions. In his article, he points out that a release date may or may not have a compelling event tied to it.

A compelling event is one that has financial significance. If you have a release date tied to a conference, Jeff asks – will that conference generate a lot of sales? Or is it just a convenient time to have a release? When you question the motivation for a release date, you may find that it is arbitrary.

  • That’s the date because that’s what we decided six months ago. Arbitrary.
  • That’s the date because we release on the first of every month. Arbitrary.
  • We have to have it on date X in order to be in the stores for Christmas. Compelling.
  • The release must coordinate with the refresh of our flagship product or we’ll lose sales. Compelling.

Building a Business Case

Jeff makes a very valid point – when faced with the possibility of slipping the date, you need to be able to build a business case for not slipping before you make the sacrifices required to not slip.

Meeting the product release date might mean working overtime. And that cost can be very high – make sure that the death-march is worth it. It might mean adding people to the project, although that isn’t likely to work. Adding people to an already-late project doesn’t fix the problem in the short term.

Avoiding project delays might mean releasing on-time with reduced functionality. The key to this analysis is to use structured requirements, and trace from the deliverables to the value.

structured requirements

For example, imagine the following hypothetical product:

Order Processing Product

First you identify a set of goals. Then you define the use cases that enable your customers to achieve the value inherent in those goals. Finally you define the requirements that support the use cases.

Example Goals

  • Goal 1: Reduce the cost of order fulfillment by 20% – value to customers = $1,000,000.
  • Goal 2: Reduce the time that inventory restocking takes by 50% – value to customers = $200,000.

Example Use Cases

  • Use Case 1: “Fill Customer Order” – supports Goal 1.
  • Use Case 2: “Audit Inventory Levels” – supports Goal 2.
  • Use Case 3: “Validate Order Contents” – supports Goal 1.

Example Requirements

  • Requirements 1,2, and 3 support Use Case 1.
  • Requirements 4 and 5 support Use Case 2.
  • Requirement 6 supports Use Case 2 and Use Case 3.
  • Requirements 7 and 8 support Use Case 3.

The Unexpected Event

You find out that the development team can not complete the code for Requirement 4 in time. What is the impact of not having Requirement 4?

This is where traceability saves you. If Requirement 4 can’t be delivered in this release, then customers will not be able to use our product to audit inventory levels. This change affects the use cases that are enabled by the release. If inventory auditing is not enabled, then restocking times will not be reduced for our customers with this release. The cost to customers of not achieving Goal 2 is $200,000. Therefore, the cost of delivering without requirement 4 is $200,000 to the customers.

Assume that your pricing model is such that you are charging $50,000 for the product / feature that achieves Goal 2. You will lose $50,000 in revenue by releasing without Requirement 4.

Imagine that you can find the resources to release Requirement 4 (and therefore Use Case 2) on the original date, and the opportunity cost of those resources is $40,000. If you didn’t already know how to calculate ROI, this would look like a good decision.

$50,000 in additional revenue is probably not worth more than $40,000 in additional costs. Revenue comes at a profit margin. It wouldn’t be unreasonable for you to operate at a 40% profit margin. That means that $50,000 in incremental revenue only results in $20,000 in incremental profit for your company. You’ll lose $20,000 if you force requirement 4 into the release without slipping the schedule.

The Analysis

This analysis is simplified. Normally, you would estimate the impact of a delay, which is most likely “get the money later” not “don’t get the money.” With a compelling event, a delay might represent a loss in revenue. Without a compelling event, a delay will be more likely to create a delay in revenue. There are other harder to calculate impacts too – how many customers are gained or lost based upon the consistency of product releases? Have you already told your customers what will be in the next release?

A change to a committed release schedule may have a larger impact than a change in an anticipated or unexpected release.

Conclusion

The important element is to make a reasoned decision, based on financial analysis of the costs of delaying a release (or a feature). You shouldn’t always “stick to the schedule” any more than you should always “stick to the functionality” and slip the schedule.

8 thoughts on “Scheduling Product Releases

  1. Hello,

    I am up for building the business case up-front before you
    even start release implementation. How about spending a little
    more time and effort at the release planning stage or even
    as part of the backlog prioritization work (which may be
    happening in background, parallel to release work), based on
    customer feedback, risk and ROI estimates (the exact formula
    is a topic for another discussion :] ).

    Instead of traditional ‘must have’, ‘should have’, ‘could have’
    prioritization (where you might have N, M, and K features of
    each sort) do exact 1,2,3,4,5,….. Where #1 according to your ROI
    calculations and customer feedback analysis has the biggest weight
    then #2 weight, then #3 weight, …. And then also decide
    which # is the one before which you can not compromise.

    Of cause collaboration with R&D is very important to keep yourself in check. May be all your team can do in a given time frame is just #1 and #2. Estimates wont solve all your problems but will definitely help you be more
    realistic. Actually an experienced team doing its N’th incremental release can be pretty precise.

    Then have your R&D team focus on the features in this exact order (which they actually agreed to during release planning collaboration).

    In such a scenario when the ‘unexpected event’ comes or release is not meeting your deadlines at least you know you’ve done your best in terms of the most important features. The decision whether to continue or to stop the work (and release the product) should be straight forward.

    What do you think?

    I would be interested to hear about techniques that people use for backlog prioritization, whatever formulas exist based on ROI, risk, customer feedback. So when we come to a release planning stage and get a chunk of
    requests from our backlog they are already pretty well prioritized.
    We just add final rifinements, check estimates and see how many
    of those features we can do given our time-frame
    (or should we re-consider the deadline?).

    Thanks,
    Alexey

  2. Hello Scott,

    Thanks for this. I continue to enjoy your posts.

    I have two comments on your topic;

    One related to the irrational but important motivations associated with perception which I posted on Jeff’s oiginal article.

    The other is about resourcing multiple projects. For instance you might have one implementation manager working across all releases and he or she will need to schedule them according to their ability to get through the work.

    But in general your point is a good one. I am wroking with some marketing mangaers now who are launching products.

    The ones that consider the launch date as critical are clearly sacrificing their business case by planning to launch a substandrd product which no one will buy, while the ones who put a quality product first are going to achieve their targets, just maybe a little later.

  3. Hey Alexey, thanks for the comment and question!

    We’ve been promoting essentially the practice you define for organizing the content of releases.

    1) prioritize based on value (and Kano can help with that)
    2) use estimates to manage delivery by timebox, incorporating into each release
    3) manage change against those timeboxes (estimate-reality disconnects, new/modified requirements, bugs to be fixed)

    Prioritizing Requirements Across Releases and Prioritization With ROI and Utility make a good starting point – and there are other articles too. Let me know if you want me to add the links to this thread.

Leave a Reply

Your email address will not be published. Required fields are marked *