Innovation at Dimagi, Part 5: Introducing the Innovation Lifecycle

---

In this series, Dimagi’s Co-Founder & CEO Jonathan Jackson (@jonathanleej) and Senior Director of New Business Shabnam Aggarwal (@shabnamaggarwal) discuss how we continue to look for ways to innovate with the help of a dedicated entrepreneur within the company.

In this piece, Shabnam explains how she views the stages of innovation and introduces her Innovation Lifecycle.

---

The other day, on a one-on-one call with Jon Jackson, our CEO at Dimagi, I asked Jon what his opinion was on a client I was struggling with, and Jon’s advice to me was, “Just don’t use the word ‘innovation’ next time you talk to them… It will get you into trouble!”

I thought that was hilarious and telling about our industry—some people love the word, some people hate the word.

I find that we shy away from innovation in our industry at times, because it points to the possibility of not having everything figured out already. It opens the door to the potential for failure, which most products, projects, and programs are not set up to support nor withstand. 

But when I think about innovation, I envision a valuable early-stage lifecycle that opens the door to learning, iteration, and the creation of a solution that’s much more aligned to what users need—and much more useful in the long run.

In fact, I think this is already the process that many programs go through, but perhaps is not elucidated in this way. People are often incentivized to act as if they do have all the answers and are certain in how they’ll achieve their outcome. But this can be detrimental to true innovation. 

I decided to draw out the steps one by one, apply them to a number of innovations, iterate on the steps, and then publish them here:

What you’ll find about my method for the early-stage innovation lifecycle is that it leaves a lot of room for iteration—a solution is almost never final nor complete.

It begins at the top left with market research, and moves left to right, then down, then right to left, like a line at the airport. As you can see, there are a lot of steps to this process.

In this blog, I’ll cover the general thinking behind this method and focus in on one row of these steps to explain how I applied it to the innovation life cycle of FocusMDM, CloudWorks, or other innovation ideas we’ve tried on Dimagi’s New Business team. As we go forward, I’ll pick and choose certain groups of steps to flush out into longer articles that I think—or that you tell me—would be useful to dive into.

Kicking off this series with market research around a new problem we want to solve, what I find most interesting and insightful is learning about where the market already stands (mostly at this stage through internet desk research). Who is facing this problem today? How painful is this problem for them today? How do they currently solve the problem? Which players are solving or trying to solve the problem today? How are they solving the problem? Who are they solving the problem for? Does it make sense to build an entirely new solution or would it be simpler/better/faster/more appropriate to use existing solutions? 

Before we were even calling our idea FocusMDM, I started asking these questions about mobile device management. What I found over and over was that while this was a problem that everyone in our industry deploying mobile devices faced, almost all the solutions that existed in the market were focused on developed markets and protecting devices like the tablet you use to order your coffee from Starbucks or Panera Bread. The solution was not designed for the market we cared about, which is frontline workers in LMICs. 

So the answers I discovered to these questions at this phase of research were:

• Who is facing this problem today? Programs deploying mobile devices to the field
• How painful is this problem for them today? Moderately painful—not the biggest issue on their list, but also not a negligible one.  For some, controlling data plans was high pain, for others, data security of lost devices was medium pain.
• How do they currently solve the problem? Empty threats to FLWs or collecting devices at the end of each day to monitor usage
• Which players are solving or trying to solve the problem today? Large private MDM companies like AirWatch
• How are they solving the problem? Fairly complex and robust solutions that require deep technical expertise to use and deploy and/or assume a centralized IT department
• Who are they solving the problem for? Large multinational organizations like Starbucks and Goldman Sachs
• Does it make sense to build an entirely new solution or would it be simpler/better/faster/more appropriate to use existing solutions? 

This last question was a difficult one to answer purely using desk market research. I needed to understand the cost and value implications of developing this product in-house vs white labeling or partnering with an existing solution on the market. From a cost standpoint, this meant I needed to jump into some early business modeling and conversations with internal developers (step 8). From a value standpoint though, the answer was fairly clear: The products currently on the market were not meeting the needs of our customers, so white labeling any existing solution was unlikely to truly solve their problem, especially at the price point I assumed our customers would demand (step 4). 

I didn’t like that I was only sensing “moderate pain.” But because we believed that data security and privacy was only going to increase in importance and that properly securing mobile devices would become a higher priority, we decided to take the plunge.

My next step was to get a sense of price sensitivity, which I’ll talk about in an upcoming piece.

---

Catch up on the rest of the posts in the Innovation at Dimagi series, including the last one, where Dimagi CEO Jonathan Jackson explained how and why to differentiate funding from innovative sources from true revenue.