ICTworks

Two years ago, I joined Dimagi, who is well known for making CommCare, with the exciting but daunting prerogative to diversify the company’s portfolio. As an entrepreneur with a thirst for innovation, I was excited by the prospect of ideating, testing, and launching new products aligned with the company’s existing clients’ wants and needs.

From my internal and external user interviews of CommCare constituents, I learned that managing large fleets of devices was increasingly important and difficult as new entertainment apps launched on the Google Playstore daily which threatened to compromise patient data. So the first product we chose to test was a mobile device management tool.

Mobile Device Management Corner Use Cases

The idea was exciting in theory, and received lots of positive encouragement at the idea stage. Once we entered the pilot stage, we had even more encouragement and plenty of lessons that we learned quickly and painfully.

What we could not have predicted was the vast number of “corner use cases” that would arise while building this solution for our target clients. Each of these corner use cases challenged our desire to reduce scope creep and maintain a user-friendly MDM tool that would work out of the box for everyone.

1. Offline Time-on-Task Tracking

We first launched Focus Mobile Device Management with a research team at Notre Dame working in Latin America. We quickly spun up a barely-tested solution to get their devices set up mere hours before the devices were deployed. We were excited to see how our assumed biggest value add – tracking how wifi and telecom data was spent – would prove useful to the project’s managers.

Then for weeks, we did not hear from the Notre Dame team while they were out in the field. When the project manager finally got in touch with me, she mentioned that the devices were offline more than 95% of the time they were in the field, and thus, our entire solution was rendered useless to her.

Although we could not solve her problem in time to support her project, this feedback led us to building a “time-on-app” feature that measured time spent on each app, regardless of being online or offline. Without this failed project, we would never have come to this unique selling point that sets Focus MDM apart from others.

2. Overworked Project Management Staff

When we first launched at scale with Jhpiego in two country programs (“scale” at this early stage in the product lifecycle was anything over 30 devices), we saw substantial uptake of the product and consistent usage from one country program, but the other country program seemed to have completed the setup process for their devices, then forgotten about the product entirely.

When investigating the non-use more deeply, we learned that the process of logging into a dashboard to manage devices every few days was an added burden on an already complex project. Project managers already felt overburdened with work and the mere process of logging into our system was too great a barrier to use our fancy dashboards.

This led us to work on emailed reports that could deliver a snapshot of the most valuable insights about a deployed fleet of devices right to a managers inbox, negating their need to log into the system on a regular basis.

This feature is slightly more complicated than we first assumed, so we’re still working on it, but our end goal is for our product to delight managers, not add burden and frustration to their already hectic day.

3. Tracking Multiple Device Movement Over Time

We then began working with small and medium sized social enterprises like Spouts of Water in Uganda. Interestingly, their use case was even more unique. They were deeply interested in how their door-to-door sales staff was moving through their assigned catchment areas, and how well (or how poorly) they were covering their target areas.

At the time, we only showed the latest GPS location of a particular device, which we used to generate feedback on what our users’ GPS needs really were.

We worked with Spouts’ managers to learn what GPS data they really wanted to see. This insight led us to launching and refining a heatmap that showed device movement over time across any group of devices. Spouts used the heat map to depict how well an area had been covered by salespeople in a certain region.

Saying No to Corner Use Cases to Focus on Functionality

Getting honest and early feedback from real users was exactly what we needed to make a tool that was viable and useful to our industry.

Yet, while I do enjoy using corner use cases to drive new product functionality, we could not possibly build every feature that we were asked to build. For example, we cannot track devices that have been turned off.

Still, I encourage everyone in our industry to explore their corner use cases with an innovation mindset – at whatever scale you can manage. The learnings alone are immeasurable.

By Shabnam Aggarwal, a strategic advisor at Dimagi.