• A digital service is a product, not a project.

• It can be helpful to think about it this way: a product evolves over time.

A digital service is a product, not a project – and it needs to be managed that way. This is a key principle in our day-to-day work at Zuhlke, but the distinction isn’t always immediately clear to clients when we first introduce the ‘product, not project’ idea to them.<p>It can be helpful to think about it this way: a <strong>product</strong> evolves over time, continuing to create value for the business and adapting to address changing customer needs. An Audi A6 built in 2008, for example, looks very different from an Audi A6 built in 2018, but it’s still essentially the same product. It’s the same for digital services – organisations and their customers expect a continually fresher, ever-more functional version of an original product.</p>

A project, by contrast, is typically a one-off series of orchestrated activities, with a particular goal or outcome in mind from Day One, and crucially, a strict deadline or end date. While it’s true that most software has been delivered along project lines in the past, characterised by a waterfall approach that ends in a ‘big-bang’ release, this is a poor match for the demands of the digital age. What’s needed instead is a ‘product mindset’ that focuses on creating a rapidly evolving set of features and functions.

At Zuhlke, an important aspect of our Digital @ Scale solution centres on helping organisations that have already made some progress on their digital transformation journeys to assimilate that product mindset. This process is made easier by a number of complementary approaches that we assist them in adopting.

For a start, we help them to move away from large, monolithic IT systems, in favour of a digital platform based on a service-oriented architecture. Consisting of many small, independently deployable chunks of code, or microservices, this kind of architecture reduces friction when updates and enhancements need to be made, because these can typically be applied to specific, standalone services.

Then, there’s automation: smartly applied, automation tools can take the strain when an IT organisation faces a high frequency of small, incremental software releases, relieving developers of the burden of painstaking, repetitive work such as testing and allowing them to focus their time, effort and creativity on innovations and improvements.

Finally, we help teams work towards the DevOps goals of continuous integration and continuous delivery and deployment, which aim to dramatically shrink release cycles to the extent that small changes are happening at an almost constant rate. This pace of change is based on short feedback loops, in which a new release is closely monitored in production, so that audience response to it can be measured and acted upon promptly.

On the subject of teams, it’s important here to note another big distinction between projects and products. A project team is usually assembled temporarily for the project’s duration and then disbanded once it’s over. A product team, by contrast, is handed the responsibility for owning, building and running that product for its entire lifetime, and is accountable for its long-term evolution and value to the business.

In my opinion, the product mindset is the only way to guarantee a digital service that stays ahead of the game. And plenty of technology leaders seem to feel the same way: according to the CIO Agenda 2019 survey from IT market analyst firm Gartner, 55% of respondents say that they are moving from project to product delivery to deliver quicker business outcomes, improved customer experiences, reduced friction and more flexibility. Many more, I believe, will follow that path.