Innovation Is More Than Technology

From the outside looking in, it is easy to think that innovation is about the technology. One important lesson I’ve learned over the last decade is that more often than not, innovation is about business and process models which enable teams to deliver more value, faster. The important innovations may not necessarily be the technology, but the forward thinking from thought leaders that apply technologies to enable more efficient models.

In the life sciences industry, there is a core system called the electronic Trial Master File (eTMF) which is a system of record for documents which will eventually be submitted to the FDA for the approval of a new drug or medical device.  For over a decade, the dominant vendor in this space was Documentum.  Since approximately 2015, however, a company called Veeva has completely dominated this space and wiped the floor with the competition.  In that time, I have seen Veeva’s stock price jump from $14 to $270 and its dominance in the life sciences industry has become absolute.

What’s interesting to me is that at the core, it is still fundamentally the same system with the same capabilities as its predecessors (there are just so many ways that documents need to flow and need to be controlled).  There are even many members of the Veeva engineering and delivery teams who came from the various companies that had stewardship over Documentum and its distant cousin FirstDoc (EMC, OpenText, FCG, CSC, DXC, etc.); some of whom I had worked with or collaborated with through various paths of my career.  Yet Veeva has replaced “legacy” systems in customer after customer and has extended its reach beyond TMF to replace the multitude of vendors for other systems in life sciences such as clinical trial management systems (CTMS) and now even electronic data capture systems (EDC).  You could call it standardization by monopoly and you would not be wrong.

How Did We Get Here?

First, a disclaimer: I am not an industry insider, I have no insight into the inner workings of Veeva’s business and engineering teams, and no real connections at Veeva. But from the outside looking in and from first hand accounts from customers, there are a few things I can deduce.

Veeva rode on the wave of SaaS which removed a cost center for many enterprises: internal IT.

Veeva’s Vault product was built as a SaaS-only solution at a time when many leaders didn’t think that pharma and life sciences would shift in that direction due to concerns of data privacy and data control.  I remember early skepticism along the lines of “how will they validate it?”; after all, when customer auditors came to visit us, they wanted to see the physical servers (yes, we’d have to take auditors on datacenter tours).

But with SaaS, gone are the headaches and overhead associated with managing infrastructure, patching operating systems, updating software versions, updating physical servers, data migrations and so on.  All of these responsibilities could be shifted to the vendor instead.  Make no mistake, updating Documentum could be a multi-month, multi-million dollar endeavor coordinating internal SMEs and systems owners, IT teams, project managers, and external consultants.

Companies that had paid for bespoke configurations or builds of Documentum avoided upgrading because of the high costs.

One of Veeva’s key innovations is that they facilitated the shift in thinking around systems qualification that allowed decision makers to feel confident in migrating to the cloud.

As a SaaS, Veeva delivered only one product which could be configured, but not customized.

While Veeva maintains multiple versions of the API, it is designed in such a way that the versions maintain version-to-version compatibility.  But there is only one TMF product which sits in the cloud for all customers.  It doesn’t get customized, it gets configured.

This is in fact a welcome restriction for many customers who experienced the first hand pain of spending millions to deploy a bespoke version of a commercial-off-the-shelf product only to find that 1) their business requirements weren’t actually that unique, 2) in doing so, it created a barrier to upgrading and improving processes and general quality of life for the end users of the system, 3) it created challenges when regulatory bodies issued new guidance, and 4) when acquiring or merging with other companies, it created a huge challenge to reconcile two disparate TMF systems.

In delivering only one common product, Veeva promised teams that once they were on Vault, there would be no more data migrations, no multi-million dollar upgrade projects down the line, and customers would always have access to the latest and greatest version of the software.  Even if the cost of entry was high (the initial migration), the long term savings would be in the tens of millions of dollars.  This is the second key business decision they made: product over project, even if it meant leaving some revenue at the table.

Veeva designed their internal processes to deliver more value, faster and with higher quality.

Like a black hole, outside observers can’t actually peer inside of the phenomenon, but we can study the external signals that give us an idea of how the internal processes are structured at a high level.  Veeva is very open with their documentation and release processes and publishes their release notes publicly (I personally think this is a very welcome paradigm in enterprise software and a tremendous shift that aligns with how companies like Microsoft and Amazon are shifting their approach to documentation to be more open).

Veeva is consistently pushing out weekly releases which ultimately deliver more value and quality of life to customers compared to long, annual release cycles (or worse: project driven releases).

Veeva’s releases with a consistent cadence of 7 days.

While this may not seem extraordinary to anyone working in consumer software or other enterprise spaces, this is a Big Effin’ Deal in life sciences due to this little thing we call “validation” which in many “legacy companies” in this space means mountains of documentation (sometimes physical!), weeks of manual testing, and processes galore to make even small changes in the code.

Software release in life sciences generally follows the GAMP 5 V-model.  This means that in some cases, for a “legacy company”, even a simple quality of life fix such as changing how a button behaves or how a screen displays can’t be released out-of-band.  If the next release is 3 months away, even a simple quality of life fix has to wait for that train because the effort cost of validation and documentation is so high, it’s impossible to surmount for small changes.  This is compounded by how documentation has been managed traditionally with Word documents and PDFs. Legacy companies with legacy leaders and legacy thought processes don’t connect the dots between quality processes and revenue; they see such processes in a vacuum as an intrinsic cost of business rather than a point of innovation which can deliver more value.

Veeva took a different route.  A good chunk of their product documentation is web–based.  Being web-based allows many efficiencies such as automatic generation of the published document, more standardization, a focus on authoring rather than formatting, and easier accessibility for all parties.  For that reason, we see enterprises shifting towards technologies like Markdown which is now standard for companies like Microsoft, Facebook, and Amazon (though Veeva appears to be using a mix of tools which includes MadCap which is XML-based).

We can also deduce that there must be some significant test automation behind the scenes to allow such a consistent cadence of 7 day release cycles as there is no way to validate a system as significant and configurable as Vault every 7 days relying primarily on human effort.  All of this likely supported by a foundation of DevOps pulling together the build, test, documentation generation, and staged deployment automation.

Combining a SaaS with process innovations that allows weekly releases is a paradigm shift in an industry that would regularly see deployed software stagnate for years due to high costs of maintenance.

____

One could make the case that Veeva’s innovation was technology.  Indeed, their leadership embraced the cloud from the onset.  Yet that cloud was already a commodity, available to all.

Veeva’s innovation was to convince pharmas that it was safe to store their documents and data in the cloud and that in doing so, they could unlock more value.  For that, Veeva needed new controls, new processes, and new approaches to quality management in an industry where people’s lives are on the line.

Veeva’s innovation is not TMF, but the business and process models that allowed them to deliver those capabilities as a SaaS and shift how an entire industry engages enterprise software.  At the end of the day, customers don’t pay for innovation in a vacuum; the innovation must be intrinsically linked to value and it is not only the technology that needs to innovate, but the business and process models must adapt to meet the market — and some times drive massive changes in the market.