Many successful software products, upon close inspection, show evidence of a dual personality. Most users see a product that serves a particular market need: Salesforce.com, for example, offers a number of features that simplify and organize the activities of account and opportunity management. Sometimes, however, these products have second side that addresses a different constituency -- software developers. Salesforce.com also has built a strong community of third-party developers that provide a variety of new solutions on top of the underlying software platform.

There are many advantages to building a software product that doubles as a platform -- doing so helps ensure a strong, extensible underlying architecture and also enables the potential for attracting a vibrant external developer base that can further cement the value of your core technology. There are also, however, challenges specific to platform development that confront a product manager responsible for such an offering.

To begin, we can make a rough attempt at defining the role of a platform in this context as a way to expose system and application level services to developers through one or more programming interfaces. Common examples include the Microsoft .NET framework, the various versions of the Java Platform, Adobe's "Flex2" framework, and, as noted earlier, Salesforce.com's "Force.com" platform.

The success of a platform, typically measured by the level of its adoption by the target developer community, rests on several important characteristics that influence a product manager's decisions. A successful platform should be
- Predictable,
- Reliable,
- Usable,
- Useful,
- Sustainable,
- and Extensible.

Maintaining a sense of predictability with your platform adopters is critical because outside agencies base their own internal product plans, to some extent, on your published roadmap. You'll find little sympathy for slips or changes in capabilities from published targets . A record of shifting deadlines, or unstable application interfaces poses a real risk that your partners will start evaluating other alternatives, or even move elsewhere entirely.

There are some basic metrics and techniques that can help assure your roadmap defines a set of predictable releases. First, look at the recent history of your scheduled deliveries focusing particularly on the "planned/actual" ratio for various estimates. A few years ago, I had the opportunity to plot historical data for several past releases in which we tracked the original estimate from the development team versus the actual time to release and found a surprisingly predictable level of unpredictability. There was a coefficient that very reliably mapped a planned time to an actual time for this organization. (The T-constant, as it became known, was 1.55 at the time.) A second technique is to work with your development team to ensure that a suitable research period is built in to any release schedule to help reduce the probability of later schedule-stretching surprises.

The second important success factor for a software platform is a strong focus on reliability. It's critical to understand that your customer's applications may be significantly out of sync with your release cycle as illustrated in the figure below.

It may not always be possible for you to introduce certain new features or enhancements particularly if they have the potential to impact backwards compatibility of deployed applications. Involving first-tier partners in early releases of new platform releases, and instituing a gradually expanding circle of beta-testers can both help mitigate unexpected consequences of new platform releases.

In this first of two postings, we've taken a quick look at some of the factors that affect the planning for a software product that serves as a platform for external development. In the next installment, we'll cover in more detail the other four success criteria noted above.