by William Mann on March 13, 2013

Product Testing and Iteration

If you haven’t done so, take a minute to read Building a Clinical Evidence Package: Parts 1 and 2 first, as this post builds directly on them.

For all of you who have read Lean Startup, you know about the MVP. The MVP, or minimum viable product, is “a version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”. The entire point of this concept is to get a prototype out, make and test assumptions with your target market, and iterate the product based on those experiences, all in the shortest amount of time with the least risk possible. After all, in our case, who better to refine a product for wheelchair users than actual wheelchair users in the community? This falls under the umbrella of the emerging field of “Human Factors Engineering”. While I won’t talk much about Human Factors Engineering here, there are many great concepts that can be used in product development, like “user-centred design”. More information can be found at the Centre for Global eHealth Innovation, one of the organizations at the forefront of this discipline:

Depending on what your device does and the type of regulatory classification it falls under, you may not be able to do this at all, or you may require authorization from Health Canada or the FDA. For example, you clearly can’t produce a minimum viable product and beta test a remotely monitored pacemaker without authorization, even though it may fall into the classification of a mobile medical application. Not only is it invasive, but it would be unethical to give patients devices that are unfinished and have the potential to do substantial harm to a patient.

With all of that out of the way, if you have a device that would benefit from this type of testing, how do you go about doing it? First, lay out your business plan and highlight key touch points, and then target those touch points for feedback. For a quick example of this, let’s think about the steps you would take if you wanted to purchase a coffee from Starbucks:

  • You decide you want a coffee
  • You walk or drive down to Starbucks, order a coffee, and pay for it yourself
  • You drink the coffee and go about your day

In this case, all 3 touch points are performed by one person: you want it, you pay for it, you drink it. However, in healthcare, this is rarely the case.

Business Model

Let’s use wheelchair users who wish to purchase the SensiMAT for Wheelchairs as an example. Regardless of their location in the community, these wheelchair users all have occupational or physical therapists. The therapist is the authorizer, someone who recommends physiotherapy/assistive devices and begins the reimbursement process. If the SensiMAT for Wheelchairs is recommended by the therapist, the wheelchair user will then order it from our website. Reimbursement can come in several forms and if it is secured, then the payer can become the government, the insurer, the patient, or a combination of those 3.

What key points do we take from this?

  • We definitely need feedback from wheelchair users, as they will be the ones using the device
  • We also need feedback from the authorizer, in this case the therapist, as they operate in the key role of recommending the device
  • We need feedback from a reimbursement agency, as they will support the device financially
  • ALL of their feedback matters, because if just one of the three is unhappy, the product falls apart

That being said: go out there and find as many therapists and as many wheelchair users you possibly can and get their feedback. Do it any way you can: tap into your network, go to conferences, visit where patients or users with your particular target health state congregate, talk to special interest groups. Once you get feedback, package it and pull out main themes, and use this information to guide product development. Many of these testers will be your first customers and they may be willing to pay for a product that is not even necessarily finished. They can be good sources of word-of-mouth and networking opportunities. Finally, some agencies will require some kind of authorizer or patient demand as a requirement for reimbursement, and what better way to create buy-in than directly involving them in product development.

Why bother with all of this? Quite simply, it ensures that you aren’t throwing massive amounts of time and money into creating a product that nobody wants. Just remember that when you target specific patients or users for mobile medical applications, they can have extremely specific needs that you would have never been able to anticipate on your own. This method provides real and actionable feedback that reduces your product risk – directly from sources that matter most, and that’s powerful.