Can you clearly define the boundaries between Product and Project Management? When our Project Management work overlaps with a Product?
Hey Crizpers, I would like to talk about the difference between Project and Product. And the most curious thing to be clarified, when a Project Manager could be needed on a Product. If you know this in advance, let’s compare the attitudes and discuss them in comments!
Project VS Product
As you may remember from the first article ‘Who the Project Managers are‘, we have been discussing what a Project is and how to define, what is not a Project.
In the academic world by PMBOK Guide 6th edition :
“A Project is a temporary endeavor undertaken to create a unique product, service, or result.”
To refresh the content, I would also suggest hopping on this video where I am describing the case in more details.
Briefly, a Project is always temporary; we get more details about the Project with its progression; a Project is focused on delivering something unique; and it always should bring value.
Many of the above corresponds to the Product as well, however, there is still a significant difference present. I am about the ‘temporary’ characteristic. Basically, when we are talking about a Product, we have something constant, progressing and long-lasting on our minds. And this is right, as Products live and breathe as creatures, they grow, change and evolve.
However, Product Management suspects to be dedicated to the different goals than Project Management. Besides, we may implement many Projects for a sole Product. And obviously, a Product costs more, than Projects it consist of. In a couple of words, the general differences between a Product and a Project are cost and size. Also, there is one more differentiation factor present, a Closure Stage. We can close a Project, but not a Product, unless it is passing away as a bankrupt. Products are usually born due to Projects, but they are not being closed together.
Product and Project Overlapping
If we look at the Product life cycle, we would see the following high-level milestones that are applicable to Products in general. I am referring to:
- Product Conceptualization;
- Architecture Design and Prototype;
- Development and Testing;
- Deployment;
- Maintenance and Support.
Every step in the Product life phases are exciting and inspiring, and could obviously create conditions for Projects. However, if we would look at the overall process precisely, we would see that generally a Project brings a Product to the big world. Part of the instances from the Product life cycle closely corresponds to the Project life cycle steps which we will discuss separately later.
The instances that are common for a Project are Architecture Design and Prototype; Development and Testing; and Deployment. We can track the overall sequence of these actions in the real-life samples.
Project Piece
For instance, someone has an idea of a new business. He or she is rolling it back and forth, thinking of it, balancing and configuring a Business plan. The Product Concept is being born and polished. There are actually multiple scenarios what exactly could happen next, but for the sample we would stick with the most basic and flat one.
To release the new business model our business owner comes to, let’s say, an agency. It might be a construction company, a digital agency, a technology supplier, and so on, depending on the essential idea. And here the Project Management part comes in.
The company that receives an inquiry is taking over the Project and starts to build a design of a solution architecture, business processes and interface. This would take the Project Initiation step. Further on, we will dive into development and testing; launching the Product through the deployment and transferring the knowledge to maintenance. And this is the only part where the Project overlaps with the Product initially. As soon as the Project Knowledge transfer is completed, the we will close the Project.
However, to grow the Product will need enhancements, modifications and even improvements. And these pieces could take part as small Projects during the maintenance phase.
Release Cycle
As you may know, many Products are growing fast and seriously due to the regular features implementation within the Product Release Cycles. Every Release Cycle follows the specific procedure to be successfully and timely deployed. Every deployment contributes to an individual Product version.
Before the Product Release Cycle starts, the product team is working with the maintenance team in order to retrieve information that was shared by the end users about issues they are facing during the Product exploitation. Based on these feedbacks and on the internal research, the Product team makes a decision about what they are going to take in the next Release Scope. We will not get deeper into the Product Management here, but at this point we need to differentiate and specify the items our Product Team is aiming to change.
If the Product is a constant entity and the general thing a team concentrates on is bugs, this is a regular procedure common to many Products. However, should they pull functionality changes into the Release Scope, I bet this could bring some inconvenience and mess from the management perspective.
Do Products need Project Managers?
Here we come to the big questions that are common to the Product Teams. Does a Product team need a Project Manager? How could a Project Manager be integrated into the Product Life?
Frankly speaking, based on the Project definition and its purpose, a Project Manager should not be engaged into the regular Product Release work. This is a Product Team who is targeted on the Product maintenance and dedicating a Project Manager to this kind of activities could be a serious waste of funds.
Nevertheless, as we have discussed above, besides the bugfixing and issues resolution, there is also a portion of work that is related to the Product improvement and modification.
Every Product to be competitive and demanded should be modified regularly and thoughtfully. This might be new functionality, improvement of an old feature, or new UI implementation based on the UX research. All the changes to the Product can be and even should be perceived as Projects. This is another certain moment when a Project Manager will play a valuable role in the Product.
How to Approach
My suggestion here is to stop mixing Product and Project. Within the Product work and after the initial deployment we are concentrated on the maintenance and support of the existing functionality; on the research and analysis to identify the new market flavors and demands, and to create a solution that will help to adapt the Product to the new market and business needs.
As soon as we have a list of the desired modifications, they could be gathered and processed as an individual Project that is not bothering or overlapping the regular Release Cycles.
This approach would be a logical and efficient separation of two common, but so much different roles of the Product and Project Managers.
Do you think a Product Team needs Project Managers to work with them on a regular basis? What kind of collaboration of these two roles (Product and Project Manager) do you find the most effective?
Cheers!