Many pharmaceutical companies are increasingly looking to innovate through the development of companion diagnostics and drug delivery devices, and/or services such as patient monitoring and adherence support. In doing so, they have tended to adopt development approaches for these products and services that mirror the phase-gate or waterfall approaches used for drug development and traditional medical device development. However, given the highly innovative, or breakthrough, nature of these products and services, agile approaches are better suited to achieve development and commercialisation success.
An optimal innovation approach
Creating breakthroughs, like innovative diagnostics and high-value wrap-around services, is easier said than done. Arthur D Little’s eighth Innovation Excellence Survey revealed that leading companies expect their share of revenue from breakthrough, as opposed to incremental, innovation to double over the next five years. However, the survey also found that 88% of business leaders were dissatisfied with their breakthrough innovation performances. Most companies lack confidence in their current innovation systems to produce significant results.
The underlying issue for these organisations, and the challenge for pharmaceutical companies venturing beyond traditional products, is usually that they are applying non-optimal innovation approaches to realise breakthrough innovation. Most technology-based companies have employed a phase-gate or waterfall approach to all of their innovation efforts. In fact, they have made significant investment in the design and adoption of these approaches so they would become rigorous and mechanical. Their fundamental goal has been to minimise variances (ie risk) from a well-understood set of requirements and a detailed plan that are both established at the beginning of a development project. As a result, they have created the perfect environment for incremental innovation, reducing cycle times and improving on-time delivery. Unfortunately, this well-honed model is not conducive to breakthrough innovation, in which requirements are rarely set in stone and uncertainty is not only the norm, but a vehicle to explore beyond the usual boundaries.
In the meantime, for the past two decades the information technology and software world has been applying its own, highly dynamic innovation model – the agile approach. For some time this agile approach has been applied almost exclusively to software development, and this has borne fruit: the software industry has consistently produced patents at three times the level of the next-most prolific sectors. Today, agile approaches are increasingly being deployed alongside phase-gate processes in engineering and R&D functions outside software, with positive results. Arthur D Little’s research reveals that companies that have successfully added agile methods to their toolboxes, and tailor their innovation approaches by the type of innovation, perform significantly better than those that stick to single, waterfall approaches.
A different twist
When applying an agile approach to product development the key agile principles remain the same. However, certain elements take on a different twist.
The iterative approach
The heart of the agile approach in product development is the use of a series of rapid, iterative loops, similar to an agile iteration for software. At the early ‘exploration’ stages of the development life cycle, each loop focuses on answering a key question that is determined to have a high degree of importance and uncertainty, in order to build a progressively clearer picture of the desired solution. Through these loops, the team is effectively building the user stories. A key artefact of each typically two to four week loop is a prototype used to test the part of the concept in question. Prototypes need to be fast and inexpensive – simple mock-ups, models, videos and simulations are appropriate. Prototypes are shared with a sampling of customers, the key questions tested and the results assessed to determine if the team can move on to a new objective for the next loop.
Teams
Clear roles and responsibilities and the right balance of authority and accountability are important for team success in an agile product-development environment. Teams must be nimble and the individual members comfortable with ambiguity and experimentation. In the product development environment, agile teams are multidisciplinary teams of specialists that expand and contract depending on their current focus. This would be different from the skills needed to do a technology-feasibility loop. To support this model, agile product-development teams are often put together with part-time or limited-time resources. A very small ‘core’ stays constant, and there is a designated team leader throughout the development cycle.
Governance
While governance is not often identified as a key element of agile software development, it is critical within product development. In the agile environment, governance acts less like a go/no-go decisionmaker and more like a coach to project teams. Governance also serves to mitigate ‘organisational antibodies’ that try to impede or marginalise breakthrough innovations. Loop reviews done at the end of each loop to assess whether the key question has been addressed are discussions between project teams and their governance, using poster boards, prototypes and other visual aids to facilitate the conversation. To enable this environment, it is important that an agile governance group is comprised of individuals who can foster a culture of experimentation and learning, a sense of urgency and agility, and a passion for helping teams jump over hurdles (versus governance being the hurdle itself).
Agile alongside phase-gate
The phased and agile approaches are distinct in their implementation, and are generally suited to different innovation objectives when applied in the context of companies with engineered products. We have seen companies try to integrate agile approaches into their existing phase-gate process by using iterative loops within each phase, while retaining the overall structure. Our experience is that attempting to integrate approaches will sub-optimise at least one of them. In our experience with pharmaceutical companies, the better solution is to run them side-by-side, so an organisation can apply the right approach across an innovation portfolio of both incremental and breakthrough innovation.
Case study: developing a breakthrough concept
A life science company was developing a highly innovative care delivery tool for physicians. The envisioned product was based on a new, potentially game-changing technology that was unproven at the desired application. There were many unknowns regarding technical feasibility, physician preferences and user experience. A series of iterative loops was defined to address several key questions, which were prioritised by their importance and degree of uncertainty. For example, one loop tested how to optimally incorporate the product into the physician workflow. During that loop, product mock-ups were created and introduced to physicians in a simulated work environment to obtain their feedback. Over the course of several loops, the solution was refined to yield the desired functionality.
Then the project was put into the phase-gate process normally used by the company. The result was the successful and timely development and launch of a first-of-a-kind breakthrough product. In addition, by employing the iterative loops early to test technical feasibility and physician acceptance, there was the added benefit of accelerating some of the development and testing activities that would normally have been left to the later phases in a pure phase-gate process.
Changing established practices
Breakthrough innovation is increasingly important for most companies, including pharmaceutical companies, given their growing interest in generating novel products and services to complement traditional drug products. However, outside the software industry, most organisations, especially those with complex engineered products and longer development life cycles, struggle to deliver it systematically. This is principally because the agile approach needed to realise breakthroughs is a challenge to the established practices that have served them well. We have seen how non-software product-based companies can successfully embrace agile, as well as non-agile, methods in a complementary way.