How we brainstormed, designed, and built a prototype within 14 hours at a Hackathon in Miami.
This weekend StartupBootcamp Miami — Digital Health held a hackathon in partnership with MIT Hacking Medicine. As a Product person building products and delivering projects is what I live for. This is why I participated in this Digital Health hackathon and a write-up of my experience.
For this hackathon, we decided to build a search tool that helps people traveling abroad. In my opinion, hackathons help to stimulate creativity and collaboration skills. Through a 14-hour exercise divided into 2-days, a team of strangers who had never worked together before shape a product prototype then pitched it to judges at the end to get feedback on the viability and scalability of the concept.
Proposing A Problem That A Team Of People Wanted To Work On
Hackathons are created usually to tackle a specific problem. In this one, we were asked to create a solution around the problem of social determinants in a community. This hackathon was like a design sprint where you work together to create a startup idea while aiming to convince people to join your team.
Each participant got an opportunity to propose ideas. 22 people went up to pitch their idea. When it was my time to present I spoke about the idea of creating a better safety net through digital services for managing benefits. The idea stuck, but I didn’t get enough traction beyond 1 or 2 people. To find a team I chose to approach others who had their own idea and offered some insights on tech-driven solutions that could help them achieve their goals.
This method helped me add value and eventually find 6 people willing to work together on one team. In the end, the problem we worked on stemmed from the story of a single team member. Whitney, the developer on the team, faced difficulties finding reliable medical services for her mother who had a chronic condition but had to travel abroad to be a caretaker for her father in Haiti.
Identify, Then Define The Problem
The theme of our problem was addressing access to healthcare services and emerging technology for people traveling abroad. Essentially it was a problem that fit Global Health particularly for US Citizens who travel into a new health system. To help us scope out a solution I asked the team, can we simplify the problem in one sentence?
After turning our problem into one sentence we spent about 25% of our time defining it and the business. To help us accelerate the process I proposed we broke into groups of 2 were 3 of us focused on business than the other 3 focused on the product experience. We then got together after working for 2 hours separately to share our learnings and considered the best approach in terms of a solution. This helped in not only motivating the team but keeping us on track for building something that added value to the end-user.
Some questions we asked when defining the business problem:
Who is the target user?
- An older Miamian who is traveling abroad with US Health Insurance, have a chronic condition, and doesn’t have travel insurance.
What are there problems?
- Access of available health services (e.g travel insurance)
- Access to new technologies abroad(e.g Alexa, Telehealth Services, Internet)
How is the target user solving their needs today?
- Word of Mouth
- Smart Phones / Search Engine
- Insurers Providing Benefit Service
Building a Feasible Business Model
The business team worked on figuring out the target market, potential revenue models, and a business operational expenses. Together we began to draft the necessary ideas that would make this a viable business. We played around with a lot of ideas some included financing through the following:
To help us with planning I used geospatial mapping to target communities who fell under certain income thresholds where we could then segment our market based on zip codes to launch market campaigns to go to market. This made it easier to target people to use our service through adword campaigns.
We believed through selective markets that we could achieve viability as a business and start not only getting users but revenue quickly. We did this through grouping users by ethnic backgrounds matching the groups we ourselves were a part of.
Getting the Data To Build The Provider Search
I took on the task to build and design how this product would work.To do that first I drafted procedures, database structure, how we would obtain the data, and how that would look in a system diagram. I broke it into 3 parts:
- Extracting Data
- Transforming Data
- Loading Data
Putting the user first and their satisfaction was key to this. For this reason, I ensured that whatever was crafted and the data points we used could all be done in a secure HIPAA compliant way. Some things I considered were:
- Where would we get this data?
- What would we use to ensure the data was regularly updated and able to updated through a 3rd party non-technical worker.
- Who would see this and what are the ways they would access this service regularly?
Wireframing, User Flows, and Solutions
I began to wireframe, define processes, and look at existing products. We started writing this information on paper, on a board, then transferring what the team agreed upon into tangible wireframes. I’m a strong proponent of the scientific method so we listed our assumptions, made a hypothesis, and would take this to users (mentors) who frequently came in for feedback.
This helped us frame ways to deliver the service via features:
- A simple web search interface.
- A method to text via a short-code to get information.
- A chatbot that could be interacted with for information.
Preparing a Presentation
We spent the 2nd day or remaining 5 hours preparing our business model and pitch deck to present in front of judges. Mentors came by in the room and we presented our ideas in front of them. We used that feedback to iterate with a hard deadline to be ready to send our presentation by 45 mins earlier than the expected time. Some last hour things we did:
- Product Design: Ensuring that the solution shown was clear and concise. I’m a high proponent of not using dummy data especially in a crowd with the target demographic. This meant reviewing our process flow and pulling real data into our prototype shown.
- Practice, Practice, Practice: We practiced our pitch. I proposed that everybody went through the pitch to become familiar with how presenting feels. We timed it then everybody got a section to talk on. We timed ourselves about 10 or 12 times before it was time for us to move to the next room to hear others present. Before we presented we knew that at our best we were 40 seconds or 20 seconds away the 3-minute time needed to present.
Getting Feedback For Improving
We didn’t win. As a product owner feedback and understanding your user is important. The judges, the organizers, the MIT crew all gave us valuable insight. We asked openly, what did we do right and what did we do wrong.
Here is some of the feedback we got summarized.
- We had a comprehensive deck and go to market plan.
- We identified a real problem and illustrated the narrative well.
- We made proper use of emerging technology to tackle an existing problem.
Here is some of the feedback on ways we could have improved.
- If it was a Global Health Hackathon we would have gotten further, but this was Social determinants.
- We were not clear on how we could make money in the pitch and in the final deck we didn’t include it in the slide. If it was in the slide they could have used that to revenue even if the numbers were assumptions.
- Our service was compelling but it was not clear where it fits into the overall health network? We did a refined stakeholder map that wasn’t shown in the presentation.
The troublesome thing about hackathons is the delivered idea can either live or die. Often it dies. How do you build sustainable projects that can live longer than a weekend? For our team, I decided to follow-up with each team member and stakeholder to keep them in the loop of how we plan to close in our project. Here are some next steps:
- Building A Minimal Viable Solution: Setting a weekend or specific day to build out this Provider Search.
- Define a Revenue Model: Build out a revenue model that makes sense perhaps switching our audience or market to one that is viable.
- Testing the Market: Using our go to market strategy and getting feedback from real users on how to improve within 2-months.
Building a Provider Search is not a new concept and most insurers have one. In the case for us, who had 4 people working in healthcare we identified some weak points in the existing system. Designing a better digital service around this problem was a positive experience for me. We will continue to iterate and build this to the point of a minimal viable product.
Any tips on how I could’ve organized the team? If yes, please comment below.
Gregory is a Technical Product Manager and an IT Project Management Consultant focused on healthcare and cities. He actively involved as a Project Manager Lead at Code for Miami where he helps them plan and ship projects. He has worked 6+ years in the Healthcare Information Technology space launching apps in various domains.
For more information, you can find him at HiGregory.com.
Credits to the team and their contributions to the project: Whitney Lubin, Brandon Slew, Menghi Qu, Grant McGaugh, Maddie Wilson.