What does it mean to move from projects to products?
Cerys shares some great reads on the shift from project to product that accompanies agile transformation, and some hints for non-technical teams overwhelmed by the journey.
As organisations work through the transformation efforts needed for increased agility, some of the required mindset shifts can easily be forgotten in the flush of initial speed, breaking things (with permission 😉 ) and training - and then abandoned.
One mindset that is underestimated, especially for non-tech teams who may see transformation as a distraction from day-to-day responsibilities, is the shift from ‘projects’ to ‘products & services’. Not only does this change the relationship you have with your customers and colleagues, but also the fundamentals of long-term value creation. But what does this mindset shift entail?
Where to start?
First, let’s deal with some basics. What’s the difference between ‘projects’ and ‘products’, and why does it matter? Nick Brown does a good job of stacking the two up side by side (as well as providing some excellent insights into the journey at Nationwide):
Project — a temporary endeavour undertaken to create or deliver a solution, service or result. A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.
And
Product — something that closely meets the demands of a particular market and yields enough value to justify its continued existence. It is characterised by its benefits, features, functions and uses that satisfy the needs of the consumer.
It’s not uncommon for non-tech departments of large organisations to examine the complexity of what they deliver through the current project lens and then struggle to understand how to chunk their work into product teams, families and beyond for effective delivery.
John Cutler’s infographic on the journey towards becoming a product team is illuminating in this regard - I have seen many non-technical teams who get stuck around the ‘Agile’ with silo release stage, only iterating and transforming in the build and test phases, unable to make the leap from one-off project delivery to becoming a long-term team focused on a product that must continually evolve to keep pace with the organisation.
Continuous improvement and learning as you iterate are essential to keep broadening the scope - but for non-tech teams, the key here is deep discussions about what each stage means in the context of your own way of working. What does ‘release’ mean in a strategy squad? What does ‘test’ mean to a governance group? There are no handy guides to teach this, so each team has to do the work - identify the customer, develop true empathy, define the problem you are trying to solve, etc.
Learning, learning… and more learning
Another fascinating read packed with practical insights comes from the write up of the experiences of the GSK Tech Team as they worked towards a product-centric operating model. In particular, their key shift areas give teams starting out a great place to challenge themselves:
From temporal project teams to stable, cross-functional product teams
From a focus on delivery of outputs to measurable outcomes and objectives
From long waterfall delivery cycles, to agile fast feedback loops
From delivering for the business to delivering and partnering with the business for the customer
Teams intent on moving to truly new ways of working must be able to discuss these points together in detail. By increasing their psychological safety, addressing barriers and engaging senior leaders in a discussion about the support their need in order to perform at the highest level, their iterative journey will not falter at the first sign of the old way of doing things re-emerging.
As the team at GSK Tech also highlight:
Our journey has required us all to commit to being a learning organisation, as the path of transformation isn’t always linear. From senior leadership to individual contributor, we have all invested in learning and experimenting with Agile and DevOps fundamentals and frameworks, as well as product management skills and practices. Most importantly, avoiding cargo-culting by taking the underlying principles, and applying them appropriately to our local team or departmental context.
Being too busy to learn is no longer something that individuals, teams or organisations can afford, but it continues to be a siren song for many, overwhelmed by the new paradigms unleashed on their day-to-day experiences.
For those looking for more case studies, the story of the Startup Lab incubated inside an agency at Kwamecorp in Lisbon is also insightful.
Organisational Immunity to Change
This is a hard transformation to effect in only one part of the organisation. All of our experience experimenting with agile teams has shown us that the greatest potential failings are where agile teams meet a traditional line organisation structure - also true when moving from project- to product-focused operating models.
Robert Galen’s insights into the key organisational differences, and the incompatibility of the two mindsets sitting side by side, highlight why product-centric transformation for non-technical teams needs a greater focus for large organisations to take the next step. His final podcast recommendation should also inspire new areas of exploration for you and your team.
Remember that mindset shifts are hard, never linear and take time. You and your team will need a discipline of dialogue, learning and feedback that takes consistency and dedication to build. But this mindset shift from project to product is a key grassroots shift that your organisation needs to embrace to become the agile, digital, innovation hothouse that your company’s future needs.