We all know the problem that we are trying to solve, or rather, hack: “How do we insure more Filipinos at a faster rate and make our brand promise of helping people live healthier, longer, better lives more concrete?”
But as true lifehackers and innovators, we don’t just stop at knowing “what” the problem is and go on with creating a pitch just based on a statement. Rather, we have to start asking “why” and reimagine the problem at the perspective of our customers and users. This is the first step to design-thinking, a solution-based approach to solving complex problems like the one we have for this year’s hackfest.
Learn the 5 Steps to Design-Thinking from serial hackthon attendee, Agrim Singh of Medium, to help your team hack the problem and deliver innovative solutions.
Too often we are guilty of building a solution without giving much thought into things that come before it — why are we doing it, who are we doing it for, what will it really do, will it do what it intends to do and for the right audience. Much of this rests in the lack of empathy for the problem. We let our own assumptions dictate what the problem is, and that is wrong. I faced this first hand when I was trying to build a solution to help the visually-challenged navigate independently. I assumed that:
Firstly, this is a problem because guide dogs are expensive and having a helper is troublesome,
Secondly, obstacle avoidance is the biggest problem to solve,
Lastly, a wearable like Google Glass could eventually get rid of the cane.
I was wrong on all three counts.
The first point on relieving the helper, while true, wasn’t a pressing concern that would require technological interference. The second point on obstacle avoidance wasn’t the biggest issue; detecting traffic lights was probably a bigger challenge given that the cane covered for most obstacles within range. The last point was severe because I assumed technological replacement is easy. You cannot dramatically switch a person’s way of life; the visually challenged are used to using their cane and tactile pavement markers so any new tech innovation must build on top of this, not entirely replace this.
How do we remedy this? Getting out and talking to people is the surest way of knowing more because you get direct insights into users and their needs. I was able to fix my product to help the visually challenged because I actually talked to someone who lives these challenges on a day to day basis.
But what if you can’t talk to the right audience during a hackathon? Time is short and maybe you’re not in the right place to meet these individuals. You have to improvise and pull up information that will help you objectively define a problem worth solving. Last weekend I was working on a hackathon that wanted us to “Solve for India”. This is a huge theme; India has no shortage of problems, each more important than the last, and to frame it effectively is a challenge in itself, let alone attempting to solve it. We decided on helping out folks employed in the Industrial sector and framed the problem to address fatigue. Why?
-India is the worst when it comes to industrial accidents,
-Indians have a strong dependence on industrial jobs to make a living and,
-There is significant proof available that fatigue and sleep deficits cause accidents/mishaps and even deaths in various lines of work like long-distance truck driving or operating heavy machinery — both risky lines of work with long shifts that make their employees prone to fatigue and losing attention.
Now, there is no way for me to personally verify any of this; I am dependent on whatever public data and facts are available to craft a narrative, but at least this information creates enough empathy to define a problem worth solving.
No matter how much you’ve convinced yourself, you’re definitely going to rush through the Empathise phase. There’s just not enough time to double/triple validate claims. However, if you play your cards right you will have enough information to work with. Let’s work with our previous example on fatigue. We’ve established that a safer working environment is required (claim 1) and one of the ways to do this would be to address fatigue (claim 3). Our problem definition will build on this —“We need a fatigue monitoring system to help create a safer and more productive working environment.”
Now, you could choose to examine any other problem within this domain and that is perfectly valid. Just ensure that your definition is based on claims you’ve established as part of your initial groundwork. Follow up with simple heuristics to set up the next phase of the process —
– Who are we doing this for? In this case primarily for the employees but also for the employers.
– How will we do this?
– What’s our measure of success?
-WHAT IS THE ONE KEY THING YOUR PRODUCT DEPENDS ON?
Here’s when you start answering the “how”. That is, now that you have all your information, what are you going to build? For our case, should we build a monitoring system? Or an alarm for the employee? In each case, what’s our measure of success — waking up the driver? Logging data for employer? Most importantly, what does this all depend on?!
Hackathons are weirdly efficient at product validation and creation. There are only a finite amount of things you can prove and show in, say, 3 minutes so you must pick the most important one. In our example it is the fatigue monitoring system because every other aspect of the product — the logs, the alarm — depends on the fatigue detection working. Therefore, you must build it and ensure it works for your demo. If it fails, the rest of the product is not convincing anymore.
Too many times teams will either botch the one main feature that holds the product together or will build 17 different features (“feature bloat”) that confuses the judges because they lose the message that the team was driving towards. It’s a very simple thing — do one or two things and do them bloody well. It’s the hallmark of all great products. Hackathons are no different.
Now is the time to build. Pick your tools for the trade — in our case we went with OpenCV and dlib for keypoint detection — and start building. You might find yourself drawing out sketches/paper prototypes first before the actual product and that is OK. Use them to bounce between your ideation/definition/empathy stages and, if possible, leverage the help of mentors and experts at the event to give you more insights. Your solution will develop and “clean up”, following which you can get to business. I combined the Prototype and Test phases because hackathon pitches end with a prototype but if you ever feel like extending the project’s shelf life beyond 24 hours then you’ll have to explicitly test with your audience of choice.
See the full story at https://medium.com/@agrimsingh/how-to-hack-a-hackathon-pitch-perfect-8c3057fe617b/.