Introduction.
It may be a little late to start now, but before the MERP web interview, I would like to reflect on the flixy “Medication Calendar” that I developed as my first major project as a student.
This was between 2013 and 2015, so more than 10 years ago now.
Participated in an app development contest as a student
It was the summer of my 6th year at university, and I participated as a player in “Applicare 2013,” a medical app development contest sponsored by the Medical Student Lounge, a community of students studying medicine and nursing. Incidentally, the organizer of this app development contest was Tazawa, a classmate of mine from medical school.
I was attracted by the fun of product development when I first encountered programming in my fifth year of college, so I put aside my polycrystals (sorry), came home around 5 p.m. after my hospital training, and repeatedly developed applications (Objective-C at that time) until around 2 a.m. I was just developing apps (Objective-C at that time) until about 2 a.m.
In the process, he decided that he wanted to create one big app of some kind through an app development contest, so he joined AppCare.
This contest was very unique in that the management picked a medical student, an engineer, and a designer from each of the applicants and shuffled them into groups of three.
To digress, one of the software engineers on the team I was with at that time happened to be Kataoka, one of my seniors from LaSalle Junior and Senior High School (although we did not know each other in junior and senior high school), and although flixy did not work out, we went on to co-found the next Melp together.
Developed backward from contest winners, not from what you want to create
After the team formation was decided, the three of us started to come up with ideas to create something together. In the middle of the project, the management provided us with an opportunity to visit Kameda General Hospital to see and talk to the actual medical site.
Although we had several ideas, we had a team member who was also a hardware engineer,
We thought, “Since others will probably come up with app-only services, we can differentiate ourselves by developing an IoT service that also includes hardware, and we can win the contest. This backward thinking led to the development of “flixy,” a medication IoT case that prevents users from forgetting to take their medications.
The medication is set in the special case in advance, and the time to take the medication is set in the app. When the time to take the medication arrives, the app displays an alert, and at the same time, the LED on the case blinks to encourage the user to take the medication.
The cigarette case-sized medication case was created using a 3D printer, and a medication sheet can be placed inside. Although not an exact measurement method, the application is notified of medication with the opening and closing of the medication case, i.e., when the medication sheet is taken out. The medication is not only taken by the individual but if a family member is also registered, the family member will also be notified.
As a gamification feature, we also implemented a “beauty flipping” function, in which the more medication you take, the more your favorite celebrity or beautiful woman’s face will be rolled up.
Click here to see the video we created to introduce our services.
However, the team did not capture the actual needs of the users, and more importantly, because I was a student at the time, I was not fully aware of the issues involved in forgetting to take my medications. However, I did not understand the actual needs of the users, and more importantly, I was a student at the time, so I did not have enough enthusiasm for the product because I did not have enough awareness of people who forgot to take their medications.
What caused the failure?
The reason for this is that the resolution of the target users was low, the needs of the users were not captured, and the means and purpose of winning the contest were inverted. I would like to look at each of these.
Failure to capture user needs and usage scenarios
This medication IoT case targeted middle-aged people in their 40s-50s who have lifestyle-related diseases.
However, drugs to improve lifestyle-related diseases, specifically hypertension, dyslipidemia, and diabetes, had already been implemented by pharmaceutical companies as adherence measures, and most drugs were already only taken once in the morning.
So, in most cases, people did not bother to bring their medications to work, since most of them kept their medication cases in the living room or work room in the morning and took them after meals so that they would not forget to take them while they were at it.
Also, even if you have diabetes medication that you take three times a day, you either put the appropriate medication in a Ziploc bag and put it in your bag, or you already have your lunchtime medication on your desk at work, and it was not practical to go to the trouble of putting a medication IoT case in your bag just to prevent forgetting to take your medication.
The means and end of winning the contest have been reversed.
I don’t have much to add, as I have already mentioned, but after winning the contest, I started exchanging business cards with interested companies at the reception afterwards, and was asked if I would be interested in exchanging information about this interesting service. Since it was the first time for me to do so, I was so excited that I thought, “I knew this service could be commercialized. I was so excited that I miscalculated further.
In the end, even though we exchanged information, the business did not move forward (as is often the case), but since it was the first time for me to have a meeting with a company, I felt like I was making progress just by having a meeting with them, and I fell into a certain hell where only the project was moving forward without grasping user needs and without making any progress in development. I fell into a certain hell.
I felt during the subsequent user interviews that we were not capturing user needs and usage scenarios, and I felt that potentially we would have to fold the project or pivot, but we had already accumulated a certain amount of sunk costs, and the mysterious nudge from winning the contest (even though we only won the contest) made it difficult to pivot. However, the fact that we had already accumulated a certain amount of sunk costs and the mysterious push from the contest winner (but only) made it difficult for us to pivot.
Eventually, more than six months after winning the contest, the company decided to change the target to the elderly and pivot to the form of a medication IoT calendar, but even there, another challenge lay ahead. This be continued in the next issue.
