My First Hackathon

7 min readOct 30, 2020

48 hours. Build a product. Shark Tank. Go.

For those uninitiated to a hackathon, it’s basically an intensive time-fenced product development event where you solve challenge ideas / problems and then demo an actual product to a panel of judges. This hackathon was completely virtual, making it a bit harder. This was my first one, and maybe my last one for a while (more on this later).

Note: details of the actual idea and names are left out for confidentiality reasons

The Zoom Backgrounds we could use! Love this.

Grab, the company I work for, has an annual hackathon (“Grabathon”). The organizers structured this by first crowdsourcing ideas / challenges, approving the ideas / challenges, and then signing up teams. If we submitted an idea / challenge and we wanted to hack it as well, we could. Some Hackathons have prescribed challenges to streamline things. I guess this way works too!

I knew I wanted to do this Hackathon because I had a pretty cool idea that I knew would win. I validated the idea with other Grabbers, drafted up target segments and sample value prop statements, and then proceeded with forming the team.

Recruiting team members

I was targeting a product space that I wasn’t involved in. As a product manager on the Driver App team, I had little context on the consumer side and my idea was completely on the consumer side. I asked people that I trusted to recommend people they trusted — at least the recommendations were within 1–2 degrees of trust.

I first created a mini-pitch to sell to the recruits, and then I broke it down by who I needed:

A product designer was a must and I focused all my efforts to get this one
Front-end engineers: I knew I needed at least two. I also knew I wanted to maximize our teams output and accessibility of the product, so I opted to find Flutter pros and dev the entire experience on Flutter. As Flutter is still an emerging tech in Grab, it was really difficult to find someone willing and also good. In the end, recommendations are the best / only way to go.
Back-end engineer: I recruited a back-end engineer that I always work with. The trust was there and I also knew the skill was there.
Analytics: Someone to help with pulling numbers and helping with setting success and guardrail metrics. One analytics would be good enough and came under recommendation.
Business: It was a bit harder to find a business owner. I was thinking about business roles, but I decided to pivot and look towards product marketing. Why? We could team up and cover a lot of the business side of things but I needed another advisor for core messaging and positioning. Good thing I went this route!

Team was recruited and it was time to tackle the problem 💪 🏎

Game day

We cheated a bit 😆 We did some exploratory work before hand as we had a solution in mind already. Realistically, a lot of teams probably did this too, otherwise the time-frame is simply not enough to design and build a full product.

Something important for us was organization. Who was doing what and by when, and how can we resolve dependencies and conflict. With only 48hrs, we had very little time to form a team and build trust. As the product manager, I had to be at the center of everything to make sure all the gears were greased and working well.

To help build that trust in a short time frame, I decentralized decision making and trusted members on the team. We voted wherever possible, leaned on experts, and made sure every team member was on board with decisions. I avoided “agree to disagree” situations as it’s simply not helpful. This worked really well and we built cohesion fast.

We were building a P2P marketplace for users to create listings for others to book. We decided to skip one side of the marketplace (the creator) and focus on the customer experience. We wanted to make it as immersive as possible so that the content was engaging.

Prioritizing work — parallel paths

The very first thing we did was knock off designs for the core structure of it and the entry point into the experience. Doing so unblocks front end engineers and gives the back end engineer an idea on how to structure the API.
While that was being done, we worked on the presentation structure, storytelling, metrics, and opportunity sizing. These were independent of the design and dev as we had a clear idea of what the product will be.
Once design was done on core structure and entry points, he shifted to details and additional experiences, and then we shared with dev so they had their backlog prioritized.
Meanwhile, we started working on the actual pitch and how the overall story should flow.
Last, once it all came together, we all did QA / desk checks, and then ran through the pitch together.

head over to our designer’s Twitter to see the video of it https://twitter.com/tridipthrizu/status/1320182486966521856

Common Tools 🛠 that we used:

Slack was a must and helped with a lot of things like alignment, communication, etc. I think the devs had a secret channel which helped streamline our conversations in the main channel.
Zoom was the next most important tool to make sure we communicated faster and got points across clearer.
Figma was where all our designs and prototypes were. Devs exported files from this, and design designed directly on it.
Google Slides was great for drafting out all the deck content collaboratively. Suffered in how it looked though!
Pitch helped beautify our slides and make it way more sellable.
Whimsical was great for collecting our teams thoughts. Basically, it’s a virtual whiteboard.

So, did we win?

Pitches were only 8 minutes. We didn’t have a lot of time at all. This was how we structured our deck

Intro (20 seconds)
Problem statement and context (40 seconds)
Product vision (30 seconds)
Product demo (4 minutes)
Impact and success metrics (1 minute)
Platforming tech to go faster + opportunities (1 minute)
Inspirational ending / call-to-action (30 seconds)

30 seconds before our pitch, our prototype broke 😩

I asked our dev to make the content look better. When he recompiled the app, it broke and wasn’t performing properly. Sometimes in tech, when you fix one thing, something else unrelated breaks. Luckily, our design whiz saved the day by having a Figma prototype ready to go. MVP right here!

We were invited into the Zoom room where the judges were and we nailed our timings. They asked questions and then we were asked to leave.

A few agonizing hours later, we found out the results.

We didn’t make it to the top 12.

My heart sank. The first thing I thought about was my team. They poured 48+ hours of continuous effort into this and had high hopes of getting at least top 12.

Consolation was that we did pretty well considering (we came top 20 I think and it was neck and neck there on out). Lots of people were really impressed with our idea and our execution of it. Many even said that they wanted it built ASAP.

Would I do this again? + Learnings

I probably would do this again. I was really excited about the idea and I practically cried 😭 when I saw the working prototype. It was beautiful. Huge props to our team for pulling this off!

It was really mentally draining though. Staying up late and stressing out over this… plus the emotional rollercoaster of being excited for it, hoping to win, and then not winning…

I don’t think I’ll be doing another Hackathon any time soon — unless it’s for a social cause!

Things I learnt:

We can create a lot in a very short time frame. Trust your team and they’ll create amazing things.
Be organized. You don’t have time to waste and you need to mediate while ensuring everyone is onboard.
Set clear roles. Clearly defined roles will help keep things moving smoothly.
Not everything needs to be developed. Focus your energy on dev’ing the things that will drive maximum impact.
Also set expectations from those roles!
You probably don’t need 90% of the stuff in your pitch deck.
Things will break. Have 10 backups ready to go.
Build trust fast.
Parallel path whatever you can.