Product Development Lifecycle

IBM teams follow a process framework called the Product Development Lifecycle (PDLC). IBM defines the PDLC as the process of taking a product capability from an idea through its development and release to market and beyond. Since product development takes place in a continuously evolving market, the framework creates room for validation in every phase of the lifecycle.

The PDLC is organized into three phases: discovery, delivery, and launch & scale. Once a product is in market, agile product teams do all these types of work concurrently, in parallel work streams, with feedback from in-market learnings shaping the priorities of both discovery and delivery.

Carbon has applied the PDLC framework to how we expect new assets like components, features, and patterns to be contributed to Carbon. We have broken the contribution process up into the same three phases, each having their own set of success criteria.

For IBMers only: You can read more about the PDLC on the IBM Winning Products website.

The discovery phase is where research, exploration, and validation happen. This is when innovations to the system are proposed and reviewed.

For an enhancement or net new asset to warrant resourcing a discovery phase, we need to determine the requirements for an asset to be considered as an innovation. Proposals need to show that the component or pattern would be useful to many teams and unique to the system.

All assets in the discovery phase start as drafts. As the asset progresses in its completeness and validation, it can graduate from

draft

preview candidate

The Carbon team and partners will review the proposals and determine next steps. Only the Carbon team can move an asset from discovery to delivery in core Carbon or Carbon for IBM Products.

Not all proposals in the discovery phase will move on in the lifecycle, some explorations may not gain traction or may be deprioritized by other efforts. This does not mean they are not valid or shouldn’t be used; it only means it currently isn’t a priority to systematize at the core level.

It’s also important to note that Carbon does not take on ownership and maintenance of certain types of assets like full applications, third party tooling, and shared services. For example, although it is shared tooling, the Carbon team does not include the Carbon for AI chat or IBM Assist Me in its libraries.

In the delivery phase, the Carbon team usually collaborates with a workgroup or discovery team to begin to codify and implement their asset for preview in the Carbon library.

As a component or pattern enters the delivery phase, we begin to complete the requirements for an asset to reach

stable

Once a contribution enters the delivery phase, it must be prioritized against the other contributions and work streams. The most important factor in determining prioritization in the contribution pipeline is business impact. The greater the case for reuse or support for a high-impact team, the more likely a proposal is to move up in the pipeline and garner more Carbon resources.

All assets in the delivery phase are considered in

preview

Launch and scale of course, involves having clearly defined success criteria or learning objectives that are monitored after launch. In this phase, an asset will become stable and achieve Carbon’s “definition of done” as defined below.

In the delivery phase, the workgroups should begin to think about the requirements for a component or pattern to become

stable

Along the way, you should be requesting peer on the various deliverables. It is crucial to get reviews early and often to make sure all requirements are accounted for. Reach out to the Carbon team if you are unsure who should review your work.

All components in the launch and scale phase are

stable

By aligning on the requirements for what it means for an asset to be done, we can create a backlog of work to be prioritized, better differentiate when an asset is a component versus a pattern, share expectations with contributors, and display the status of assets to users. With each phase, the component should progress in its completeness. Once it has reached stable, then the asset will be considered done.

Defining and standardizing our terms across the ecosystem is crucial as we align against the PDLC. In the past, teams operated under very different assumptions about what is a “pattern” versus “component”. It has been difficult to move towards stability without everyone being on the same page in this respect.

Eventually, all Carbon and Carbon for IBM Products resources (e.g. libraries, assets, design kits) will follow a schema to standardize definitions and documentation. However, for now, we’re just going to focus on defining the two most important assets in our ecosystem. Each asset type has its own definition of done that must be completed before an asset can be considered done.

As an asset moves through the phases, it needs to be reviewed to ensure all requirements and criteria are being met. Below are the best ways to get a review from the Carbon team. In order to not overwhelm these review channels the community first needs to show significant interest in the discovery phase. The community is the first approval gateway before the Carbon team engages with the work.