What Is Product-Based Software Delivery?

This post is an excerpt from the DevOps Enterprise Forum whitepaper Moving from Project to Product by Ross Clanton, Carmen DeArdo, Mik Kersten, Alan Nance, Karen Person, and Jason Zubrick.

So, you want to move from a project-based to a product-based software delivery model. How do you start?

In a large enterprise, there is likely an embedded culture of working in a project model. Roles such as project managers and portfolio managers will be impacted. Business leaders who previously may not have directly concerned themselves with IT’s implementation of Agile will now need to be more involved.

In this post, we will clarify what a product-based software delivery model is. In our next post, we’ll provide some simple guidance on how to start your journey.

What is a Product-Based Software Delivery Model

When trying to appreciate the idea of “product” within the landscape of IT and DevOps, it can sometimes be difficult to understand the boundaries of a product team in relation to how our business counterparts define a product.

To help conceptualize the idea of IT product teams to market products, we’ll lean on the product life cycle (PLC) as it defines products in the marketplace. The PLC is a simple model for describing the life of a product in a market using the relationship of measurement between costs/time and subsequent sales.

Product Life Cycle

Every product sold within the consumer world today has a life cycle defined by the creation to the demise of that product. Although every product has unique factors that led to its inception and rise in maturity, the fundamental model for understanding and recognizing those stages remains constant.

A product’s life cycle follows four stages:

1. Introduction: The product is new to the market and hasn’t had a lot of traction since being released.
2. Growth: The product hits a tipping point at the end of the introductory stage that pushes it into a rapid growth mode.
3. Maturity: At this point in the product’s stage, it is firing on all cylinders, but the product begins to show a slowing of growth and eventually shows signs of decline.
4. Decline: The product has started to show signs of weakness and is losing its value to customers.

The image below shows the relationship of the life cycle stages to sales and time.

Software Product Life Cycle

Now that we have a general understanding of PLC, there are several interesting relationships between the PLC and software product teams worth pointing out, including the following:

In the figure above, imagine that an IT product has been introduced to the ecosystem. Now, replace the label “Sales” on the y-axis with “Resources.”

As capabilities are introduced to customers (internal or external ecosystems), the resources needed to care and feed for that capability rise to a point of diminishing returns. In this example, resources could be capital investment dollars, manpower, and/or CPU/network/storage usage.

The most obvious abnormality to how the two ideas contrast is that software products don’t magically appear. This model doesn’t consider the work needed to “introduce” the product to the market.

In our guidance, we strongly suggest introducing “product” teams to alleviate many of the pitfalls common in today’s corporate environments. However, we also believe that projects don’t necessarily go away.

In the figure below, we’ve replaced “Sales” with “Resources” on the y-axis to better represent a software delivery point of view. We’ve also added the gray section entitled “Creation.” We believe that this part of the life cycle could follow more of a project life cycle in the ideation and creation of the initial product.

The Minimally Viable Product

The reason for the contrast in delivery models between projects and products in software is the introduction of the idea of a minimally viable product (MVP).

For a product to reach the point of viability, a specific scope must be met to deliver that value to the customer.

Imagine building a house. To get any real value from the house we need a few crucial features: a roof, flooring, running water, electricity, bathrooms, windows, doors, and a kitchen.

What makes this house an MVP is that the builder, knowing he could sell the house with these minimal features, installed a standard tub, no dishwasher, cheap carpet, and garage doors with no opener.

The project portion of the house analogy is the idea of building a house, deciding on the smallest number of features we need to live in the house, and building the house.

Once we assemble the house with our minimum set of features, the house comes out of the project phase and enters the product phase. The product portion of the house analogy is identifying features that we need to make the house comfortable, less risky, and more usable based on our changing needs.

Now, let’s apply that same thinking to software deliverables in general. To get value from a software platform, we need a base set of features that the customer will require to purchase or use the platform. This minimum set of features is our MVP.

When new platforms or software are being dreamt up, the team will need to be assembled and introduced to the idea that will create the outcome. In many cases, this team won’t exist, and one will need to be assembled. Once assembled, the team will take off on the defined scope to produce the MVP. The scope typically comes with a defined budget for how much the team thinks it will cost to deliver the MVP.

From Project to Product

Following this approach, projects turn to products at the point where the team has delivered the first MVP of the product. Once the product is released to the customer and value has begun to be measured, the team will start to iterate on features to add additional value to customers or reduce risk as the product matures.

This iterative approach requires an iterative mindset with a stream of funding to fund the capacity of the team to iterate.

Products in Decline

But, as we’ve laid out in the product life cycle and the software product life cycle, all products will decline in use and value. This decline has a direct impact on the resources used to curate the product, which translates to a reduction in those resources. As products reach the “Decline” stage, software product teams begin to lose the prioritization of features and consequently funding for the team.

From the inception of the idea through the creation and growth of the value to the ultimate reduction and elimination of that value, the software PLC shows a life cycle where the project creates a baseline in which the product begins to return value from the initial investment. The product then follows the PLC through iterations and investment to the demise of the product and the next idea. This relationship is the true project-to-product evolution.

Project versus Product Oriented Software Delivery

The table below further clarifies the different approaches and associated tradeoffs.

In our next post, we lay out our advice for getting starting with your project to product transformation.

Or you can download the full Moving from Project to Product white paper for free here.

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

• 
• 
•