Product managers, especially software product managers, are frequently faced with the question of when to “cut a release.” Engineering teams are typically ready and willing to continue new product development, but at some point, the product must be released to the market. The literature on agile software development encourages delivering maximum business value as early as possible, so that if market or competitive pressures require a release sooner than initially anticipated, its value will be maximized. However, there are pressures motivating early and frequent releases and opposing pressures motivating late and infrequent releases. The literature doesn’t elaborate on how to cut a release that successfully balances these pressures.

Arguments for Early/Rapid Releases

• Make money: the purpose of any commercial product development business is to earn a return on capital invested. The sooner the product is released to the market, the sooner it makes money, and the better return it yields.
• First mover advantage: in certain market segments, the first developer to market with a product may dominate the market and squeeze out all competition.
• Avoidance of scope creep: when there is a hard deadline for the product to be released, product developers and managers are forced to set priorities. The desireable result is that less important (or unimportant) features are dropped. On the other hand, when there is a soft deadline or no deadline, product developers and managers are tempted to add features. Additional features may dilute or distract from the core value of the product.
• Acquisition of early market feedback: for new products, the importance of certain features and even the feasibility of the product actually operating successfully in the field may be uncertain. Early release of the product lets future product development proceed with the certain knowledge derived from field deployments.
• Real option to terminate: a related argument for early releases is that it prevents you from throwing good money after bad. Based on the experience of deploying an early version in the field, product management may choose not to invest in further development.

Arguments for Late/Infrequent Releases

• Overhead from multiple customer configurations: frequent releases of a product result in customers with various configurations. Each configuration includes unique features or defects. The development organization incurs overhead from educating the market, the sales channels, and any support organizations on each release.
• Overhead from multiple development configurations: frequent releases of a product result in development organizations managing multiple configurations. Development teams incur overhead from managing released configurations separately along with their respective software patches (or manufactured product recalls). Each configuration may require different installation software for upgrading to new or different products. Testing of backward compatibility also becomes easier when there are fewer configurations in the field to test.
• Economies of scale: delaying a product release may allow the inclusion of features that win new customers. This means a larger customer base is available to justify development of enhancements, as well as to provide testimonials and case studies. Although during development it seems relatively easy to cut multiple, frequent releases, this tends to degrade economies of scale and therefore margins.

In order to balance these forces properly, we must re-visit and refine the feature priorities outlined by agile development processes:

• "Must-Have" This is the category of features without which the release is incomplete or not worth completing. Even a single new customer will not be fully satisfied with a release unless these features are included.
• "Adds Significant Business Value" This category should contain features which will prompt sufficient purchases to fully justify the development effort.
• "Nice-to-Have" This category should contain features which would be developed, except there are insufficient prospective customers to justify the development effort. If market trends raise the number of prospects, or if technical developments lower the cost of the feature, then features may move from this category to another.

A release should consist of the “Must-Have” and “Adds Significant Business Value” features. Otherwise, economies of scale are poised against the product development effort.