A Guide to Mini-Hackathons
How we brainstorm, build, and ship within 8 hours at Oscar
Co-authored by Gabe Schindler, Senior Product Designer, and Lukasz Mosakowski, Group Product Manager.
Building products at Oscar is an ever-changing process. Some days we’re testing how doctors virtually treat patients, other times we’re bug squashing and sprint planning. While our day-to-day is often an exciting challenge, we sometimes mix it up in search of fresh approaches to solving problems in health care.
Every two months, the Find Care team — a group focused on guiding members to high-value doctors in Oscar’s network by building features like search and scheduling — blocks off a Friday to hack. We devote eight uninterrupted hours to building a feature from start to finish, shipping the product to Oscar users at the end of the day. Mini-hackathons are not to be confused with Oscar’s official hackathon, as they are initiated by individual teams, not the greater organization. As a break from our regular cadence, mini-hackathons stimulate creativity, build team rapport, and develop vital collaboration skills. These sessions have been so effective that we’ve compiled a rough guide for other teams interested in running their own mini-hackathon, using the real-world example of in-app appointment-management, as seen in the image below.
1. Identify a problem
So, what should you build? While creating something entirely new is an exciting venture, we’ve found that, given the time constraints of a mini-hackathon, iterating on existing features is best; it imposes healthy constraints, maintains product focus, and easily ties into a team’s long-term goals.
In the lead-up to our latest hack day, we received significant feedback that Oscar members were having difficulty accessing appointments they’d scheduled. They were booking and cancelling appointments through the Oscar app, but there was no centralized repository to house all of this information. We wanted to to fix this.
2. Explore the problem
After identifying a potential problem, we unpacked it some more. During the exploration phase, we began with a list of questions framed around the user, modeled after Giff Constable’s assumptions exercise. Our answers ensure the team understands the landscape of the problem before jumping into problem-solving.
Who is the target user?
- An Oscar member who has booked an appointment, engages with the Oscar mobile app, and is in a non-critical health condition (meaning they’re not rushing to the emergency room).
What problems does the target user encounter?
- “I don’t know where or when my appointment is.” Users found it challenging to access key information, especially on the day of the appointment.
- “I don’t remember why I visited the doctor that one time.” Referencing past appointments to reconcile bills or reschedule new appointments was difficult.
How is the target user solving these problems today?
- Users may dig through emails to recall their appointment details, wait until they get a same-day notification of the appointment, or review their health timeline in the app (a ledger that records every interaction a member has with Oscar).
- Perhaps users manually save the appointment to a calendar or write the appointment down in an agenda.
What could we build to solve these issues in the future?
- Display a monthly calendar view of a member’s health timeline (currently it’s in list format).
- Place appointment info on the doctor’s profile whom they have a visit with.
- Make appointment info searchable in the app.
- Establish a new entrypoint to view all appointments (the winner).
3. Connect it back to the business
Once we explored the problem, we evaluated our potential solutions by considering their benefit to other teams or stakeholders. Reducing patient no-shows was top of mind, as it would save Oscar members costly cancellation fees and doctors valuable consultation time. We also imagined that a central access point for appointments would more effectively facilitate booking repeat visits and encourage users to rate their experience.
This feature would also give us the future benefit of capturing visits not booked through the Oscar app early, before a claim arrives, as members could manually input appointments. This would give us even more insight into ways to provide care.
With the potential business and user experience wins, as well as the constraints of (now less than) eight hours of build time, an appointment manager project was the clear victor. It would be a new entrypoint where we could experiment in isolation, ensuring we don’t impact current features while avoiding the burden of navigating existing code.
4. Get scientific
After listing out potential outcomes, we created a hypothesis that would measure the success of our feature. We hypothesized that a central repository for appointments would result in a decrease in cancellations and no-shows.
5. Agree on data and build
We then segmented the feature into two parts: upcoming and past appointments. This way, users remain focused on appointments they must attend without confusing them for their appointment history. We also agreed that each appointment contains four data points:
- Who: The doctor with whom you’ve booked an appointment.
- What: The appointment date, time, and location.
- Why: The reason for seeing the doctor.
- Status: The status of the appointment (confirmed, pending, cancelled, missed, or past).
Baptiste, our tech lead, delegated engineering tasks while I split off with Lukasz to advance the wireframe and realize the final product. I leveraged Oscar’s design system, an established library of UI components, enabling me to focus on the user experience without worrying about visual finesse. If you don’t have your own design system, use Apple’s or Google’s UI library: it’ll help you easily adopt standard interface paradigms.
6. Launch, celebrate, and learn
Fast forward a few weeks. We’ve shipped the product to a subset of users, gathered some metrics, and now it’s time to examine our findings. How did our assumptions fare? Should we iterate, adjust course, or completely scrap the project?
Before we launched, users mainly accessed appointments through their health timeline, the in-app ledger of every member interaction with Oscar. After introducing this feature, we found that 35% of users now accessed their appointments through the new appointments manager, while 60% of users still leverage the timeline and 5% use email reminders or push notifications.
Although this shift in utilization is great, we did not observe a significant change in cancellations or no shows — thus refuting our ambitious hypothesis. But, that’s okay! Some, if not most, experiments will not support your hypotheses. Learn from that outcome, feed those learnings into the product, and adjust course as needed. In this case, the promising shift in engagement towards the appointments manager warranted shipping it to all Oscar members. We’ll continue to iterate on different approaches for reducing cancellations and no shows.
The new appointments feature is now live, joining the ranks of previous mini-hackathon successes, including quick access to nearby urgent care and saving a doctor or hospital for later. And now, it’s your turn. Grab a few hours, a clean whiteboard, and get hacking!
Any suggestions for how we could improve this process? Let us know — it’s a work in progress.
Many thanks to Baptiste Truchot, Savannah Lim, Emili Hsu, Will Strasser, Marissa LaFontant, Esme Ricciardi, Olivia Witte, Clare Lynch, and Bin Shen.
Want to talk more tech? Send our CEO, Mario, a tweet @mariots
