Transcendental Generalization

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.

Via Wired News: Tesla Motors has introduced the Tesla Roadster with impressive performance characteristics.

By implementing Microsoft Dynamics, SAP or any other ERP (Enterprise Resource Planning) system, an organization imposes a uniform structure on its data and processes. The uniform structure of data is meant to promote understanding of the entire organization through management reports that can be compared and consolidated. Uniform processes are meant to promote smooth and productive interaction across the entire organization.

These are desirable intentions, but when an organization is large, it includes teams with data and processes that may be optimized for certain environments (market segments, product lifecycle stages, geographies, etc.) By optimized, I mean they have unique processes and organizations of data that work well for them, even though they may be difficult to compare, consolidate, and integrate with the rest of the organization. An enormous challenge of implementing an ERP system is “normalizing” teams across a large organization so they “fit” the uniform structure and can contribute to the benefits of enterprise resource planning. This challenge is tantamount to making teams think and work differently, to participate in the ERP system.

However, each team forms an identity and builds pride around how it thinks and works, precisely when it is different from (and perceived to be better than) how the rest of the organization works. A team may not realize that it is environmental differences that allow or require the differences in data organization and process. Such teams suffer trauma when global processes and structures are imposed on them. In particular, if the global structures are (or are perceived to be) sub-optimal for their environment, teams may actively resist their imposition, or experience failure and loss of productivity.

Collaboration systems like Microsoft Sharepoint, Jive’s ClearSpace, Intel’s SuiteTwo and PBWiki’s product allow individuals and teams to create, organize, and share information. One benefit of such systems is that their use can be initiated by an individual and then grow organically to provide value to an entire team. These systems currently fall short in two ways:

• They ignore processes. A team may want to define workflows that artifacts must pass through before they are considered ready for sharing outside the team. Collaboration systems would benefit from the flexibility to define and enforce such workflows.
• They ignore the value of collaboration between teams. These collaboration systems could actively identify commonalities, across teams, in organization of data and definition of processes. For example, based on the names or contents of tables or columns, a collaboration system could predict that two teams are maintaining separate lists of customers that might be usefully combined or linked. Another example: if the name of the terminal state of one team’s workflow matched the name of the initial state of another team’s workflow, a collaboration system could predict that the two teams would benefit from closer interaction. Based on such commonalities, the systems could help teams share best practices, support each other’s work, and generate reports that can be compared and consolidated, all without losing their individual identity and value. For this to work, collaboration systems would have to expose–and help resolve–discontinuities between the team’s organization of data and the larger organization’s.

If such capabilities were added to collaboration systems, they might be successfully introduced into an organization and provide the benefits of ERP systems without traumatizing and lowering the productivity of teams. The costs of implementation would also be low if the systems were designed to promote incremental, organic adoption.