The Essence of Product Life Cycle (PLC)

Fig 1 - PLC Cheat Sheet

The summary
Here is a cheat-sheet for the major steps in a product life cycle (Fig 1). It covers four ideas:

1. What are the phases in a life cycle?
2. What is the top level goal of each phase?
3. Who are the key actors?
4. What are the actors trying to do in each phase?

But what about agile?
Agile is a methodology for answering some of the questions in the life cycle. Agile is not a substitute for a proper life cycle process (more on this in a minute in "cycles repeat"). Choosing whether to follow an agile method or a more traditional waterfall method depends, I have come to believe, on the cost of developing requirements vs the cost of validating those requirements (Fig 2).

Fig 2 - Agile vs Waterfall Development depends on cost.

• If the cost of developing your product to a point where the requirements can be tested is LOW, then it pays to adopt an agile approach. Optimize for speed to market because each iteration is cheap.
• If the cost of development or testing is HIGH, then it pays to invest more time getting the requirements right before paying to develop and test them. Optimize for learning per unit cost because each iteration is expensive.

The specifics of how much is required to get a testable concept vary from case to case. 

For example: The cost of developing and testing a deep UV optical system to determine if it can collect enough data for the detection algorithms to flag a sub-wavelength sized pattern difference is quite high. The cost of testing different parameter entry field orders to determine which one causes more users to follow the correct setup procedure is relatively low. Hence semiconductor capital equipment hardware is not developed according to agile methods while the software that runs the hardware can be developed in an agile way.

[More on this in an earlier post.]

Cycles repeat

Fig 3 - Iterations in a Product Life Cycle

Learning at each phase will determine whether to proceed to the next phase or to return to a previous phase (fig 3).

I think the most interesting part is that there are basically only two questions here:

1. Am I solving the right problem?
2. Is there a better approach to solving the problem at hand?

Under the right conditions, agile is good for moving quickly through the iterations required to answer these questions. However, agile methods, in themselves, won't guide you to ask the right questions at the right time - that is what a product life cycle is for.

Extra stuff:

The slides that these images come from are embedded below.