To shift to product thinking, we first need to look at some of the side-effect of project thinking.
We discussed project versus product thinking early on in Chapter 1, The Software Industry and the Agile Manifesto. We concluded that although project thinking wasn't all bad, if not managed correctly it tended to focus on the wrong outcomes—meeting time and budget requirements instead of delivering something of value, often settling for something that was somewhat useful rather than something that truly delights our customer.
Even projects that we run with an incremental delivery approach can suffer from this, as we often get put under pressure to deliver on time or within budget, or both, which can result in a significant slip in quality.
Project thinking works for particular categories of software development, mainly those that are small. The general rule of thumb is: the smaller the project, the higher its chance of success of delivering on time, within budget, and within scope, as there is less variance in the estimate. This thinking was shown by the Cone of Uncertainty in Chapter 1, The Software Industry and the Agile Manifesto, which shows that the further you are from completing something, the less certainty you have.
Larger-scale projects often introduce significant changes to the organization, and you can view the project manager as the curator of that change. We seek to minimize the disruption that large change brings by using a change management process. As we introduce the change, we will need to provide excellent communication and staff training.
Once everyone in the organization is up to speed, our project team then hands over maintenance and support to the support teams. This includes business support, that is, helpdesk, operational/infrastructure support (the operations team), and enhancement/bug fixing support. Although not always the case, each support team usually looks after multiple systems. Once our project is in the support phase, this is known as Business As Usual (BAU) and the support teams will be collectively known as BAU teams.
The project team is then free to disband or move to the next project. Some transfer of knowledge will take place between the project team and the BAU team, but just like any handover, this approach often results in us losing much collective knowledge of the finished product.
However, a fundamental shift has taken place—our business is no longer supported by digital systems. Instead, our digital systems are interwoven into our business; they are either core product offerings for our customers or our operational backbone. Viewed in this light, the knowledge we gain about our core products is one of our organization's chief assets.
Project managers are concerned with time and budget, and to an extent, product managers are too, but our product management teams are also focused on delivering return on investment to the organization. They use a different set of metrics to determine the success of a product.
Decisions that product managers make will include being able to identify when peak value has been achieved from a particular work stream. It's also vital for a product manager to know if more value is likely; for example, maybe by extending this particular work stream by another month, they might be able to double the organization's return on investment.
Our organization needs to become empirical in that it should fund work on product(s) based on data. We treat everything as experiments, and we measure our successes and failures honestly and brutally. We become a learning organization.
To shift from project to incremental product delivery, we turn our focus from managing date, budget, and scope to managing outcomes. Change management is also handled incrementally, giving the people working with our product a sense of evolution rather than abrupt, sometimes disruptive change.
Regardless of our organization's size and how it is structured, we want to create the sense that we're all on the same team, moving in the same direction, regardless of product management, the project management office, technology, marketing, and so on. We need to break down the silos as much as possible.
The first step is to create an alignment of purpose; the outcomes for our product(s) should align with our organization's overall mission and purpose.
By shifting our focus to outcomes, we will start to look at our products and our associated teams as long-lived. One way to start is to foster ownership amongst our technology teams regarding our core products.
In the next section, we'll look at ways to create alignment within our teams.