Ten Lessons Learned From My First Healthcare Hackathon
I attended the MIT COVID19 Challenge Beat the Pandemic II Hackathon this past weekend (5/29–5/31). As a resident physician, solving pain points in the healthcare industry has always interested me. This was my first hackathon, but it certainly won’t be my last.
Shout out to all the organizers for creating a supportive environment that encouraged diverse ideas and backgrounds. I couldn’t have asked for a better team, and our mentors were generous both with their ideas and time. When the organizers announced the three winners of our track of the hackathon, I was thrilled to see our team name pop up on the Zoom screen!
This incredible experience showed me what collaboration between dedicated and forward thinking folks can do in such a short period of time. Thinking back, there are ten lessons that I would like to share with you.
1. Set goals.
For my first hackathon, I centered my goals around learning. I wanted to learn how the process worked, how entrepreneurs approached these problems, and what constituted a successful idea or product. Having goals also helped me become a more active participant as I tried to practice what I have learned in real time.
2. Pitching in the beginning doesn’t require you to have a solution.
In the beginning, there was a pitch session where anyone could pitch their idea to attract potential team members. I thought you had to have a solid idea with a solution in order to do this. However, I was pleasantly surprised that many people pitched a problem that they wanted to work on rather than a solution. Don’t be afraid to pitch a problem without a solution! You have the rest of the weekend to figure out that solution.
3. Joining a team is very fluid.
After the initial pitch session, we were given a list of the pitches and their corresponding Slack channels. I joined a few channels to check out the ideas. Quickly, I realized the following:
A. Those who pitched ideas also talked to other people about other ideas. Pitching an initial idea does not bind you to that idea. You can join efforts or completely switch over to a different idea.
B. Talk to as many teams as possible. This “speed dating” is a way to find the best fit for you and also for the team.
C. When making the final decision, keep your goals in mind and consider the tradeoffs.
4. Team success depends on communication and accountability.
You’ve heard of this before: communication is everything. Our team was made up of seven people across four continents and three time zones. At first, I thought this time difference may slow us down. But I was wrong. We brainstormed ideas, planned To-Do lists and deadlines, and we went to work We had regular check-in’s to keep us moving forward and helped each other when needed. And I got almost 7 hours of sleep each night. Note: depending on the type of hackathon, your mileage may vary regarding sleep.
5. Pay attention to the judging criteria.
Hackathons are still competitions. The criteria for this hackathon centered on Impact, Innovation, Implementation, and Presentation. If you understand that the criteria are not made just for the judges but rather key characteristics of a successful product, then you will be much closer to success. During the final presentations, I was surprised to see several pitches that included amazing ideas but not all of the categories of the criteria. Don’t sleep on the criteria.
6. Listen to your users.
But how do you do it with less than 24 hours before your final pitch?
Survey.
We created a survey to find out how our users get information about COVID-19 and what pain points they had. We sent these surveys to our family and friends, posted to our social media accounts, and even blasted it to the general Slack channel of the hackathon. By the next morning, we got about 275 responses! This was a huge success for us because it identified a key pain point that would shape our product. Conducting a survey as a way to “listen” to our customers was also likely a key reason why we won.
7. Don’t forget about the business model.
It is difficult to do good on a large scale if you can’t sustain the team that is making your product. Will it be a one-time payment? Freemium? Subscription? Grant supported? Get some idea about where your revenue may come from and what your pricing structure may be. Again, you would be surprised to see how many pitches that overlooked this crucial component.
8. Identifying a good problem is better than building an amazing solution.
You won’t succeed by building an innovative solution to a problem that doesn’t exist. During the final presentations, you may hear “we believe the problem for our users is…” a lot without hearing about how the team arrived at that problem. Was it really a problem the team had or a problem that users had? Take the time to identify a good problem. How? Listen to your customers and users.
9. User feedback > pretty demos.
Getting a product right is an iterative process that should be governed by user feedback. We focused on getting a prototype out to our survey takers quickly to solicit timely feedback. This strategy paid off — we learned valuable information and tweaked our prototype for the final presentation. Keep talking to your users and customers.
10. Post-hackathon reflection is important.
Participating in a hackathon is an intense experience. Take some time to reflect and remember what you enjoyed about the experience. You can do so in private and/or on social media. Posting on social media (i.e. Twitter or LinkedIn) may help build your brand but also may help spread awareness of the event. Maybe your post will inspire someone else to join next time.
We were very fortunate to have been picked as one of the winners. But my biggest takeaways from the event is not the end result but rather the process that we went through and the team that we built. Try to remember the process that you went through.
So how did we win?
By listening to our users and customers. We never would’ve identified the pain point if we didn’t conduct that survey. We never would’ve been able to have an improved prototype if we didn’t do user testing. We never would’ve thought of our pricing structure if we didn’t talk to people working in the field.
There’s a reason why we have two ears but only one mouth.
If we want to overcome the challenges posed by COVID-19, we have to listen to those whom our actions will have the most impact on.
