Product User Life Cycle (PULC)

Over the last years I noticed that there are many ways to describe a Product Life Cycle (PLC). All cycles are explaining how the product grows during a project(s). The product can grow into a good direction; still the user feeling might tend to go the other way. There seems to be some other cycle next to the PLC. Parallel to this cycle there is something I will call the Product User Life Cycle (PULC).

The existence can be shown in short words using the phases in combination with user feelings:
1. Requirement phase: the user is exited since after long time he is asked to think what the user really needs
2. Building phase: the first negative sounds are getting there as the user is confronted that some functionality might not be there on go live
3. Test phase: There are still some requests for changes, seems the user knows how to act in a project and knows much better how to ask for functionality
4. User Acceptance test (UAT) phase: The negative sounds from build and test phase are acknowledged, not all functionality will be there, even some main functionality
5. Production phase: there is on certain areas no direct match with functionality and wish which results in dislike of the system.

Though the user is involved on early basis still there is a negative grow of user feeling. (Off course not on your projects) In development methods the call for early user involvement was growing. And sometimes continues User involvement. Still did it control the feeling? What I noticed that on a certain time in a project the user was heard, a RFC was created and it was scheduled for the next phase of the product. Or user involvement was only granted in the UAT as the code was not mature and the fear for negative sounds would be bigger.


Isn’t it better to manage those sounds on early basis then at the End? I think so. I like the idea of showing the user parts of the application while building and testing and give him the notice that it is not as it should be and intended to give them the opportunity to confirm if it is as expected or if some changes has to be made. Isn’t it better to have those RFC's now instead of the UAT?

On a previous project I got in touch with Conference Room Pilots. This is a term which is used in Oracle's development method called AIM. For more information about it see the article:

Managing Successful Conference Room Pilots by Ed Estaugh & Craig Scollick


Quoted from that article:
"CRPs naturally lend themselves to progressively increasing the functionality demonstrated to the users. The figure below highlights three blocks of CRP sessions within the Build Phase to scale the functionality demonstrated from transactional activities (CRP1) through to end to end business scenarios (CRP3)."

Though there are some challenges using this approach as managing the perception of the user and learning the user how to participate. (And off course more.)

A great benefit was that the user became familiar with the project, product and the team. In the first CRP it learned how the system would look like without seeing the "end" system. Based on that pilot it was easier to define the needed functionality. In the next CRP it prepared the user how the system would act on their own environment with their own data. No customizations were there. In the last CRP also a climps of the customizations were given.

This early user involvement can also be accomplished in normal trajects too. Let key users test during Functional Acceptance Testing (FAT) the critical functionality with a user point of view and not only looking towards written (requirements) functionality. Those users will learn from the product and will be better prepared for the UAT. They even understand certain decisions and can explain it towards other users. The acceptance grade might become larger and the chance of RFC's lesser.

This might help to manage the "feeling" of step 4 and step 5 of the PULC. Negative sounds are confirmed, though they understand the decisions as they had the opportunity to give feedback. And they know that in some cases the wish changed. Only it changed after they agreed to it.

I am aware that this post doesn't cover my whole idea as it would be too large for posting. Still the essential meaning is expressed:

• There is another cycle next to the PLC
• Involve users also during FAT is not a shame
• Managing feelings during the project is better and perhaps cheaper then when the product went live.