Quick Thoughts on Hackathought

Over the past weekend, I participated in a hackathon put on by the Centre of Addiction and Mental Health (CAMH). It was a fun weekend, and a great opportunity to do some work in an area that is effectively disregarded in the private sector. It also, however, highlighted several major problems with the hackathon model more generally. I had my suspicions about these problems earlier, but I really felt them as a participant. Looking back over the weekend, three major concerns stand out for me: the lack of focus in the problem definition, the limits on time and emphasis placed on research or insight-gathering, and the lack of opportunity to test ideas with end users.

To kick off the hackathon, we were treated to a panel discussion covering some of the issues around mental health and wellness facing post-secondary students. Much of the discussion focused on the need for dialogue about mental health and wellness issues, and little time was spent exploring or characterizing the needs of students either on a day-to-day basis, or in times of crisis. Moreover, the emphasis of the hackathon itself was placed on creating a mobile app that used the ThoughtSpot data. This made it difficult to more clearly define a problem faced by post-secondary students to target, as there was both little discussion about those problems and a lot of emphasis on a particular implementation (a mapping application).

While I felt it was reasonable and worthwhile to set a constraint on needing to rely on the ThoughtSpot data, I think greater emphasis on problems faced by post-secondary students around mental health issues followed by ideation around how the available data could be used to solve those problems would have resulted in more creative solutions, and less emphasis in the end on mobile map viewers.

The tight timeframe also prohibited opportunities to do deeper research within the ad hoc teams at the hackathon. This meant that most of the ideation was driven from personal experience. While personal experience can be an effective source of inspiration, it is also harder (in many ways) to evaluate one's own experience retrospectively, and self-rationalization of behaviours can lead to radically different outcomes from researching the experiences of others.

This also makes the lack of opportunity for testing even more concerning, because it means that there is no opportunity to have someone else's reality steamroll your preconceptions and throw into sharp relief the inconsistencies in your own narrative of events, personas, or user goals.

While hackathons and design slams can be a great way to challenge yourself to get creative and to produce something meaningful in a very short timeframe, I sincerely hope that any organization using them as a tool to crowdsource product ideas subjects any they choose to rigorous evaluation to make sure they are actually meeting needs in their context of use.