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.

Can't Test This... A/B Testing

A/B testing is a very powerful tool for developing certain kinds of products. Here are a few thoughts on where it does and doesn't work.

Below is a high level flow of the testing cycle.

A/B testing works when:

• The cost of implementing ver A & B + 
• The cost of collecting "enough" data about A&B + 
• The cost of fanning out the "best" version, 

is less than:

• The cost of visiting "enough" of your key customers + 
• The cost of spending "enough" time with each of them to understand the full requirements.

Or framed a different way...

If it costs a significant amount to develop, test or deploy the thing you want to evaluate or

If you cannot get adequate information back from the customer base or

If you cannot get information back in a reasonable amount of time,

then there may be better development approaches than A/B testing.

The Essence of a Marketing Requirements Document (MRD)

A few thoughts about writing MRDs.

NOTE: The MRD should describe WHAT needs to happen overall and between parts. The MRD should not (usually) describe HOW all the parts get implemented - that is for the engineering design document.

1. Describe the end-to-end scope of the problem to be solved
2. Break the problem into logical sub-problems
3. Describe the inputs required to resolve each sub-problem. This includes:
• human interfaces for data input 
• one time 
• interactive / iterative 
• machine / data inputs from external data
• machine / data inputs from internal (transient) data
4. Describe what output should be generated by resolving each sub-problem. This includes:
• which data is needed as "the" output. i.e. the "permanent" data. 
• What is the expected input format of the consumer(s)?
• which data is needed to address another sub-problem. i.e. transient data.

All of this should be written with an eye to the system in which the functionality described by the MRD lives.

• Every input is the output of another system, ideally described by an MRD (reference it if you can).
• Other systems may need the output of the system described by your MRD. Include these systems as examples in your MRD to give color to the bigger picture problem being solved.
• Human input interfaces (User Interfaces), Machine Input interfaces (APIs) and Permanent Data stores (HDDs or Databases) may be shared between multiple systems. If they are, or should be, note that explicitly.

One obvious challenge, given the recursive approach to MRD writing given here, is figuring out where to stop.

How big should the scope of THE problem be?

My experience: when in doubt, make the scope too big. Then scale back the scope during reviews based on feedback from the stakeholders.