Edited December 2013.

Each time I encounter someone who confuses project management with product management, I react with surprise and concern.

  • I become surprised because people seem to think because the words “product” and “project” have a similar sound, that they must have a similar meaning.
  • I become concerned because the two roles serve goals that oppose each other, and because many companies suffer inefficiency because they fail to staff one of the two.

Project thinking is simply the wrong mindset in a commercial software product company.  Product thinking is the answer.

Please, allow me to explain.

Product managers are responsible for market success of a product offering, which must address problems felt by a segment of the market that is willing to pay to solve, from inception to sunset.  The product’s lifecycle may be years or even decades.   “At their core, products are the sum of benefits that satisfy a customer’s need or desire…” (ProdBOK – 1st Edition)

A project manager is responsible for driving a project from start to finish, with a defined timeline and resource budget.  The project team works together for a limited period of time and then disassembles when the project ends.  Projects are temporary, defined as “A temporary endeavor undertaken to create a unique product, service or result…” (PMBOK – 5th Edition)

Go on….

A project may deliver a product to market “successfully” if the delivery date is the most important criteria of success, but if scope is cut to the point where the product doesn’t solve the market problem, the product won’t be a market success unless additional projects add more capabilities to the product.

Despite the attention paid to delivery dates and market windows, there have been countless examples of superior products capturing commanding market share from a previous market leader.  The iPod became market leader despite releasing three years after the first MP3 player.  Facebook took command of the social media market from MySpace, which itself took the lead position from Friendster.

The evolution to Agility

In the last ten years, software development has become agile.  Product managers have always been agile.  Product managers have always needed to respond to emerging requirements, but software teams’ demand for “complete” requirements and change management led to failure.

Given an agile team, which agile project management methodology is implemented decreases greatly in importance to how well a market problem is solved, from the perspective of the consumer.  Scrum, Kanban and Scrumban all deliver functionality incrementally, allowing the product manager to solicit feedback periodically.

Once a product is in market, its buyers care that their problem is solved.  They don’t care as much how the solution was engineered.  Michael Butlitsky recently wrote in The World is a Product:

Cynical as it may sound, nobody today is weeping over the miserable slaves who died constructing the Egyptian pyramids and the other ancient wonders of the world. Nobody is trying to elucidate how effective production was. But everybody continues to be delighted by the results.

At the end of the day, a flawless process can lead to failure if the team is pointed at the wrong target.  A flawed process can lead to market success if the right problem is solved, “well enough.”  Agile processes recognize this, and are geared towards estimation techniques that become more precise as more is known, and encourage change along the way.

A Product In Market Continues To Grow

Once the first version of a product is built and sold to customers, those customers express latent needs for additional features and capabilities.  The company has plans for how the product will evolve to capture additional market share and market segments.  Each of these forces ensures that additional versions of the product will need to be developed.  These forces drive creation of a product roadmap that communicates its direction.

RELATED:  Duties of Product Manager vs Product Owner Responsibilities

Each of these additional versions can be delivered within a single project.

A Single Person Cannot Manage Market Needs AND Manage Projects

In commercial product companies, a single individual cannot be responsible both for the functionality of a software product, and the delivery schedule.  The seams this opens up are obvious:

  • The product manager pushes to include all necessary functionality, and the schedule suffers.
  • The product manager pushes to meet the date, cutting corners in necessary functionality and possibly ignoring some defects that shouldn’t be released.

Some teams staff their development teams with a single individual serving as product owner, but with no-one manning the store from the project management side.

This is a mistake.

Risks of Project Thinking

For a commercial software product company, project thinking contributes to several existential challenges:

  1. Limited funding.  Companies fund the development of v1 of a product, and subsequently have to make a business case to add features.  Adding features is inevitable and unending in a product company–why add to the interia?
  2. Reallocation of resources.  People can be moved around between projects pretty easily, taking accumulated knowledge with them.  This lowers product quality as the product evolves.
  3. Lack of buy-in.  People reassigned among products don’t feel a sense of ownership – they’re more like hired hands.  They don’t have to think about long term maintenance as they won’t be the ones to support it in the future.
  4. Encourage silo-ism.  Projects work well to keep people who are assigned permanently to other teams working together.  Another word for this is “task force.”  Nobody wants to spend their time working on those.

Project Based Funding Failure For Software Products

For companies evolving from the legacy “IT” mindset, you may be securing funding for products on a project basis.  This leads to a few challenges that Marty Cagan calls out in his evergreen post on the topic.  Primary among them, as mentioned above, is that strong products result from continuity of the team working on the software, and this continuity is broken up by organizing around projects.

The other one is that the “business case” that drives project funding approval is inherently flawed.  A green light given prior to any prototyping or user testing / concept validation is really premature.  Some projects that get well past that point simply should not. But it’s hard to know which at that point in time.

Set Yourself Up For Success

Ensure one person is not responsible for both delivery timeline, delivery content and delivery quality.   Consider your product as its own entity, not a series of projects.   With those items in mind, make the right decision for your business about the most suitable project management process given business constraints, and staff accordingly.

 

Image source: Flickr