This post is a part of a series “Watching My Blood Sugar Levels”. I intend to use short posts in this series to walk the readers through the initiative of using data to manage my Type I Diabetes condition. The content in this series is not expert opinion, it’s more of a documentation of my personal journey with this condition in the way how I understand it - Data.

The last 2 posts in this series were

  1. Watching My Blood Sugar Levels - The Beginning (ry05.github.io)
  2. Watching My Blood Sugar Levels - Problem Framing (ry05.github.io)

The next couple of steps in building my blood sugar tracker is eliciting requirements and identifying which of these requirements are indispensable if I want my problem to be solved. As defined in the previous article, my problem statement is

Newly-diagnosed diabetics(like me) have difficulty in understanding how certain meals affect their blood sugar levels and also find it hard to effectively track their progress in managing the condition because they lack a system that would help analyze the data collected.

Eliciting Requirements

What do I want my blood sugar tracker to do? Well, I want it to track my blood sugar levels, suggest what to eat, scrape the internet to find me the best eating options, book an appointment with the doctor if sugar levels go too high, automatically adjust my sugar levels, cook meals for me and cure my condition :)

Apologies for the detour, however this is exactly how our minds work when planning a project. We start with basic requirements and then the ambition bug bites us and next thing we know, we are demanding a unicorn. I don’t know if companies are plagued by this, however I do know that the struggle is real for individual projects!

Even though some of the requirements above seem too complex or some preposterous, I don’t see a reason why my product can’t include them. To me, all those requirements are needs. Hence, I shall go out on a limb here and add some of them onto my requirements list.

  • Visualize blood sugar levels
  • Compute metrics that would help quantify how well (or badly) I am managing my condition
  • Identify relationships between food I eat, insulin taken and blood sugar levels
  • Send an alert to the doctor if my levels go too high
  • Suggest what to eat next based on my current sugar level
  • Compute the insulin to take based on the food I am about to eat
  • Recommend recipes that involve foods with low glycemic indices(GI) by scraping the internet
  • Generate a report with a single button click
  • Filter readings and data based on a given time period
  • Visualize my eating patterns (for example, how much do I eat? what do I eat?)
  • Flag spikes in sugar levels and conditions that caused them
  • Share my results instantly to my doctor or parents or friends

Deciding on the Minimum Viable Product(MVP)

A Minimum Viable Product(MVP) is the product that just has those features that allows the product to satisfy some core objective of the end user. As Eric Ries, the person behind the idea of an MVP puts it, the idea of having an MVP is to show early adopters what fundamental problem the product is looking to solve.

The blood sugar tracker system I am planning to build is currently just a personal project. However, that still does not discredit the fact that building this system could benefit from the idea of having an MVP. As per the MVP definition, this blood sugar tracker system has one core objective - To help make use of data to track diet and blood sugar levels and thus measure progress. Every other feature can be considered as an add-on, features that can be added in future iterations of the system.

The MVP model was originally conceived in a context of building better products for your customers, especially in a competitive business environment. This personal project of mine is neither - I am not trying to build a customer base(yet) and naturally, there is no need to compete.

Why am I Thinking of an MVP?

The reasons are simple. I am a full-time graduate student at one of the most competitive schools in the world. Therefore, time is an important commodity. Building an MVP will help me control the time I am spending on the project and will ensure that I don’t drift away from what’s really important.

Also, I am no expert in either diabetes or product building. Having the condition can’t make me an expert. Therefore, I need to keep an open mind while building this system and be ready for any number of iterations at a later stage. An MVP model is flexible and allows for this kind of iterative development.

The Features of my MVP

I intend to have the following features in my MVP

  • Visualize blood sugar levels
  • Compute metrics that would help quantify how well (or badly) I am managing my condition
  • Identify relationships between food I eat, insulin taken and blood sugar levels
  • Filter readings and data based on a given time period
  • Visualize my eating patterns (for example, how much do I eat? what do I eat?)

If you are familiar with data analytics, you would recognize that the MVP is a system that performs diagnostic analytics or answers the “what has happened?” question.


In the next post, I will be writing about the data collection process.