Episode transcript The transcript is generated automatically by Podscribe, Sonix, Otter and other electronic transcription services.
Hello, everyone; welcome to the Five Minutes podcast! Today we will talk about a very relevant topic, product management versus project program and portfolio management. You know, the sentences look very similar. All of them start with B, all of them have the word management, and they are quite related, but they are not the same thing. Many times a project is responsible for delivering or creating a product. Most of the time, a product that you will provide to your customer will come as a consequence or as a part of a project or a large program. However, this is not necessarily 100 percent of the cases. Many times you can have a product that just appeared by chance. Suddenly, an error-expected event created for you, a massive opportunity to leverage a product, and then a product that you never thought would be a product becomes quite a relevant product. However, of course, we cannot just wait and see if we will be lucky to have a product that will be desired in delivering a lot of value without proper thinking, because this, of course, is not very frequent. So most of the time, a project generates a product. However, a project always starts with the end in mind of a product. It's different. You introduce a product; you let the product grow. The product reaches maturity, and at some point, it can be six months. It can be 100 years. That product reaches a point where there is no business value-added anymore, that there is no client, or there is no one willing to use it.
And then it's time for you to decommission to retire that specific product. And this is why the two of them are different because in the full lifecycle of a product, you can have many, many projects and programs. The easy one is the project that creates the product, the initial product, and not an easy one, the project that will take care of the decommissioning. I know that if you work, for example, with technology, maybe when you decommission, you have a legacy and other aspects. But if you use and see this in capital projects, this is a massive effort. For example, if you have a hydroelectric power plant and you want to decommission it, it's a massive project. Of course, maybe it's not as complex as it was the construction, but it's extremely complex. You just don't just let it go. You really need to do a proper closing of the product. However, between the start and the end and the lifecycle of a product like a hydroelectric power plant or like a telescope or like a car, there are many times you need to develop products that will be adapted to that main product to deliver more value. So you add features, and you add this through more projects. So you do features, you do revisions, you adopt the product to different marketing circumstances, you adapt the product to changing customer behavior. For example, a car, you start developing it, for example, in the year 2020 and you release it.
But then, every year, you make revisions. Sometimes you are making big improvements; sometimes you are just changing colors or changing some small aspects. And this is exactly to make sure that your product will deliver value for the longest period of time that you can afford at the end. You need to revisit your production line and adapt this production line to maybe a different product. So they are very related, but the product will last until there is business value for it, and the project is the way that you conduct the business value of your product. I want to give you two examples now. The first one is Hubble Telescope. Hubble Telescope was not supposed to last the amount of time it's lasting. Why? Because the expected life cycle when they develop was much shorter. However, the images are continued to be wonderful, and it's still useful, and people are using them because it's still a possibility to deliver value. So you are extending the product life cycle by adding, I would say, new features, probably new computers, new software, new ways of adapting. Or maybe, for example, as they did a couple of times, sending the space shuttle to do some revision or fixing of the telescope, and these made the telescope last longer. A second example, very similar, is James Webb Telescope. They spent a massive amount of money and years to develop it during the launch. For some reason, I'm not an expert on that. They were able to save fuel from the telescope, and the expected lifecycle of the telescope that was supposed to be five years is now expected to be maybe eight or ten years.
So did you see the product lifecycle? It exists. For example, the lifecycle of the product exists only until that product delivers value. Maybe five years from now, we will be able to go to L2 Point Lagrange to point with spacecraft. I don't know how and refuel it. I don't know. Maybe this will become possible. And then maybe that product, James Webb, will not last only eight years, but maybe 20 years. And this is the aspect of uncertainty going and affecting the product and not an important thing. Some products, when you go to the introduction, and you go to the growth, the product does not deliver the business value, and you need to create products to adapt this or even to make an early retirement of that product. Because, for example, for some reason, the assumptions you use to develop that product are not there anymore. So this is so important because a lot of people think that we are talking about the same thing. We are not we are talking about, I would say, maybe brothers and sisters or maybe cousins, but they are not the same individual. Always think about that. So product management is very related to project management, but it's not the same thing. They may use some of the tools that are very similar, but they are not the same thing. Think about that, and see you next week with another Five Minutes podcast.
