Data science as a product
Bringing together analysts, data scientists, and customers to better serve patients and the whole NHS
Data science in healthcare is booming. Every day new advances emerge that promise to deepen understanding, improve screening or optimise treatments. But as this panoply of models grows, so does the scrapheap of potentially useful ones that have never helped a single patient. The vast majority of promising new models, even when published in prestigious journals and cited extensively, are never fully translated into clinical practice.
There are many reasons for this, and many potential solutions. Viewing a model through the lens of a ‘product’, produced and optimised for ‘customers’, is one potential solution.
At The Strategy Unit, our acute demand forecasting model for the New Hospitals Programme has been in use for nearly 2 years. The suite of apps, simulation models, bespoke functions and outputs that make up this ‘model’ has been constantly evolving since its inception.
This is a fast-paced environment in which to do data science, since the team are continuously improving the model alongside its active deployment. The NHP model is not ‘new’, and has already had considerable national impact, but there are a whole host of potential applications which we are yet to explore.
It is all too easy to get your head down and work away at the next issue in the backlog without realising that doing something else, something you may not even have thought of, could be preferable.
To avoid this problem, we have created a ‘product team’ for the NHP model.
Borrowing from the realm of software development and Scrum, our team has a Product Owner, a Product Manager and a Customer Engagement Manager, all overseen by a project director. The team is in its infancy, but almost immediately the need for it was obvious. The overarching goal of the team is to ensure that the model (and all its component parts) meet the needs of current and future ‘customers’, and prioritising work to ensure the medium and long-term ambitions for the product are met.
How we do this requires, first, a brief explanation of the roles of the product team members:
*Product Owner**: As product owner, it is my responsibility to ensure that the work the data science team does is moving us forward towards our shared goals. This means that I need to have a clear view of the work backlog, how each element relates to the vision for the product and understand the competing priorities coming from our stakeholders. I distil those into plans of action that the data science team can fulfil.
*Product Manager**: This person’s priority is to have a clear understanding of where we are now. Who are the current users, are their needs being met, what niche does the model fit into currently, who are the main competitors, what are the potential opportunities for growth and development. What are we good at, what could/should we improve? The product manager does not need to be a data scientist but needs to think holistically and be comfortable talking to coders, planners, customers and everyone in between. They have a key role to play in helping prioritise the data science team’s work and contextualising new requests.
Customer Engagement: How do we know if the model is fulfilling the needs of our existing customers? What are the pain points? How could we improve the offer? Gathering and assimilating this information is essential if we are to keep the model friction-free and fit-for-purpose. This role is very time consuming and iterative but is crucial to the model’s success and eventual impact.
Our product team works closely together.
We hold regular meetings and end up having ad hoc chats most days.
We create our own tools for planning, prioritisation and information dissemination, using whatever software works for us. Currently this means a combination of GitHub projects, Excel workbooks, Quarto documents and Canva. We’ve created a product vision and goal, adopted a prioritisation framework for assessing proposed new functionality, we’ve created Gantt charts and a bespoke product team backlog, and gathered hours of user feedback, all within the first few months of the team’s inception. All this user feedback is fed into the data science team’s work backlog, ensuring that it will be done as determined by our prioritisation exercises. Our current users know that their opinions matter, that we are continually improving a tool that is as intuitive, functional and impactful as they need it to be to do their jobs. Where the product team identifies new use cases for the model, the work to understand the implications of this are captured, examined, and measured.
Through conversation and research, we help the team to make decisions around whether a risky new path may be worth the work.
Although data scientists are excellent at building useful tools, conceptualisation of the needs of new users is a different challenge entirely.
We want our data scientists to do data science because they love it and excel at it – other tasks should sit with other teams.
Every iteration of data science work (we operate in ‘sprints’, meaning we release code every 4 weeks) moves us one increment closer to the ultimate vision for the product, and this journey is transparent, building the trust of stakeholders. The product team helps us sharpen the point of the spear, helping us clarify what we should do and why, and it does so without burdening the data science team with any extra workload. This frees them up to do what they do best.
Its early days for this way of working, but I believe we’ve already seen benefits.
The more our workload grows, the more important it is to have team members whose job it is to help steer the ship where we all want it to go. To realise opportunities and help us make the most of our work.