In digital, guessing is the standard
A key success factor in digital innovation, invented by big players like Google and Facebook, is to run largescale A/B-tests all the time. In essence, such testing is the same as placing bets on all the roulette fields, in all casinos of the world, all the time and figuring out which strategy works best from there. Things go fast and rely heavily on user input. Digital companies build a minimal viable product (MVP) and improve through iterations, in order to ensure fast user adoption and high usage levels. Trial and error is an integral part of the game. Over time the true value of a new solution(s) emerges.
One of the major trends in healthcare innovations has been digitally supported treatment strategies. Because patient outcomes can be improved where a drug-based treatment fails, e.g. autism, dementia or ADHD, or where a medical device needs digital help. The promise digital health holds is huge. The question is: Can the approaches of digital companies also be used in digital health?
In healthcare you cannot guess
In medtech, the development processes are rigorous. Clearly defined gates strive for proven efficacy and maximal safety. There is no room for user-centered trial and error to ensure quick adoption from patients or HCPs. It is unthinkable to launch a premature beta version of a digital solution and ask patients, doctors or nurses to highlight the usability problems and solve them iteratively. It has to be (largely) right the first time. But how can you know the value of new digital solutions if you cannot test or prototype them beforehand?
Pharma is not different. In traditional pharma trial and error approaches make no sense even beyond medical and ethical concerns: Taking or prescribing a pill requires much less user-centered efforts. The clinical evidence of a treatment just is the value of the treatment. But when treatments are digitally supported or even replaced, things change.
In summary, in healthcare you need to know the value of a digital solution before it is being developed. You can’t put it out there and see what the market says. So, what can you do to speed up the healthcare approach for the digital world?
Stop guessing: Stakeholder-Focused Innovation
We at Vendbridge worked on several digital health projects over the past 2 years and developed an approach to combine the advantages of the two worlds: A structured and data supported process allowing iterative elements before committing extensive resources. We call it Stakeholder-Focused Innovation (SFI).
SFI starts by taking the perspective of the patient and of healthcare professionals very early on in the development process to design a Prototype Value Proposition that is sharp and compelling. To do so, we use the Jobs-to-be-done logic, a powerful mental model to take the stakeholders’ perspective and identify their most burning Pain Points independent of specific solutions. The process allows you to set your sight on key user problems first, before committing extensive resources later. 3 questions need to be answered by innovators:
Who are the stakeholders influencing the purchase and use?
What are the Pain Points of the most influential stakeholders, when trying to get a job done?
What is the most compelling narrative to convince these stakeholders?
1. Who are the stakeholders influencing the purchase and use?
In healthcare, many innovation teams face the challenge of delivering value to multiple stakeholders. Not all stakeholders purchase or use the innovative health solution, but many of them influence the adoption decision.
In a current case, where a pharmaceutical company wants to develop a digital solution to accompany the treatment of psychological disorders of teenagers, there are at least three stakeholders influencing purchase and usage: the patients, their caregivers and behavioural therapists. Psychiatrists, psychologists, pediatrics and family members of course also play a role, but as the analysis shows, less so.
In another case, where a provider of lab testing equipment wants to develop an integrated IT system, the key influencing stakeholder groups are lab technicians, doctors, nurses and patients. In a third example for a hearing aid manufacturer, the stakeholders are patients, family members, audiologists and payers.
Stakeholders differ greatly in their needs, their socio-demographic contexts, educational background, behaviours and goals they want to achieve in life. To get a deeper understanding of these stakeholders, we propose to develop a Jobs-to-be-done hierarchy for each of the relevant stakeholders. A Jobs-to-be-done hierarchy provides a clear and solution-free perspective from the stakeholders› point of view. That is the first step in applying Jobs-to-be-done.
The Jobs-to-be-done hierarchy template
2. What are the Pain Points of the most influential stakeholders, when trying to get a job done?
Adoption of new solutions is largely increased when they solve a relevant user problem. A relevant problem is a Pain Point that people have when they try to get their Job done. A successful innovation is a superior solution to that problem. Hence, the Pain Points along the Job-to-be-done of each stakeholder must be known. This provides the basis to spin the solutions towards addressing these Pain Points.
Pain Points can be uncovered at 3 different level of robustness:
Inside-out based on internal expert opinion
Outside-in qualitative, based on qualitative insights from a small sample of stakeholders
Outside-in quantitative, validated by a large sample of stakeholders
Each level has its merits and limitations. However, in many cases, the costs for an outside-in quantitative validation of the Pain Points before proceeding to development is a minor investment compared to the benefits of increased confidence and the reduced risk of failure during market introduction. More on our view on what a Pain Point is here.
Independently of the level of robustness we built a general framework into which user needs can be placed. To determine which user needs are Pain Points at the first level of robustness, do the following for each stakeholder:
Write down all the needs that you think are important to that stakeholder group. Take the list and discuss with as many internal experts as possible or in a workshop where they would place the respective needs in the Value Map (level 1).
To move up the level of robustness, this placing of needs in the Value Map can be supported by our validation process at Vendbridge with real data from stakeholders (level 3) or be a more informed placement process after running qualitative interviews (level 2).
The Value Map tool
3. What is the most compelling narrative to convince these stakeholders?
Knowing the Pain Points of each stakeholder is the basis for aligning the innovation concepts with the stakeholder needs. Each stakeholder group requires a value proposition that convincingly links the innovation with the Pain Points in a story. This story describes what value the innovation will bring to a stakeholder once it is actually built. And it will iteratively be adjusted, tweaked and improved as new findings about the stakeholders are gained and development progress is made. This way solutions can be prototyped before being developed.
The key ingredient of a compelling Value Proposition is the Promise. It links Pain Points and solution features and makes explicit what the stakeholder will get. The promise proposes the answer to a requirement or problem a stakeholder tries to solve, with specific features, services or evidential proof. Over the years, we have seen over and over again that this promise-centered Value Proposition framework is very powerful to guide the development process on digital services or physical products.
Promise-centered Value Proposition framework
Download pdf:
Comentários