Creating definition around a product's entire lifecycle is going to bring value to you and your team and I'm going to tell you why. The value prop;

• Provide a clear contextual picture of where the product exist and its interfaces
• To begin to elicit what the product should do and support
• Allow teams to understand how a product transitions from one stage to the next

I want to make some points from the outset here. One, this is a team exercise and all teams are different. Alignment from across team stakeholders; engineers, project managers, product team, etc. is important. In addition, not all products will have the same Lifecycles, it's all contextual. Lastly, this not a post about the product lifecycle that depicts growth, adoption, maturity, and decline. This is about a snapshot of a Product's Lifecycle, its capabilities, and interfaces.

The term 'Product Lifecycle' has two applicable elements;

• Product: The device, application, website, or system of interest
• Lifecycle: Distinct stages the product moves through

Two elements, simple as that.

In this context, the term "Lifecycle" is intended to convey a period of the product's life that is bounded by events, interfaces, and purpose. I know for myself examples work best for understanding something new so let's move to that.

Case Study: iPhone

Lets use an iPhone as an example product as it is well known and fairly complex being a product that is an integrated software-hardware platform. Now for a product like this I might define the Lifecycles as;

• Development: A cycle bound by the design and development of the product. Ends as the product is transferred to Manufacturing.
• Manufacturing: The process of procuring and constructing the product. Ends when the product is Retired.
• Distribution: The process of getting physical product from a manufacturer to the marketplace. Ends when the product is transitioned into Operation.
• Operational: The main part of a product's life where it performs its intended functions and the user interacts with the product. Ends when the product is Retired, or transferred to Maintenance.
• Maintenance: A cycle containing all things related to maintaining and servicing the product. Ends with the product is serviced and is returned to Operation, or is determined to be Retired.
• Retirement: The end of a product life, where it is removed from service.

You can begin to notice and understand how a product is to transition from one phase to another. You also can quickly begin to imagine what all the product should support throughout it's entire lifecycle. This becomes relevant for developing Use Cases.

• Development: Support prototyping, certification testing, user testing, and design documentation
• Manufacturing: Support part procurement, quality assessments, assembly, and storage.
• Distribution: Support international and domestic shipping, and storage. Support bulk shipping and individual shipping.
• Operational: Support phone calls, text messages, photo capture, photo sharing, web browsing, support regional setup, native mobile applications, connections over WiFi, etc. (this is a long list)
• Maintenance: Support part replacement, software updates, refurbishment, and device analytics.
• Retirement: Support product returns, recycling, and disposal.

We can also imagine the use environment (where) of the product within those lifecycles, and what it is expected to interface with. I'll spare you an entire list but some examples might be;

• Distribution: Domestic and international shipping conditions.
• Manufacturing: Manufacturing conditions, interfacing to a local network and test equipment.
• Operational: Outdoor and domestic home conditions. Interfacing with users, WiFi networks, Bluetooth devices, other iPhones, cell towers, wall outlets, personal computers, etc.

Hopefully by now it is more clear as what I mean by the Product Lifecycles, and perhaps you're starting to see their value. Now I know many of you are sitting there thinking, ''well I don't develop integrated hardware platforms, I build software that runs on a server, so this isn't relevant to me''. I am hoping I can change your mind.

Case Study: Instagram

Let's take another very well known product, Instagram, and think about how we could apply this same practice. Like I mentioned, the definition of a Lifecycle varies on a product-to-product basis, so what define for an iPhone is not the same for a mobile app. I've made a table to summarize an example of Instagram, this is definitely not exhaustive, but it at least can start to paint a picture.

Hopefully by now you are beginning to see the value in creating such a framework for the team to work within. Product Lifecycles offer a snapshot into the existence of a product as it move through the world. It provides stakeholders with context on what it should do and where it exist while it'd doing that. By adding in how it transitions from one phase to the next it becomes more clear how the product evolves.

Apply with Care

By now I am hoping you are asking yourself the question, 'how do I actually apply this and get teams to use this on a program?'. As mentioned, every team is different, but I think a great starting point is creating a simple table like the previous example shown in place where it is easily accessible by stakeholders across the dev team. Next, shop it around to the engineering team, QA team, product team asking questions like, 'Do we actually interface with this?', or 'How do you know the product is ready to transition to the next stage?'. Usually this starts to uncover some gaps in understanding while also give certain functions insight into different areas of the product they weren't familiar with.

As with anything new it takes time, effort, and some gentle encouragement to pull people along before they can begin to see the value in a new process or tool. When talking about challenges, use cases, user stories, testing, new features, etc. refer back to the Product Lifecycle definitions and try to use that as a tool for creating a clear picture of where and what the product is responsible for supporting.