Transforming from a project to product-centric organization
Technology is playing a powerful role in the ever-changing landscape of healthcare and life sciences. Our everyday devices are tracking our health continuously and giving us insights that previously was not possible without a visit to your doctor. Data storage and computation have become commoditized enough to make it possible to utilize artificial intelligence and machine learning to discover and repurpose drugs at a much faster rate than ever before. At GSK, technology is critical for us to remain at the forefront of research and development and to expedite our mission to help our patients and customers do more, feel better and live longer. Technology at GSK is integral throughout the organization from Supply Chain Manufacturing, R&D, Commercialization, Consumer Health, and so much more.
Over the past few years, we’ve invested heavily in transforming how we approach technology and fundamentally how we are structured as an organization to most effectively harness digital, data and analytics to drive better outcomes for our patients and customers. The challenge with 120,000 employees is transforming at scale. Core to this is to switch our organization from a project-centric operating model to a product-centric model. Our transformation journey encompasses organizational change as well as skills, cultural and technology changes, enough to fill a book, but what’s most important is to understand what we’re shifting to, where we were and why these changes were essential to disrupt our previous operating model.
There are 4 main focusses in our shift from project to product teams that describe our journey at GSK in the last 3 years:
- 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
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. To give an insight into how this journey has manifested across GSK Tech, below are four stories of our project to product transformation from four different parts of the GSK Tech organisation.
From temporal project teams to stable, cross-functional product teams — Kelly Ellis, Consumer Health
Projects and programmes are organisations set up to deliver a specific aim, with the assumption that the output — go live — will deliver something that remains valuable in the long run, so that we can all move on and do “something else”. We live in a VUCA (volatile, uncertain, complex and ambiguous) world in which change is constant and where fixed big bang go-lives are unlikely to satisfy anyone, potentially on any time horizon, because they rely so much on assumptions and give us so little opportunity to test them. All the while needs, and opportunities, continue to change at an accelerating rate.
The process of understanding whether we’re building ‘the right thing’ requires a shift to a more experimental approach. One based on discovery of user needs and behaviours based on data and research to form hypothesis to be tested (sometimes called hypothesis-driven development). A test and learn approach.
Our approach, in Consumer Health was to create stable product teams with missions that hold true in the long run and that can be the north star for the continuous change journey. Finding these streams of truly long-term value can be challenging especially when technology innovation out-paces delivery cycles, and customer expectations evolve so quickly. In the Consumer Tech organisation we experimented in this new model by segmenting our customer base at a macro level and mapping their customer journeys; each product team being wholly responsible for improving the experience of their customer. The teams’ success is measured in our customers success. Customer’s needs will change frequently, but the customer themselves persist.
Consumer Tech’s Customer Segmentation — the basis for product teams.
An immediate impact of this switch was the realisation of how quickly organisation and team structure changes can optimise the value stream and reduce bottlenecks and handoffs in the flow of delivery. An example to highlight this is our previous structure to support our expert Health Care Professionals (these are professionals in their field that recommend or prescribe our products — their insight is crucial). Our interactions with experts spans various digital channels (e.g. email, video conference, CRM engagement, e-commerce, etc). Previously teams were formed around these channels and delivering experiments that were customer-centric and spanned these channels failed to deliver due to the complexity of managing cross-team dependencies.
There were many hand offs, roles and responsibilities were unclear and there was no clear lead to a drive a programme. Unsurprisingly progress was stalled.
Rearranging ourselves to break apart traditional technology functions and to re-conflate around the problems our customers experience was key to turning that around; creating self-sufficient empowered teams with resources to implement the needed change fast. In our journey to make this transformation each barrier breakthrough also brought a new, larger constraint to consider. Where we had been successful in re-organising ourselves, we have immediately realised our need to improve our relationship with the wider organisation. Within Expert we aligned with our stakeholders to ensure our Business & Tech teams act as one team and we have united around shared strategy and goals and manage a single backlog of priorities.
As a result, our Expert and Influencer Portal Team went from stalling to flying, in the first 12months (2020) releases were reduced from every 3 months to every 2 weeks for our Global Health Partner site, unique visitors increased by 300% to 2.5million and registrations doubled, with 69% new reach.
From a focus on delivery of outputs to measurable outcomes and objectives — Graham McCauley, Pharma Manufacturing Excellence
Good product teams do not confuse effort with results. Project managers love milestones, deliverables, progress charts, many ways of measuring activity, designed to ensure the business get 100% of the resource it is paying for. Even with agile methods we have invented ways to represent activity e.g., sprint burndown reports, control charts, epic and release burndown charts etc. These are all good measurements of team efficiency but do not represent the overall objectives are for the product nor do they measure the value or outcomes that the product delivers. We have all seen ‘IT Projects’ in the past that have been delivered on-time, on-budget, delivered with clockwork efficiency, hailed a success only to see limited user adoption, low business impact and over time they become disused white elephants.
For over a decade the idea of a paperless factory has pervaded industry, none more so than in life sciences where paper plays a key role in documenting the regulated manufacturing process for each batch of medicine produced. Many attempts to reduce or eliminate paper from the manufacturing process have had limited impact. Adoption has been slower than many would have anticipated given the technology enabling paperless factories has been available for many years.
Only after the organization moved to a product centric operating model and we defined the business outcomes needed from our ‘paperless product’ did we begin to see a step change in success. Moving from purely project tracking metrics like time & cost to business and end user outcomes like operator errors avoided, operator time saved, % right first time transformed the way the product team thought about what needed to be delivered. Collaborating more with end users and the business process owners enabled the development of a product through several agile iterations that more accurately met the business outcomes and end user needs. The resulting product was prioritized only on what the business and end users needed, adoption was high as the value from the product was clearly seen & understood by the business and end users.
At this point using agile methods to increase product velocity really becomes important and the metrics and rituals that drive team efficiency enable a valuable product to deliver more value, but it happens in that order — you need to develop a valuable product first before driving more value through agile efficiency.
From long waterfall delivery cycles, to agile fast feedback loops — John Muller, R&D Tech
For very large enterprises, this journey to product orientation naturally progresses through similar steps. A legacy of long waterfall delivery cycles left us with very siloed departments who saw each request from customers as one-off efforts. Switching to cross-functional product teams with a product mindset has resulted in a greater focus on smaller, more iterative experimentation (Minimal Viable Products) but the infrastructure was still very fragmented and supporting operations teams were siloed. The next progression came as a result of deeply understanding blockers of flow.
When a big company starts this transformation in earnest, it quickly learns that teams cannot be quick if they are constantly waiting on external blockers in the value stream that are dependencies for their products. Provisioning infrastructure, firewall rule changes, adding a subnet, standing up a data warehouse, and injecting secrets management are all examples of work that was still being handled in a traditional IT service management ticket style. Often owned by different teams. The next step was recognizing that distributing that responsibility across to every DevOps team didn’t make sense. When 88 product teams are all creating their own audit logging framework, you know that something is broken.
The solve? Take a platform-as-a-product approach. This is a precarious step for large legacy enterprises because platforms take some autonomy away from DevOps teams. Though this is never our goal as we strive to balance autonomy and alignment. The key to making it work is to force the platform itself to be two things: cohesive components that can be used as individual products, and self-service products in their own right. Having your platforms, be it infrastructure as code, a middleware platform, or data platform, become self-service products allows for both freedom of choice and removal of duplication through standardization.
But the biggest benefit that the platform approach provides is the opportunity for mastery. In R&D, GSK has 88 DevOps product teams. Each of them needs data storage, even when their product is customized SaaS software. One of these teams was a pre-existing big data team working through advanced analytics on Hadoop, and this team has the experts on data storage technologies. Their expertise wasn’t just the ecosystem, but also years of first-hand experience in performance tuning, debugging, disaster recovery, and maintaining an SLA for data storage. So we carved out a self-service product, Scientific Data Store, that allows other teams to provision storage in a variety of formats, structures, and cloud options.
Accounting for benefits for platforms is hard; who knows exactly how much time 88 teams would have spent reinventing the wheel of modern cloud storage? We are certain that none of them would have storage layer as robust, flexible, or manageable as a result.
From delivering for the business to delivering/partnering with the business for the customer — Sameer Gohil, Commercial Channels, Pharma Tech
Deep knowledge of our user community, their drivers, and the outcomes they are trying to achieve allow us to build better products. We are making the move from delivering specific lists of requirements and features, to becoming product teams that understand the customer, their jobs to be done and the measurable outcomes that we need to achieve. Cross-functional teams are then empowered to ideate and experiment iteratively towards a solution.
For our US e-commerce platform, the tech team worked collaboratively with key stakeholders to define a vision for their product as well as define key goals for the product and how they will measure the success of these goals. This has made it easier for teams to align on which experiments to prioritize and work on to best deliver the defined business outcomes.
The first step of the new way of working was for all the stakeholders to work together on building a customer journey map. This collaborative approach has enabled the product team to identify gaps in their roadmap by visualizing the roadmap from a user-facing perspective rather than an implementation perspective. The journey map identified potential customer problems that we did not previously know existed and allowed testable hypotheses to be built to determine whether there were truly opportunities for improvement. This contrasted with the previous approach of working through a list of detailed requirements from the business. The result of what might seem like a small change is a dramatic increase in alignment across teams and way of finding valuable experiments to work on.
Examples of new features added to the product to help customers with their job-to-be-done include “reminders”, marking items as “favorites”, and account based reporting. These have resulted in a 30% decrease in abandoned shopping carts.
“[We] are very much a part of the process in identifying the next most value add feature. I would highlight the strong partnership between tech and the channel operations team where we are very much an enabler. Through collaboration with our stakeholders, we have been able to better formulate how technology can help us achieve our product goals.” — GSK E commerce product team
So, what’s next?
We have invested heavily in building the foundations for real agility. A tough challenge in a rightly heavily regulated industry but crucial to ensure we’re able to solve problems that deliver value for our customers and drive towards our mission to help our patients and customers do more, feel better and live longer. Our investment in cloud infrastructure for our product teams is empowering them to design and build experiments at speed. Coupled with investments in product discovery, user research and data literacy and democratization, our teams are now able to truly put the customer and data at the heart of what we do.
Our journey is continuous and ongoing. Teams across the organization are at differing stages of maturity and we’re by no means ‘finished’ but as with all journeys of continuous improvement — we never will be. Our commitment is to learning and growing together, sharing our experiences, leaning in and getting comfortable with experimentation and change.
Authored by: Mike Montello, Kelly Ellis, Graham McCauley, Sameer Gohil, Kieron Scrutton, John Muller, Joss Duggan, Ryan Tomlinson
