Article overview:
Product managers are a key part of project teams, but their role doesn’t end when the project wraps up. Let’s look at the difference between the product and the project life cycle.
Table of content
There are often several (many) projects happening during the life of a product. First, the product is made – that’s a project. Then it’s improved or enhanced in response to customer feedback and market requirements. The product may ‘live’ for many years, being made more relevant or having more features added over time. Eventually, the product is disbanded.
The product life cycle – often called ‘cradle to grave’ is a broad look at the existence of the product from the first idea through to decommissioning and termination. The product manager is someone who acts as the guardian of the product throughout that time. They are responsible for working out what should happen next with the product, what features to incorporate or how the product should evolve over time.
A project team working with a product manager (or product team) needs to be aware of this because that specific project is part of a larger roadmap for the product overall.
Projects exist to deliver a certain piece of functionality or a set of improvements. While you might have teams working constantly on development, bigger releases may have a project team aimed at completing a set of features by particular launch date, for example.
The project life cycle starts with defining what needs to be done, turning those ideas into a workable plan (with timeline, budget, resourcing requirements, quality measures and so on), doing the work, and then transitioning the work to the live environment. Then the project is closed down and that particular work is over.
The product, however, continues. In fact, it might have existed long before the project team came along.
Let’s say the product already existed before the project team arrived on the scene to do the work to launch version 2.0. The product life cycle would have started the same way: someone had an idea for a product, it was created and launched. So far, so “project”.
However, the next part of the life cycle is very different to the project. Projects don’t normally have operational running included in the life cycle (programs might though). The product is made live, then there is a period of benefits realization and operation. During the operation part of the life cycle, there might be more projects launched to add those enhancements we’ve already mentioned.
The product life cycle ends with termination: the product is decommissioned and no longer in use.
Taking a product out of service can also be run as a project. When I have been involved in product decommissioning, it’s actually been a very interesting project with a lot of unusual aspects that I hadn’t had to do on other projects.
For example, data wiping from the laptops and computer kit that were no longer required, and migrating data into other systems that would need it (these were IT software products that were no longer serviceable). Then we had to dispose of kit in an environmentally friendly way.
When you start work on a product-related project, it’s important to try to understand the history. In my experience, that’s been key to understanding the stakeholders. They may be reluctant to try something they’ve already tried in the past – and it failed. They might have preferred ways of working, or define processes for getting things done, for example customer focus groups.
The project team also needs to look forward towards the longer term goals of the product: don’t build anything into this project that will make it harder to achieve other things on the roadmap for development. The more flexible the solution, the easier it is going to be for other teams to build on it later, whether that’s a software app or a new building.
It’s also worth considering how the project documentation is stored and archived. It will become part of the history of the product, required in the future, and the product team are going to want to look back on it to justify how decisions were taken and understand what features were perhaps not included this time. Make sure you have a project documentation strategy that makes it easy to file and find what you need in the future, with sensibly-named files and a folder structure that doesn’t leave your colleagues scratching their heads.
Projects may also need to incorporate elements of operational running, such as setting up a customer helpdesk or providing information to the teams that are going to continue to support the product long after the project team have moved on to delivering something else.
Finally, consider the environmental impact of your project. If the product is going to be around for another 20 years, what can you build in now to reduce the impact of the solution? That might affect your choices for materials or processing power, hosting, or something else.
The more you understand about the full product life cycle, the more you can be a better steward for the product throughout a project. While you might be moving on to lead something else once you’ve signed the project closure document, the product team have to live with and support the product for a long time: every action on the project should be made with them and the customers in mind so the end result is fit for purpose and a true enhancement.
Ultimately, you will achieve better value for the organization if you consider the product life cycle during project delivery and vice versa. Everyone wants the same outcomes, so when the project and product teams work together, you are more likely to end up with the expected benefits.