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:

1. Exploratory - A competitor has created something novel and potentially interesting ,and your company wants to see if it would be beneficial for you. This would require something akin to a software project: a focussed effort, delivery, review and assess whether to pursue it further.

2. Risk Mitigation - A new legislation is introduced and you need to purchase software to continue to operate. A software project can address these needs and solve the problem alongside the product approach.

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.