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.
Our users
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 can be 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 across patients and clinical teams.
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, as 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 is also an important part of your Quality Management System (QMS) and regulatory processes e.g. ISO 13485.
- 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 and we’ve been using their template for a while, which is based on 4 elements:
- Ideally…
- In reality…
- As a consequence…
- Proposal…
For our Alerts feature, 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 the Indeed template, the “Proposal” element lives in a separate section in our Business Case because we want the Problem Statement to be devoid of bias. We wrote the following proposal for our Alerts feature to guide our product and design team on how they can 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.
Challenge assumptions
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.
For the Alerts feature, we sent a survey to clinical teams across different customer segments, validating our problem and challenging 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 also assumed that communicating Alerts via text message or phone call would be the ideal method because it would be the quickest way to get through to clinical teams for any rapid health deteriorations. However, when we surveyed clinical teams they all preferred email and our clinical app as 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 communications also helped us define our Minimal Viable Product (MVP). Of the 40% who preferred not to get an Alert, we were able to understand 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, the feature being talked about, 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 provided an excellent user experience, and that it met our clinical safety standards and kept 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 being missed, which 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 so that it was very clear when a new alert came in.
Define success metrics
What does success look like if we address this problem correctly? Setting out 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.
Start thinking about what product analytics you need to evaluate your product before your new feature starts being developed. Doing this allowed us to closely monitor the usage of our new Alerts feature and give us an insight into user behaviour, as well as inform 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
Statistics emerging from feature follow-up with one hospital
