There’s a fundamental difference between a product and a project, even though both product managers and project managers often refer to themselves as “PMs.”
To clarify, let’s revisit the classic project management triangle: Scope, Time, and Resources.
In a project, the scope is fixed. You know exactly what needs to be delivered, and your job is to determine how many people and how much time it will take to achieve that. Once the deliverable is complete, the project ends, and the team moves on to other initiatives.
In contrast, for a product, the resources are fixed. You have a dedicated product team, and your primary challenge is deciding what to build—essentially, identifying the value you want to create.
Both projects and products benefit from some form of discovery, which involves figuring out what to build. For projects, discovery may already have been done, or the scope might be dictated by strategic decisions from leadership. For products, however, discovery is a core, ongoing activity for the product team.
None of this is groundbreaking—most people in the field are aware of these distinctions. However, the management approaches for products and projects differ significantly.
So, is it a product or a project?
One common issue I’ve observed is a lack of clarity about whether an initiative is a project or a product. People often use the terms interchangeably, which leads to confusion. To avoid this, it’s essential to define the following:
What is the goal of the initiative?
What are the success criteria? Are you measuring success by being on time and within budget, or by achieving customer satisfaction and delivering value? Hint: What are you reporting to management?
Is the scope fixed, or is the team fixed?
Will the initiative have a clear endpoint, or is it an ongoing effort? (Keep in mind, projects can sometimes evolve into products after completion.)
Do you have the authority to define the scope?
Is your team stable over a long period, aside from normal turnover?
By clearly identifying whether you’re working on a project or a product, you can set the right expectations and ensure everyone aligns with the initiative’s goals. This clarity helps teams focus, stakeholders understand priorities, and leaders manage outcomes effectively.
What I read
As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >800) at https://www.digital-product-management.com. These are today’s picks:
Product Principles so You Stop Struggling with Decisions: Teams need to align on what matters most. Product Principles help.
API architectural styles: An overview of the most popular API architectural styles.
Questions Every Founder and Leader Should Ask Themselves: Go-to questions for taking a pulse check on everything from product strategy to co-founder relationships to own decision making
Great perspective! As a project manager I like the distinction between fixed scope delivery vs ongoing team management. Projects end while Product Management in some ways is similar to Operations Management where the goal is continual optimization.
Product management results in a product plan that defines which products are needed, when they're required, and what properties they must have. Product development projects, on the other hand, focus on realizing these planned products - whether as part of a complete portfolio, as individual products, or as components of the broader portfolio.
Projects can also deliver outcomes beyond products themselves, such as organizational changes or strategy. While developing a product plan could be structured as a project (In this case, product management and project management would be identical), I believe it's more effective as an ongoing, continuous activity in most cases. As soon as it is an ongoing activity it is not a project anymore, even so it still requires resources and funding. Does this resonates with you?