I'm a product manager, not a project manager

As a product manager, it is not uncommon to face confusion around the difference between product management and project management. The problems stemming from this range from the merely annoying, like being called a "project manager", to the truly disruptive, like being asked to run projects that have not been anchored through product discovery. In this article, I'll detail how product managers can handle this.

The main difference between a product manager and a project manager

The main difference is that:

• A project manager's job is to execute a defined project with a clear end date, whereas
• A product manager's job is to deliver product value* over time

From there, stems a few clear differences between the two roles.

*We define product value as "business value + customer value"

Defining projects and products

A project can be defined as a piece of work "that will require more than one action step to complete and that you can mark off as finished in the next 12 months" (from David Allen, author of Getting Things Done). For bigger projects, it can make sense to appoint a project manager.

A product however, can be defined as "a service or an item offered for sale". It often makes sense to appoint one or a few product managers to be responsible for improving that product over time.

Timing is everything

Since a project is limited in time, the project team is temporary in nature, and it is common that the project manager has to work with team members that are involved in the project on a part-time basis.

A product however, is subject to ongoing product management process, not limited in time, and that makes it practically possible for a product manager to have a full-time product development team. In fact, I will stick my neck out and say that the existence of a dedicated full-time team is crucial for the success of a product manager.

What to work towards

For a project manager, the goal is to complete the project, on time, on budget, and according to the scope set. There can also be specific results that the project aims to achieve, but these are assumed to be achieved by the actions specified in the project definition. Projects often follow the Waterfall methodology, with an upfront definition and actions laid out in a Gantt chart. If the actions are performed well but the results are still not achieved, it is not seen as the fault of the project manager.

For a product manager, the goal is to improve the product by maximizing the business value and customer value it generates. It is not known from the start what to do in order to achieve this, which means that product managers need to engage in discovery to figure it out. This means that the plan of action will change as the team learns and discovers insights, using for instance Agile methodology. A product manager should not be held accountable for any specific action performed, but for the results of all actions combined, i.e. what value has the product created for business and users. The measure of this success can be defined as KPIs, usage metrics, qualitative results, and so forth.

The implications on product discovery

Product Managers need to have a deep understanding of the business context in which they operate and the customers they serve. Without this, they will not be successful in creating product value over time.
Project Managers on the other hand have less need for such deep understanding since their scope is often already defined upfront. Research has already been done because without it - why decide to do the project in the first place?

‍
This means that product managers cannot start with prioritizing from a list of feature ideas. Or even from a list of user problems. They need to start with what's important to their business. For an early-stage startup, this might be to get their first 10 reference customers. For a scale-up, it might be to reduce churn on a specific customer segment or enter a new market. These things will vary from company to company and product to product. And there might be several things that are important at once. But they are crucial to understanding.

‍
Secondly, product managers need to understand the opportunities surrounding the business goals. To do this they need to talk to users. There's no getting around it. Once they know what users want to do (i.e. jobs to be done), what problems they face today, and what desires they have - then they can start generating ideas for how to deliver on those opportunities.

‍
Does what was just described sound familiar? Well, that's because I basically described an opportunity solution tree. Here comes the most important sentence of this blog post:  Whether it makes sense to work with an OST is the litmus test for whether you're a product manager or a project manager. If you jump straight into building a feature - you're a project manager. If you spend time doing product discovery - you're a product manager.

In the illustration of an opportunity solution tree above there's a solution called "Single Sign-On, enabling login with e.g. Google". Typically, the product manager would arrive at this solution after doing extensive product discovery. He or she figured out that increasing the visit-to-signup ratio is a top business outcome. After this outcome was formulated, discovery activities are done (e.g. users are interviewed) to figure out what the opportunities are relating to the desired outcome. The "problem of having to keep track of many passwords" is prioritized as an opportunity worth solving because the team has strong reason to believe this will affect the visit-to-signup ratio.

‍
Different solutions are considered and the team arrives at Single Sign-On as the best way to solve the problem, which hopefully achieves or at least contributes to the business outcome. From here on out, the workflow of a product manager and a project manager merges into more or less the same with the goal of delivering the project, i.e. the feature Single Sign-On, to the market.

The implications on product delivery

We recommend both product managers and project managers use a document for detailing how to deliver a project to the market. We call these documents "Epic documents". The document for the product manager would be called "Single Sign-On" and be generated from the OST, while the document for the project manager would probably have the same name but wouldn't necessarily originate from the OST (although we advise companies who use project managers to do similar discovery activities before committing to projects!).

The document is then used for detailing the "plan" of how to deliver the project, as well as to collaborate with key stakeholders including the engineers and designers. In Delibr, this document would have a structure similar to this:

To sum up the difference

Product managers should avoid being project managers

Being a product manager is at the same time an enormously important and difficult job. If product managers are pulled into unrelated projects, they are likely to perform less well in their core role, to the detriment of their organization.

Therefore, whenever product managers are asked to run projects they have not defined themselves, and that has no clear link to the metrics of their product they are trying to improve, they often do best in trying to politely resist.

If you are ever in that situation, you can refer back to this article.