Building products in digital health is extremely rewarding for those working in the industry, but it also demands careful product planning and robust processes. At patientMpower, we’ve built product processes that we’d like to share with other health-tech companies. Drawing from a recent feature we launched, Alerts, we’ll introduce some of the key processes we used to build it, and a few important things we learned along the way.
It’s estimated that 545 million people in the world had a chronic lung condition in 2017, an increase of 39.8% since 1990. Our platform enables patients to manage their lung condition from the comfort of their home. With our patient and clinician apps, health data is captured at home and used to make better and faster care decisions. The COVID-19 pandemic has also accelerated the adoption of digital health solutions.
As patient numbers grow, small clinical teams are being tasked with monitoring more patients on our clinician app. It’s our responsibility to make sure that monitoring 100 patients or more remains quick and easy, that we deliver clear and prompt health insights, and that all patients are safely monitored. This became our next product goal, but where do you start in finding the right solution?
- Validate the problem we want to solve
- Ensure that the problem is worth solving and aligned with our business goals
- Define the right solution
Go wide, then decide
Our processes are built around the Zendesk triple diamond. We “go wide, then decide” when exploring the problem and solution. This ensures we are open to solutions and that the right features get built. This visualisation is missing activities that are important for digital health companies, such as clinical risk analysis, and we’ve added these over time.
Zendesk’s visualisation of their product and design process
Build a business case
It’s easy to get excited about a problem and jump straight into defining the solution. A common pitfall in Product Development is getting fixated on a solution, without taking the time to analyse the problem properly. Additionally, it’s important to look at whether it is a significant problem across all customer segments.
This is why writing a Business Case when exploring a new feature is crucial. It helps to ensure that you’re solving the right problem and that it aligns with your company goals. A Business Case is also a brilliant resource for sharing with your design and development teams, so they can understand why a product feature is a priority and how it aligns with your company strategy. Product documentation in general is an important part of your Quality Management System (QMS) and regulatory processes e.g. ISO 13485 – standards that are used in Digital health.
- Support the problem statement with research
- Measure the impact of the proposed solution
- Gain a clear view of the requirements needed
- Problem statement, Proposal, Use cases, Business requirement, Success metrics, Market information, Customer feedback, Strategic alignment, Risks and assumptions, Alternative options, Cost analysis, Project milestones
A problem statement is the foundation of a good Business Case.
Define the problem statement
A good problem statement clearly communicates what problem you’re trying to solve and why it’s important. It also helps to create sympathy and buy-in from other stakeholders. We love how Indeed explains what a Problem Statement is, which is based on 4 elements:
- In reality…
- As a consequence…
We took the problem of wanting to enrol more patients safely and translated it into a Problem Statement. It’s important that the problem statement doesn’t mention a solution, but focuses on the desired outcome.
Unlike Indeed’s template, we separated the “Proposal” element from the Problem Statement. This is because we want the Problem Statement to be devoid of bias. We used the following proposal to guide Product and Design on how to investigate and resolve the problem:
Proposal… we have data-driven health insights for when a patient’s health deteriorates (rapidly or gradually over time) and these are communicated clearly.
The problem statement is a great starting point, but what supporting evidence do we have? This is where market and user research comes in.
Carrying out user research can be done in many ways. We have a highly-skilled Customer Success team, who help us engage with clinical teams and patients regularly. For our Alerts feature, we used surveys to capture quantitative feedback, usability tests to validate our designs, and beta-testing to test our product in the real world.
We sent a survey to clinical teams in order to validate our problem and our proposal. We had assumed that most of our clinical users would use our new Alerts feature, but from our survey, only 60% of those surveyed said they would like to receive alerts.
Understanding our target customer segments
We had assumed that alerting clinical teams promptly via text message or phone call would be ideal. However, our survey results showed us that email and our clinical app were the best means of communication.
Backing up product designs with data
With this research, we realised that Alerts are better suited to some patient groups and clinical teams than others. Findings such as a preference for Email Alerts also helped us define our Minimal Viable Product (MVP). Of the 40% who preferred not to get an Alert, we investigated why and used their feedback to refine the product specifications further.
User interviews and tests are usually run remotely over video call. We record the sessions and use tags to highlight parts for analysis. We create tags based on a number of things like user journey stages, features, and the overall experience felt e.g. positive or negative experience.
An example of how we’ve tagged and added notes in Dovetail.
For a large feature like Alerts, we beta-tested with multiple clinical teams before releasing it to the rest of our users. Our goal with beta testing was to make sure that our Alerts feature provides an excellent user experience and keeps patients safe.
Prioritise patient safety
Our Clinical Safety Team brings together people from all across the company to discuss patient safety. In a nutshell, we assess every idea, problem, product requirement, design, development spec and release plan. We ensure that our product is reliable and easy to use.
For our Alerts feature, we wanted to reduce the risk of an alert getting missed. A missed Alert could lead to a patient not receiving urgent attention. A simple example of how we addressed this was to include the number of Alerts on a notification badge. This made it very clear when a new alert came in.
Define success metrics
What does success look like if we address this problem correctly? Setting success metrics ensures that everyone is aligned on what the goals are, keeps us focused, and lets us know if we’ve succeeded in making the product better.
- Clinical teams who set up Alerts enrol more patients
- High adoption of Alerts across our target customer segments.
Think about what metrics you need to track before your new feature is developed. Doing this allowed us to closely monitor product adoption and user behaviour. It also informed the next iteration of alerts.
Test, learn & adapt
- Help clinical teams with Alerts enrol 44% more patients within 6 months.
- Achieve an adoption rate of 71.4% for Alerts across our target customer segments.
Clinical Nurse Specialist in Portlaoise Hospital that started using alerts
Clinical Nurse Specialist in Portlaoise Hospital that started using alerts