Project Management

Vs

Product Development

In recent years, there has been a growing consensus that developing software using a project management approach is always wrong and we should always be talking about product development  instead.  The general consensus is that if the software has a life after the end of the project,  it shouldn't be run as a project.

Whilst the vast majority of digital-first companies should embrace a more product-based approach, a project approach may still be appropriate in some situations.  Let's look at the benefits and limitations of each.

A Digital-first company:  a company whose main product is a digital / software product or service.

It may also mean a company that was set up and has always worked in a way that utilises modern tech and software tools...as opposed to a business where practices, processes and structure were established well before the digital revolution.

Is your software development initiative a project or a product?

Can't they be both?  Does a project not create the product?  In layman's terms, yes.  But let's use the colloquial terms of the agile software development universe.

There are several key differences between product and project approaches.

Product

This may be software or a service, but it aims to meet a specific need and will require ongoing maintenance and upgrades.  As such, Product teams stay together long term to ideate, build and run the product.  Unlike projects, which are about a near-horizon result, products are about now and the future, often long-term horizons.  There is no known end point and participants are learning as they go.  In Product development, the focus is more on creating a working environment that supports a  sustainable pace.  Even if everything seems predictable in the maturity phase, you don’t know when there’ll be disruption.  You can’t control the product lifecycle; all you can do is try to prepare for change.

Project

A project is a way of executing an idea. In practical terms, with a project you need to understand a lot of things before you start to reduce the vuca levels.  For example,  what time, money and people you have available, the expected quality and all the other constraints and drivers across the project execution. These all need to be outlined in the scope. A project is super focused on execution – if you deliver late or over budget, it’s usually not a success even if your story tells otherwise. Projects are temporary with a defined beginning, one or more milestones and a fixed deadline. When the project is finished, the team disbands and members begin a new project.  Projects often (wrongly) assume that the undertaking is of low complexity and therefore of high predictability.

A Product is still a Product regardless of how you try to build it

Note that an undertaking to develop and launch a product or service, even if undertaken as a project, is still a product.  At VFS we've seen, and helped to salvage numerous software products and services that were approached as projects.  Arguably they were delivered on time and within budget but as a product were either unsuccessful in the market or problematic to own.

One clear example to compare the difference between the two approaches would be the act of planning, building and selling a house (project) and that of planning, landscaping and maintaining a park (product).

Isn't the Product Lifecycle just lots of projects?

It can be argued that specific product initiatives can be approached as a project, with project techniques.  Two examples:

However, to consider the Product Lifecycle as a series of projects is generally harmful.  It tends to drive short-term thinking where as it's far better for people to remain aware of, and also to make decisions with the big picture in mind.  Also, initiatives managed as projects tend to be run in a less sustainable way.  I.e. people working long hours to meed deadlines.