R&D Programs

The lifecycle for a typical product or service is shown in Figure 1 below. The green line represents the revenue generated by the product or service and the red line represents the development and support costs. For our purpose we’ll talk specifically about products, but the same arguments also hold true for service.

A typical product will move through 4 phases: Introduction, Growth, Maturity, and Decline. The time a product will spend in any one phase can depend on any number of factors both internal and external. We typically want to extend the time a product spends in the growth or maturity phases as these are the optimal revenue generating periods. This desire must be balanced with the development costs at any point in the cycle. As shown, it is difficult to make data driven decisions early in the product phase as most revenue is realized well after the major cost has been incurred. In most cases we need to rely on market analyses and predictive models to help with funding decisions.

The example above depicts a somewhat ideal scenario where the cost sharply drops off as the product approaches maturity, but this is rarely the reality. The example also depicts costs stabilizing at a low level over time. As a product enters the decline phase the recurring cost should be modeled to predict when revenue no longer exceeds cost. In some cases, it may be worth investing more in development as a product enters this phase to lower the eventual recurring costs in the decline phase.

The longer a product remains in use, the higher the likelihood that significant investments must be made to keep the product viable. Typical causes include the release of a new operating system or new security requirements that apply to the product or target market. A large cost may also appear at the tail end of the lifecycle if a product migration is required.

There are several strategies to extending the viable life of a product and the most common is to reinvest in features and capabilities. An example of this behavior is depicted in Figure 2. The underlying assumption is that the cost of adding incremental capabilities is far cheaper than creating a completely new offering. Although this approach can be very successful it’s also commonly observed that the costs associated with adding incremental features over time increases. At a certain point in the product's lifecycle it is no longer efficient to continue with the original codebase and a major reinvestment must occur.



There are many factors that should influence the choice to reinvest or not. It doesn’t make much sense to invest in new capabilities if there is no potential revenue but it’s also common to see time lag between feature development and revenue. This means that we cannot solely rely on revenue numbers to set product direction. Another factor to account for is that once a product is defunded it can be very expensive to restart. If the time window is short this could just be a matter of reassigning the original team back to the effort; if it’s a longer window this could require retraining an entirely new team.

Thus, it is reasonable to assert that when a product is funded, it should be to deliver major new capabilities. These capabilities should be linked to end user scenarios which have been determined to have monetary value. This is as true for a new product as an incremental investment.

We term these major funding events as R&D Programs. The attributes of a Program are:

Program Organization

The complexity of any software system increases over time and it becomes increasingly challenging to efficiently solve new problems. As the system grows we need to balance local decision making with the ability to deliver a consistent and manageable system. As with computing, we know we can gain efficiency by running tasks in parallel, but the overall speedup is limited by any purely sequential processes. To this end, we strive to create small and autonomous teams that are free to get work done without rate limiting dependencies external to the team. These teams become Development’s core unit of scalability and the rest of the department's focus turns to providing whatever guidance is necessary to target these teams at high value outcomes.

Once stable, a typical development team will compromise of Engineering Manager and between 4 and 8 developers. It is assumed that teams are stable constructs and that the individuals on the team grow and evolve skills and competencies over time. This is not to say that problems a team works on or the codebase they contribute to are stable over time. We want to avoid creating ownership over a code base or a problem domain as it can create perverse incentives that we want to avoid. Ultimately, we hire smart individuals, and if we align them with business goals, they’ll be able to deliver great results, even autonomously.



In this context, we can look at a Program as a mechanism to organize around a business goal. If we can break down a Program’s overall objective into distinct components, then we can leverage multiple teams to execute on the goals in parallel. A diverse set of support functions are required in order to successfully execute a Program. Some of these skills are required fulltime for the extent of the Program and some are only necessary at certain junctures. Also, different Programs will have different needs depending on the deliverable, therefore composition may vary from Program to Program. Essentially, Programs enable the department to successfully execute on problems of a larger scope and of higher value than possible with an individual team.

The charts in Figure 4 provide a basis for a conceptual budget for the department. As with any budget, the goal is to provide a basis for balancing resources and identifying needs. One thing that is apparent is that we need to grow the program support functions significantly.