Traditionally, software is delivered as a project: a thing with a start and an end date, and probably a list of desired features. The software is (hopefully!) deemed complete by the end date, the project is closed, and the project team move on to their next project.
A Product on the other hand is something that lives for an indefinite period of time, is hopefully seen as an asset to the organisation, and is something that should evolve and improve over time, addressing the needs of real users.
Too many organisations are still focusing their efforts on delivering software platforms with a Project rather than a Product mindset. We observe that this harms organisations in a number of ways:
We often see that the project approach encourages big bang releases, where significant chunks of work are stored up and released close to the project end date.
This leaves little room for iteration and improvement, as the software spends a small amount of time in the hands of end-users before the budget is exhausted and the team are disbanded.
We favour instead looking to adopt an MVP* approach, where the smallest increment is delivered to real users as soon as possible, so that their feedback can help to shape the most valuable direction for future investment.
The investment strategy for a product would usually look different to that of a project. Typically projects look to maximise their budget at the start, and would expect to run the budget dry by the time the first release is out.
*A Minimum Viable Product (MVP) is: "the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."
Encouraging teams to think of success in terms of "on time, on budget" delivery removes the focus of a meaningful commercial goal, such as how useful the product being delivered actually is to customers.
Instead, a team can become focused on delivering a set of features to a deadline, often regardless of how useful those features might be once the software is in the hands of real users.
We see much greater success where teams are more closely aligned with delivering against the commercial objectives of the product launch.
There are distinct differences between the roles of Product Owners and Project Managers - though we often see the latter assume the surrogate role of PO during a more typical project engagement.
Empowering a stakeholder in your organisation to take ownership of a product, set its direction, and assume overall responsibility for its commercial effectiveness is a great motivator.
It can often be observed that teams who are responsible for running a software platform in the longer term have a stronger vested interest in building something more maintainable and easier to run.
A project team ceasing development and handing over to an operations team to run as an ongoing concern is a surefire way to promote organisational silos and a lack of responsibility.
It's not true that the cost of change in software systems needs to increase over time. With a mature team having ownership of a product, a sensible approach to evolving and improving a system can be attained.
It's a common misconception that once a software system is built, providing you don't make changes, it can run in perpetuity without further investment. Software seldom sits in true isolation. It's likely to be dependent on third party libraries that may require patching and updating, it may have dependencies on third party services, the interfaces to which can change, and it's likely to increase the size of dataset that it deals with.
All of these factors can change how a software system behaves and requires a level of ongoing investment. Software rot is a challenge for most software products.
Too often we see customers stuck in a cycle of replatforming every few years. Almost as soon as one project reaches its conclusion, another project is spun up to replace it with the latest, greatest new tech.
By making use of appropriate software architectures, a software platform can improve and evolve over time, replacing smaller components as they reach end of life, but avoiding the baby with the bathwater scenario of throwing everything away and starting from a blank sheet.
We'd encourage organisations to shift their thinking from freeing up big budgets every few years to embark on yet-another-big-project ("we'll get it right this time!"), and instead look to set a reasonable ongoing budget to maintain, improve and evolve their software systems as a continual effort.
This approach also rings true for bringing new products to market. We don't believe investment strategies that encourage a big team upfront which is scaled down to a smaller skeleton maintenance crew is generally the best route to market. Delivery strategies like this too often burn their investment without getting anything in to the hands of end users; lacking a true feedback loop that can be acted on.