Holiday Hackathon Experiment

A weekend away to build something that matters.

For the past few years I’ve been thinking about ‘how might we build solutions with social impact in better, faster, cheaper ways?” I began to research and eventually practice lean thinking, agile software development and human centered design. I’ve immersed myself in the how to build, in hopes that it will guide me in what I build in the future.

What I’ve learned through this inquiry is how to build something meaningful quickly. I learned that with a small cross functional team that possesses a make-it-the-best-way attitude, solving a clearly defined problem we can demystify the black box of product development.

As an experiment to test rapid product development, I brought together a small, nimble, group of people to solve a hairy problem in 24 hours. I wanted to test the process, I wanted to see if we could make something of quality quickly, while keeping costs low and people happy.

The experiment was a success.

Over the course of one day in Tahoe, we built a record case management system for sexual assault victims. The best part was that the team had fun, felt motivated, and still had time for walks in the woods and coffee breaks by the lake. It had enough features for the founder of the startup, code named ‘Vivify’, to show to investors, and police departments what kind of solution she was looking to propose. Best of all, she would have enough built to pilot the product with a police department in North Carolina.

How did we do it?

Every great start to a great product comes from solving a real need held by a real person. Amelia came to me, asking if I could help her solve a problem.

She articulated her problem as: “the way that victims of sexual assault are dealt with in the criminal justice system is atrocious” she said. Officers are inundated with paper records of unresolved sexual assault cases that sit in boxes unopened for decades. Victims are left with no information as to where their case is in the process and need to constantly follow up with police departments, leaving voicemails, emails, and dropping in to the station. There is little ability for police to access the records as well and so follow-up is slow and arduous. Amelia had close experience with this and wanted to improve this process for others.

Assemble a small, dedicated, team of people who can make stuff.

A key to rapid product development, is a team of people who can actually make things. Each person needs to bring something to the table beyond strategy and ideas. Our team consisted of a designer who had front end development skills, two rails developers, and myself who managed the backlog, designed, and made product decisions with the founder. With our complimentary skill sets we saw the challenge from different angles, enabling us to see the product challenge ahead of us holistically. Each of us took leadership within our own domains of expertise, which expedited decision making. Familiarity with the tools available to us to launch a product helped us quickly decide our tech stack and communication tools.

Define the problem

Ask a series of questions to uncover a discrete unit of complexity that you can then systematically solve. We spent the first 2 hours of the day unpacking the product definition, what were the core elements of the product that if we were to remove would prevent us from solving the problem.

We asked questions like:

  • How does information flow from hand to hand in a sexual assault case? Can you draw it for us?
  • How is information stored?
  • Who’s responsible for communicating with the victim?

User story mapping also helped us identify different pain points that we could potentially tackle.


Create a list of metrics for success. Startups often look to standard metrics of success, which in many cases is not a great idea. A quick card sorting exercise to define product success helps us define what matters to our team within the current scope of work. Using these filters we were able to have a structured conversation around what features we wanted to build and what feature we needed to cut. We used Trello to organize our list of features that we wanted to build, and create a rudimentary backlog. Our focus was on speed, agility, and great communication. Our designs were drawn on whiteboards and paper, we took photos and posted them to the Trello card with that user story. The focus was to get the right work done,

Trello board that tracked feature list, QA testing, success metrics, bugs and goals for the project.

Parallel Track Execution

We intentionally limited our time to hold ourselves accountable to our highest priorities. We kept our feedback loops as tight as possible. While the developers set themselves up, we drew our designs and wrote feature stories for the developers to work on. While development was occurring, our designer Jimmy worked on the front end and I made any necessary copy changes. We worked closely with the founder Amelia to make sure that our priorities were correct and we were using the right language for our users.

Ultimately, within a day we were able to ship a decent working product that provided investigators the ability to update information, communicate with SANE nurses, and have automatic notifications for victims when their case has progresses. These features provided Amelia with enough robustness to test her major assumptions with her pilot group in North Carolina.