Using patient interviews to prioritize features for a health tech product

It was testing day of our design sprint, and we all were wondering if our prototype would hold up the rigor of the interviews that we had lined up for the day. Of course, our nerves were high, but that’s always the case, right? I started out the interview with some of the easy softball questions, trying to give the interviewee some time to warm up. That’s when our world came crashing down.

Me: Tell me about the last time that you've gotten sick.
Them: Oh! I haven't gotten sick in the last five years.
Me: 😮🤯😭

Let’s rewind things a bit. The healthcare company we were working for is a service that sends a Nurse Practitioner to your door when requested instead of going to urgent care or struggling to make an appointment with a primary physician, just like old fashioned house calls. The service had been running for a few months successfully, and the team was eager to scale the service using technology on the patient side to make requests more seamless. We had run through understand, created our critical path, held our expert interviews, drew speedy eights, mind mapped, storyboarded, and prototyped. Together, our team arrived at what we believed was an excellent solution for their patient side to request a Nurse Practitioner to come to their home or work. For testing, the team had lined up a small group of people who had already used their service and requested a Nurse Practitioner to their house or office.

Photos from the product design sprint

We were three interviews, a whole bunch of tacos, and one large bowl of queso into our day. Each one of those interviews in the morning had been informative for our team. They posed some questions for our team, but nothing considerable enough that we couldn’t adjust for our MVP. We were digesting both the things we had learned so far and lunch when Mr. Healthy started to blow up a large chunk of assumptions. They had used the service before, so if they weren’t sick, why did they already book for care to come to their house?

It turns out they were a business owner using the service to help people who didn’t feel great in their office. A majority of our assumptions and prototype were built around immediate families. I never ended up showing them the prototype that we had spent the last day designing and the last few days planning on; it wouldn’t have made sense for their use case. After the interview, the team hummed with new ideas on how we might solve this new understanding and development. Each of those ideas was written down on a post-it and organized, ready for us to begin another sprint.

Photos from the product design sprint

Out of all of the interviews we had that day, Mr. Healthy was the only one that truly invalidated our assumptions but that didn’t derail our MVP. The information we learned during the interview with Mr. Healthy was put into our backlog for us to solve for another version. The other interviews helped us prioritize features from our MVP prototype and feel confident in moving it forward. All of our patient interviews helped us surface surprising insights even if we didn’t act on them right away. Mr. Healthy certainly reinforced how healthcare services are very personal and accessed in different ways and how important it is to conduct interviews.