Monday, March 25, 2013

Am I A Product Or Project Manager....?

There's so much chatter in the world about Project vs Product Management. It's a question which many people do and will continue to get mixed up.
Most of the arguments are really drawn out and subjective. It's much easier to define than: 

"...well a product manager does X, Y, Z and a project manager does A, B, C..."

and more more precise than: 

"...well a product manager answers 'why' and a project manager answers 'how'..."

To determine if a task or process is project or product, ask yourself: 'Is this task or process....'
  1. ... primarily focused on customers and markets?
  2. ... have the customer involved?
  3. ... delivering value to the customer?
If at least 2 of the answers above are 'Yes' then it's Product Management - otherwise it's Project Management.

Product Is An Invariant

Another easy test of if a task is Product or not is if, or how, it changes depending on how an organization is structured or its size. An effort related to Product is the same no matter the organization size or type. The parts that do change are project management. 

As the examples of Project vs Product efforts are described next, think about how it might be different between organizational types (a horizontal 'enlightened management' style vs a vertical, command and control style) and the size (1 person or 1 million). You'll find that a Product task, such as cohort analysis, exists regardless of the organization and doesn't change much; whereas a project task, such as wire framing & stories, will vary greatly and may not even exist in some organizations.

Without further ado, some examples....


Project Management

Agile is an engineering discipline: a framework for communication and getting things done within an organization. I only recommend Agile to an organization in which communication is ineffectual, members are disconnected and / or members cannot be trusted. It does not care about customers (directly).

Creating Personas & User Stories

Project Management

Personas are a way to fill the gap of educating the organization of who our customers are. Besides being a bad idea, they don't actually involve customers; rather, it's just an abstraction of a customer so project members have a point of focus to communicate around. It's to make sure everyone is on the same page. They are qualitative, subjective and not actionable. 

Cohort Analysis & Multivariate Testing

Product Management

We are analyzing customer behavior to give us an understanding of how our product is being used and what needs to be changed. It's only concern is the customer and meant to give us an actionable metric on what is working and what isn't.

The Product Vision

Product Management

The product vision is a process which involves thinking about topics such as customers, markets, revenue and solutions. It involves customers because as you come into contact with customer, it will change. The product vision is born from the customer and markets; it tells you what to do with your project and what comes next.

Wireframing & Storyboarding

Project Management & Design

Customers do not come into contact with wire frames or storyboards - ever. These are never directly affected by customers. They are a way for a team to communicate and collaborate around design. It's an internal, intermediate step between when analyzing customers and delivering design to customers.

update: two great interviews by Ryan Singer and Joshua Porter destroy the notion of wireframing as being helpful and how it's not product.


Project Management

As I've written before, roadmaps are not only a bad idea but they don't involve customers or markets and don't deliver value to the customer. It's only focus is internal communication - a glorified TODO list.

Dealing With Stakeholders

Project Management

There is no customer here. Customers don't know or care who stakeholders, if any, are. Working with stakeholders is internal politics.

Feature Prioritization, Addition and Deletion 

Product Management

In this process, you're considering the market and:
  • If a feature should be added.
  • If a feature should be deleted.
  • The the order in which to add / delete feature. 
It's not the speculative roadmap process. Feature prioritization changes upon customer interaction and market conditions. Think of it as a realistic, short term roadmap whose only concern is the customer and not anyone else within the organization. If someone needs to understand what your team is doing, show them the product vision and the feature prioritization.

Building a Business Case

Project Management

Again, there is no customer here. Customers don't know or care about business cases and are not directly effected by them. It's just building a pro/con list if should something be done or not. There's no customer input and nothing actionable about it.

Are you a Product Manager or Project Manger?

There are many more tasks involved in creating a product; however, this gives enough examples to allow you to determine if a task is project or product related. Most likely if you're a product manager, then you might have to do a project management task once in a while (e.g. dealing with a stakeholder). If you're supposed to be a product manager but frequently doing project management related tasks, then you have an organizational smell.

*update: someone made a great comment about Program Managers - specifically at Microsoft. As I understand and infer from reading and talking with former Microsoft employees, Microsoft handled their problem of product vs. project management by adding in another level of bureaucracy: the Program Manager. So what happened here (as at many orgs like this) the 'Product Manager' is really a Project Manger who manages products. The give away is to ask where they spend most of their time - dealing with the organization or with customers and markets.