In Mobile Medical App Development, MVP is Important

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

Nope, I’m not talking about a Most Valuable Player trophy. The MVP to which I’m referring is minimum viable product, a relatively new concept to product design that’s been gaining worldwide recognition. It’s a way to launch a new business that’s gaining more ground with the explosion of mobile application development, a big part of what we do at Orthogonal. My role is that of project manager, directing our clients’ process and overseeing their relationship with the team.

So, what exactly is minimum viable product? We like Ash Maurya’s take: “The smallest thing you can build that delivers customer value (and as a bonus captures some of that value back).” It’s not always an easy process, and with the mobile apps in Orthogonal’s arena, it’s a tricky balance to get something out as quickly as possible while ensuring the app meets our clients’ expectations.

I was faced with this situation with a recent project at Orthogonal when we developed an app for the American Association of Critical Care Nurses. AACN Bedside is designed to work within hospital environments that may have internet connectivity issues, or in which employees may not be able to access a network at all.

AACN Bedside allows brand new nurses to understand things like EKG readings, pulmonary distress issues or how to recall settings on a machine by pulling up reference cards. No internet connection is necessary. Basically, anything a critical care nurse would want to help them in decision-making under pressure can be found on this app.

As it is with most apps, we faced our share of challenges during the course of its development.

1.) No Internet Connectivity – One of the app’s most useful features for critical care nurses on the go –  the ability to present information without connecting to a network – presents its own hurdles. This one required us to think differently about the entire process.

Typically, when you think of a smartphone app, you assume it will operate on a network. But when a network isn’t always available, you still have to be able to access content quickly and accurately for this app. This meant that we had to create the app to store all of the data locally on the device. At the same time, we had to make sure it didn’t take up too much of the phone’s memory. To achieve that, we shrunk the graphics, tightened up the interfaces and did a few other things so that using the app wouldn’t require the whole device to work.

2.) Approval Process – It’s impossible to talk about mobile apps without mentioning the almighty Apple Store. We learned a lot about Apple’s approval process when building the AACN app, including Apple’s recently tightened rules, interactivity mandate, broad appeal and extensive features requirements.

Sometimes it’s difficult to hit each one of these nails on the head. We were creating the AACN app for a very specific audience, with inherently low interactivity and straightforward features, which made approval challenging. At the same time, the app was a huge innovation for critical care nurses and its use was, well, critical.

The takeaway from this particular challenge was that it was more advantageous for us launch the app for Android on Google Play first in order to achieve the speed to market we wanted. Google Play is more inclusive and offers more flexibility. By taking this path, we were able to get quick real-world feedback on the app – lessons we could then take into our next iteration, the iOS version.

3.) Client Expectations – Looking back on our experience with the AACN app and the Apple Store, we realized that the development process for this app should have involved a more Apple-friendly MVP (there it is again!). But this is easier said than done when it comes to client expectations. Even if the client requests something simple and straightforward, the Apple Store has its own set of complex criteria. In this case, we had strong core functionality in place, but we were missing the bells and whistles Apple requires for approval, things like bookmarking, search capability and a lightweight device.

So how do we help the client find the balance between speed, bare bones requirements and necessary Apple add-ons? Moving forward, this will likely involve a more collaborative discussion with the client about the constantly changing Apple Store requirements.

The possibility of an early launch on Google Play as an MVP is another possible scenario, since it allows for quick market research to take place and improvements, enhancements and changes to begin immediately. The lessons learned from those early tests can be helpful in developing and submitting a later version to the Apple Store.

Regardless of how Orthogonal helps clients’ products get positioned in a rapidly growing mobile app marketplace in the future, the MVP is moving to the forefront of our strategy. The MVP concept allows us to better serve our clients, and those who use our apps to monitor health issues, by providing unrelentingly efficient and high-quality technology.