Explore

A tale of "two products"

The Evolution of Novo Nordisk’s Digital Portfolio

Novo Nordisk stands at a crucial crossroads in its digital journey. Our current portfolio primarily consists of “Commitment Products” - systems that need to run and operate but will not need to change much over time. These platforms, like IOCCS or NovoDia, serve us well.

However, as 'customer-like behavior' becomes more prevalent among our patients, we need to expand our capability to build another kind of product: Products that require continuous improvements and pivots during 5-10 years to reach problem-solution fit. I suggest to call these products ‘Skunk Works’.

⁠

A proposed operating model for Skunk Works Products

Unlike Commitment products, our portfolio of Skunk Works type products (e.g., ObesityPSS, Apollo, DoseCheck, NovoConnect) need to embody the principle "You build it, you own it." Hence, these products will never be handed over to an operations team.

This fundamentally different approach to development and operations requires several key shifts in our ways of working:

1. Product Team Structure We need small, nimble teams—starting with just two people (a designer and a developer) and then growing to a maximum of eight people—with end-to-end ownership. These teams need to be empowered to move and pivot quickly as they learn. For these teams, we will need to minimize the classical roles of QA, compliance, systems management, and project management and ensure that these skillsets are baked into our technology.

2. Organizational Structure To allow for rapid decision-making by the people closest to the context, we need to eliminate mid-layers between product managers and the line of business, such as program management and strategy. Also, we need to minimize the use of advisory boards and steering committees, and instead empower the business owners and product management to reach out when they need to.

3. Data Approach Because only 10% of these kind of products will succeed and likely only after 5-10 years of improvements, we need to take a ‘nail it before we scale it’ approach to data. We need to accept imperfect ad hoc data setups during early stages so we move fast and focus on discovering product market fit. If we believe in a tighter focus on data in some products - we need to embed data stewards directly in the product teams full-time.

4. Implications for IT Architecture For this type of products, the emphasis in choice of tech stack should be innovation and creativity, not scalability and reliability. Particularly, we need to choose the IT architecture that attracts top development talent. At the core of a great product team is an empowered software engineer who wants to understand the business and users in depth. Those kind of software developers are rare - and they always insist on working with modern open tech stacks (e.g., Vue.js, React, Angular, Python/Django,...).

Most importantly - we need to create the technical tooling and pipelines that centralizes what is needed (APIs, component libraries, design systems,...), and then let the product teams themselves choose the particular programming language they use.

Conclusion

For skunk works, such as digital health products, there is a historical 85% failure rate and it has historically taken 5-10 years to reach the desired business outcomes (as showed with data in

this IQVIA study⁠

). So - to make that worth it, we need to take some big swings with huge upside for Novo Nordisk.

This document proposes a separation of Skunk Works form our other products (called ‘commitment products’). It proposes to have a dramatically different operating model for these - so they can operate with the speed and agility needed for truly disruptive innovation.

Importantly - if we in CDDIT do not make such a change to how we operate around these products, someone tech savvy in Operations or CSCA is likely to just spin out the products in a unit outside DDIT - e.g.,

like this article shows⁠

Questions you might have about the IT Architecture

Q1: How can we maintain and operate on different tech stacks across different product teams?

We might choose just one key stack, e.g., Django/Python on back-end and Vue.js on front-end. Then, we still need to operate these separate back-ends and front-ends - but that is common practice in product companies across the globe. Most importantly, the “you build it, you operate it” principle means that the product team themself have to carry this - no one else. That team needs to improve the product continuously anyway.

Q2: How do you ensure re-usability of components across products?

By using open technologies, we will have more re-usability opportunities than with a closed-source stack like SalesForce - because we can use the full global eco-system of developers as our supply chain.

Q3: Won’t testing, validation, and quality control be more difficult than if we used a vendor system like SalesForce?

Yes - we gain some complexity here - but good testing, validation, and quality control are done as code by the product team via, e.g., test-driven development practices. This is how the tech industry does it.

Q4: Isn’t staffing and outsourcing at scale difficult in an enterprise setting using these technologies?

No - I propose to use the most widely used tech stacks on the planet (Python and JavaScript frameworks like Vue.js). This is precisely the key reason for going with such technologies.

Q5: Won’t we lose speed in startup phases for products because they now have to define a back-end, core data model, standard integrations, DevOps processes, etc

At startup, we are proposing to start with one tech lead - so it is just one person choosing the technology - and that person will have the incentive to select the tech we already have used in other places for fast startup. I propose to let this one person make a judgment call. We will hire smart people and trust their judgment.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.