RHB Get Your Hack On 2023: How We Hacked Our Way into the Grand Finals
- Published on
- Muhd Rahiman · 34 min read
Table of Contents
Introduction
"CONGRATSSS RAYYYYY"
"Let's freaking go, Ray!"
Such were the reactions from my teammates on Discord and iMessage when my name was announced as the Best Presenter at the Grand Finals. Overwhelmed by fatigue—having only slept for an hour since the day before—I was completely unfazed and stared at the Airmeet window on my screen with a blank, poker face.
Moments later, our team was awarded the consolation prize for being in the top 10—which is already to be expected (it’s honestly a miracle we even reached this far as first-timers 😅).
But now that my soul has fully reentered my body and my vitality replenished, I plan to dedicate a blog post detailing the whole experience i.e. what happened, what we nailed down, what we did wrong and what others can learn from it.
How it Began
The story began when an old high school acquaintance-cum-debate-rival of mine reached out on LinkedIn for a hackathon collaboration opportunity. This was how I first found out about the hackathon’s existence.
If I learnt anything from my Hack2Hire experience—which was my first hackathon—two years back (can’t believe it’s been that long), it’s that camaraderie is important. Whether you and your teammates’ work ethic compliments each other matters a lot.
Hence, despite there being a desire to try and team up with a couple of strangers just for the thrill, I decided not to at the last minute. I figured, for a hackathon of this scale, it might not be worth the risk. Instead, I texted my partner-in-crime Faidz if she was interested; giving me a slight deja vu feeling as that was exactly how it all started for Hack2Hire as well. Thankfully, she gave me a thumbs up.
Before I proceed any further, I should probably clarify: Even though this was my second hackathon, the decision to participate in this next one wasn’t as straightforward. For Hack2Hire, the main hurdle was imposter syndrome. This time around, it’s not just imposter syndrome making a comeback, but also more importantly time and energy. Much has changed since then, the most obvious being that we’re both working adults. So, we don’t exactly have that much spare time at our disposal to work on the hackathon. Sure, it’s not impossible, but it’s not going to be easy either.
So, part of the reason why I decided to join was related to that: trying to prove to myself that while I’m no longer a student and wasn’t as carefree, I still have it in me to win or at least do well in a hackathon. Yes, I understand that by saying so, I made it sound like it's been years since I graduated (melodramatic, much?). But, a lot has changed in me both mentally and physically compared to my student days. For example, I can barely pull off an all-nighter these days when that used to be a piece of cake back then. Is this what adulting can do to you?
Knowing that Faidz is on-board, in any case I would’ve just stopped there. Most of the time, the Raidz duo can handle a lot and can put up quite a fight. But, that wasn’t an option for this hackathon, as the rules mandated that each team must have a minimum of 3 members with at least 1 programmer. So that marked the beginning of the quest to find the remaining 1-2 members—which turned out to be harder than expected.
Because pretty much all of my peers are working, the ones that I approached (whom I felt comfortable teaming up with and who can bring value to the team) declined the offer. I got so desperate to the point that I even tweeted on my private account to ask if any of my circle of friends there are interested.
Thankfully, it was because of that tweet that I managed to find the remaining 2 members of my team; Aiman and Muhaimin. After that, I filled in the team details in the registration form and submitted it. In the process of doing so, I realised I didn’t discuss with my team on what to set for our team name. It’ll be too time-consuming to gather the thoughts from them. So, I just set out my way to use my Discord name, Halcyon, as the team name.
Anxiety kicked in afterwards as our team’s registration is not confirmed until we receive a confirmation email from the organiser, JomHack. But fortunately, it didn’t take long for us to receive said email.
Tip #1: Form a Balanced Team
Due to the product-centric nature of this hackathon, how you assemble your team matters a lot. If possible, form a holistic team composition by having members from different backgrounds and skill sets.
For instance, in my team, while Aiman is also experienced in web development particularly Vue (no surprise, since we all came from Software Engineering backgrounds), the 2 areas where he had been of tremendous help were his financial knowledge (particularly in investments) and graphic design expertise. He helped design the UI mockup for our app as well as the pitching deck which played a huge role in supporting my pitch.
On the contrary, having a homogeneous team composition (e.g. a team of all web developers) decreases the likelihood of diversity in thinking and exchange of ideas. Instead, form a team of different subject matters experts depending on your proposed solution. For instance, you might want to have a person familiar with A.I. if—say—you plan to use machine learning.
The Prep
As the team lead, I immediately created a private Discord server for the team. In our first call, the very first agenda that I set out was managing expectations. I told the team upfront that realistically speaking, our winning chances will be slim after considering the scale and prestige of this hackathon. Since it’s Aiman’s first hackathon and the rest of us are still relative newbies, we should focus on just doing our best and learning from the experience.
Yes, I know. What a demotivating way to kick off the team discussion. But as a highly-competitive/kiasu individual, it’s my way of ensuring that I don’t get deeply disappointed and beat myself up too much if things didn’t go our way. It's better to underpromise, then overdeliver.
Since the Discord server creation, we had around 1 week time of prep prior to the start of the preliminary round, which lasts from the 13th until 15th January. There are a total of 5 challenges to choose from, and a bunch of lucrative prizes to win that you can see for yourself (which admittedly, is also another factor that attracts me to this competition).
During that time, we had a total of 5-6 meetings, all held at night since we were working during the day. They were centred upon a few things, ranging from ideas brainstorming, tech stack confirmation, task delegation and role assignment. It was during these meetings that we made some good decisions and newbie mistakes, especially for this type of hackathon (more on this soon).
Tip #2: Plan Your Schedule
Hackathons are synonymous with burning the midnight oil and pushing your limits. After all, time is of the essence and you need to make every minute count.
Hence, it’s important to come up with a draft of your team’s schedule. Break down each day into several time slots and allocate specific agendas to each. That way, not only you'll be more organised, but it’s also easier to ‘quantify’ how much progress you’ve made and whether your team is on track.
That said, it’s equally crucial to leave room for flexibility. Trust me, in a high-octane environment such as a hackathon, it is not a matter of if but rather when things will not go according to plan (that doesn’t mean we should abandon planning altogether). Be prepared to adapt to last-minute changes. Remember, the schedule is just a guide, not a Bible.
Tip #3: Tech Stack Doesn’t Matter As Much
Right off the bat, we spent too much time arguing in determining what framework to use. Borrowed from our Hack2Hire experience, we thought the working prototype has to be built from end-to-end. To make things worse, each of us had familiarity in different frameworks and languages.
But the thing about this type of hackathon that leans more on product design is that it doesn’t put that much emphasis on how you code the prototype. As long as it works and it’s able to visualise and translate your abstract ideas into something concrete, that will suffice.
So, prioritise ideation over technical implementation. A great idea with minimal prototype > solid prototype with a half-baked solution.
But that's far from being the only mistake we did during this stage. Another one is related to how we conducted the ideation process itself.
Tip #4: Optimise Your Ideation
Throughout the ideation process, there was a lot of judgement involved. As we go through each proposed idea, everyone is playing the devil’s advocate role, trying to scrutinise and figure out every foreseeable flaw for every idea. We essentially took turns shooting down or breaking each of our ideas apart, and that creates this aura of negativity that just demotivates everyone.
In the end, the goal of the ideation process is not so much about finding the overall best idea that strikes a balance between technological feasibility, business viability and human desirability, but rather the idea with the least flaws.
Don’t get me wrong. It’s not that scrutiny has no place in the ideation process. Every idea will eventually have to be evaluated based on factors like business value, innovation, feasibility etc.
Instead, it’s how we scrutinise that matters.
A foundational principle in the earlier stages of ideation (that I came to learn when I was attending a talk as part of the Dell Digital Malaysia Regional Summit during the same week of the hackathon) is deferring judgment. Instead of looking at each idea and thinking "How can this idea fail?”, why not change the mindset to “How can I make this idea work?”.
Such a simple mindset shift makes a huge difference. In a way, you’re still scrutinising the idea but in an optimistic manner that’s conducive and incentivises creativity.
In other words, we should be solutions-driven, instead of problems-driven. We don’t just stop short of finding faults for the ideas, but figure out a workaround, compromise or trade-off.
We also indirectly tried hastening the ideation process because we were too concerned about the implementation details (as explained earlier). While there should be a time limit set for ideation (dragging it too long would lead to a rabbit hole and the discussion will take forever), it shouldn’t be rushed either. Members participating in the ideation process shouldn’t feel pressured to come up with ideas in any way.
The final nail in the coffin was that sometimes we strayed too far in ideating that we forgot to refer back to the challenge chosen. It’s important to always ground ourselves and cross-check whether any of the ideas fulfils the objective and answer the problem statement(s). Otherwise, you’re just going to syok sendiri.
It was during our second-last meeting before the hackathon kick-off when observing that we were debating our ideas endlessly that I decided to push the reset button and told my team about what I learnt/realised and proposed restarting the whole ideation process based on these guiding principles.
And thank God we did. Because it was after starting over that we eventually finalised our idea (or at least the main differentiator of our solution) that propelled us to the Grand Finals.
Tip #5: Choose The Right Collaboration Tool(s)
One of the best ways to optimise your ideation (apart from the ones that I mentioned) is to visualise them. There’s a reason why the ideation process is often stereotypically depicted with sticky notes being stamped on a whiteboard. It is through the inspiration of said stereotype that I decided to use Miro as our team’s secondary collaboration tool aside from Discord.
At first, I wanted to use my good ‘ol friend, Trello. Trello has been a tremendous help for Hack2Hire and my student life in general. But because I was too busy throughout the hackathon week, I didn’t have time to properly organise everything into a Kanban board. I also hesitated in adding yet another platform as that means more things that we have to maintain and worry about, as well as more context-switching. We already have Discord, Figma and Airmeet. Like, how much is enough?
- Airmeet doesn’t have persistent save chat history. Also, its chat feature is terribly minimal.
- Discord is still necessary for dumping resources and references, but not suitable to share and visualise our ideas, system flow etc. A lot of scrolling is also involved when navigating the content.
- Figma is dedicated entirely to high-fidelity prototyping. I don't want to mix its use for other purposes.
Miro fits in to fill the gaps by allowing asynchronous and real-time collaboration without having the need to share screens e.g. we can follow a person’s cursor to know what they’re doing/trying to highlight. Technically, Figma supports the same feature but I find Miro is easier and I want Figma to be dedicated purely to mockup design.
In fact (spoiler alert), our use of Miro actually got praised later by the mentors who came to visit us. So, there’s that!
All that being said, we must remember that at the end of the day, these are just tools. They are mere means to an end. You can use the best or as many tools as you want and it still won’t guarantee success for your team. It’s how you utilise them that matters.
Preliminary Round
It's Friday the 13th (hah!), and that marks D-Day. The hackathon kick-started in the morning, mainly with a briefing on what will transpire for the next 3 days. The real work begins in the afternoon when we will have our first mentor hours slot. This is where each team gets the chance to consult with mentors from different backgrounds and expertise. Before that, each team is required to fill in the brief details of their draft solution so that the organiser can assign the right mentor for you.
This leads to my next tip:
Tip #6: Fully Utilise the Mentors
Truthfully speaking, our team was a bit too passive to my liking when it comes to consulting mentors. Don’t get me wrong, we did meet up with a total of 4 mentors. One came from a legal startup background, another was a startup founder specialising in chatbots and 2 more were actually from RHB's insurance department itself (big shoutout to Ms. Lydia!). But, I felt like not only we could interact with more mentors, but we could also be better prepared with the ones we met especially in terms of the questions that we would like to ask. The type of questions you ask affects the quality of mentoring and feedback you get.
If a hackathon provides a mentoring service, please utilise them to the fullest. Don't be afraid of getting mentor/outsider feedback and ask as many questions as possible. Let others break your bubble and verify your thought process.
That being said, when getting these consultations, sometimes the mentors might poke holes in your ideas or fundamentally disagree with your overall approach to solving the problem statements. Such was the case for my team on the second day, where we had this 1 mentor who outright told us that not only did we choose the most popular challenge (Challenge 3, related to improving financial literacy among young adults), but our solution (which involves a chatbot) is not unique as other teams had come up with a similar idea. These 2 reasons will made it extremely difficult for us to stand out above the rest.
This leads to my most perplexing, controversial and contradictory tip yet:
Tip #7: Know When to Stand Your Ground
Don’t immediately surrender and scrap everything you worked on the moment the mentors or anyone finds weaknesses in your ideas. Most of the time, you don’t just outright bulldoze your house when you find structural defects, right? Likewise, you can’t just give up and be done with it every time anyone challenges your thought process. Instead, have a firm belief in the solution that your team came up with and fully commit to it. Use the feedback received to further strengthen your idea instead of demolishing it.
In my team’s case, we got demotivated after getting the aforementioned mentor’s comments. But as the lead, I told the team that we can’t afford to change the core idea behind our solution at the last minute and encouraged everyone to commit to it the best we can, especially since we already finished the design mockup and started working on the MVP already. Had we lost our guard and changed our ideas again, we might risk losing our winning chances and not qualified for the grand finals altogether.
Tip #8: Split the Team Roles
Throughout the preliminary round, everyone in my team got so caught up with developing the prototype that we found ourselves scrambling to work on the pitching deck. I mean seriously, we legit only came up with the problem statements, business value and all hours before our pitching. Please, don't do this and don't be like us, folks!
Hence, another useful tip that is derived from this experience is to try not to have everyone in the team fully involved in coding the prototype. Perhaps, appoint someone to become the product manager, who helps to conduct research into the product design aspects of your solution e.g. problem statements, business value, market research, value proposition, key success metrics etc.
The technical implementation of the prototype only accounts for a third of the total scoring rubric for this hackathon, while the rest comes from the aforementioned criteria. Of course, these can be discussed together as a team, but I recommend that you have at least 1-2 individuals to lead the research arm of your team.
Note that the above tip comes with a huge caveat: It depends on the type of solution you bring, the number of members and respective skill levels in your group. Some ideas may be easier to implement its MVP than others, and therefore need less manpower. Meanwhile, if you only have the bare minimum number of members, you don't have much choice but to have everyone wear many hats all at once.
The takeaway here is to take everything into consideration when you're doing capacity planning. Every team composition is unique, so there's no one-size-fits-all strategy.
Tip #9: Organise a Physical Meet-Up If Possible
On the last night before the final day, our prototype is still around 60% done and we haven’t even prepared anything for the pitching.
Since Faidz and I are the main developers and we live nearby, we decided to have a physical meet-up at the very last minute at a Starbucks, hoping that easier communication between the 2 of us will help expedite the development.
Long story short, it did. Faidz even told me in our first call to kick-start our grand finals preparation that the decision to a meet-up that night made a huge difference and changed our team’s trajectory. So much so that for the preparation for the grand finals, nearly all of our meetings were physical.
Admittedly, not every team has the privilege to meet up the way we did especially if your team members are far away from each other. But if possible, do so. Putting aside the obvious advantages, hackathons are just better to be experienced face-to-face. That’s how it was pre-pandemic, and I hope it will return to that state soon.
Fast-forward to the presentation day, and honestly, we were excited to just get it over with. Faidz, Aiman and I stayed up until Subuh the night before and only had a few hours of sleep. We didn’t even shower before our pitching 😂 (I might regret revealing this information).
Since this is just a preliminary round, each team will just present at their respective tables in Airmeet and the judges will come to visit. Surprisingly, the pitching and demo went smoothly. I was caught by surprise when one of the judges (who consisted of the mentors) directed their questions through the Airmeet chat. Usually, judges would ask questions verbally.
Nevertheless, I think I handled the Q&A session well as I had this satisfying gut feeling and it was also accompanied by compliments from the judges before they jumped to another table.
However, being the pessimist that I am, I still felt that we won’t stand a chance to get into the finals. But imagine my surprise when our team’s name was announced as among the top 15 finalists.
I’ll just let both the Discord screenshot and Aiman’s Instagram story do the talking.
I remember watching the announcement on my phone while lying in bed in the afternoon trying to sleep. 😂 I was almost certain that our journey will end there and that I get to enjoy my CNY break. But I guess, life had more in store for me (not that I'm complaining though).
Grand Finals
For the Grand Finals, we decided to focus on upgrading our prototype and improving our pitching. I guess at this point, I should briefly mention what our team's solution is all about.
Our solution proposed an all-in-one financial management app that turns your complicated money life into a simple chat with a witty virtual assistant that can resonate deeply with Gen Zs. We intend to unite the fragmented financial management feature from 3rd party apps and consolidate them into one, backed up by research indicating that nearly 3/4 of Gen Zs would use a single bank if they found one that meets all their needs. However, the Gen Z-centric chatbot is our main differentiator, with unique features that enable the user to get ‘roasted’ or ‘hyped’ depending on their spending habits and ask for a laymen’s explanation of financial jargon which is littered in many banking sites/apps.
Tip #10: Don't Upgrade Your Stack At the Last Minute
Previously in the preliminary round, we built our prototype as a web app using Nuxt 2 and Tailwind CSS, but only with mobile view and responsiveness in mind. We developed the whole thing almost entirely in Inspect Element mode, with the device toolbar enabled. The code was all over the place and it's a miracle that the demo went smoothly. Not to mention that we struggled in integrating other plugins due to most of them being tailored towards Vue 3.
After conducting a short post-mortem during our first post-preliminary round call, we decided to upgrade the stack to using Nuxt 3. It was a gamble because none of us was familiar with Vue 3. So, the next 2 weeks were spent mastering the basics of the Composition API. Spoiler alert, it’s so much better than Options API in Vue 2 and I’m honestly grateful because if it wasn’t for this hackathon, I wouldn’t have had the incentive to learn Vue 3.
For the CSS framework, Tailwind CSS is still used but on top of Ionic Framework to give the app a more native iOS look. This is also a risky move because Ionic is highly opinionated. Although it vastly improved the UI/UX of our app in the final version, the process of integrating its UI components into Nuxt was hell.
More importantly, we (finally) utilised the AWS free credits that were awarded to each team during the preliminary round by integrating Amazon Lex into our app to automate the chatbot logic, mainly using intents. It took a while to get used to at first. The AWS UI looks so dull and old-school compared to Azure. There was minimal documentation on how to integrate Amazon Lex into Nuxt, making my life much harder. But after a bit of Googling, I finally managed to do so. Being able to separate the chatbot logic from the rest of the app and offload it to AWS makes for a cleaner, more optimised code.
For the financial jargon simplification feature, we used OpenAI's DaVinci 3 GPT-3 model API. That was fun to explore as well and caused less of a headache than the rest to integrate.
While all these changes proved to be somewhat worth it in the end as our final prototype looks vastly superior to before, the last-minute change in the stack is not something that I’d recommend for everyone to do. So much valuable time was wasted in learning, integrating and debugging which could’ve been better spent solidifying our pitching.
For instance, the switch to Nuxt 3 meant not all codes in the previous version can be reused straightforwardly. My inexperience in using Amazon Lex led to a lot of trial and error being done along the way to debug. However, the biggest culprit to the time wastage goes to the Ionic Framework, where we faced a lot of friction as for some reason its UI components aren’t fully compatible with Nuxt.
In the end, despite having 2 weeks at our disposal, we only began working on improving our team’s pitching at the very last minute. I kid you not, I started writing my script 1.5 days before the Grand Finals. The revamped deck was completed less than 6 hours before our team’s turn. Heck, we only figured out our solution’s key success metrics before Subuh!
Had we allocated more time to the non-technical aspects of our solution, we wouldn’t have been so unprepared. Because spoiler alert, our team got hit hard during the Q&A session because of it, which most likely have cost us our chances to make it in the top 3. As the sole presenter, I basically butchered my answers—so much so that both judges who directed questions at me expressed their disappointment. One of them shook their head while the other outright told me I didn’t answer the questions well.
This leads to my next tip:
Tip #11: Have Other Team Members on Standby for Q&A
The biggest disappointment I had towards my team was when none of them was able to back me up during the Q&A, despite already reminding them several times prior that they need to be on standby for my cues in case I’m not confident enough to answer the questions myself. As the sole presenter who was also sleep deprived at the time, I predicted that, unlike the preliminary round, my mind was already too convoluted to not be able to handle the questions effectively.
Unfortunately, at one point during the Q&A, I already gave the cue/S.O.S message but no one stepped in. It led to this awkward, deafening 5-second silence where I’ve never felt lonelier in my life.
I immediately expressed my dissatisfaction to the team on our Discord call right after the presentation. To be fair to them, the questions were rather difficult to answer, so I can’t pin the blame entirely on them. But I guess this is a good lesson learnt for us, and also anyone reading this.
Make sure other team members who aren’t presenting are on standby for Q&A in case the presenter(s) could not answer the questions. This means not only being alert during the call and ready to jump in to answer, but also helping brainstorm possible questions and their answers in advance before the presentation itself. Trust me, how your team handles the Q&A can make or break your team's winning chances.
I’ve watched some of the other finalists’ presentations and noticed that during the Q&A, some of them have a dedicated team member aside from the presenter(s) to help answer the questions. This is a good strategy, as you’d want the presenter(s) to focus entirely on the pitching and demo narration. They’ve already anxious and under pressure on performing well for the pitching. The worst thing you can do is to add one more thing for them to worry about during the presentation. Of course, if you're versatile enough to be able to handle both, by all means, go ahead. That would've been the case for me if I was given enough time. Alas, there's no point crying over spilt milk, am I right?
Anyway, as you already know from the introduction, our team ended up getting the Top 10 consolation prize and I was crowned Best Presenter at the Grand Finals. To be honest, I still have no idea how and why the judges chose me for the special award as I felt unqualified and undeserving, having mishandled the Q&A session earlier.
No, I’m not humble-bragging. The presenters from the Top 3 teams were all splendid, and I felt it could’ve been better awarded to any of them. I was personally rooting for my friend Shawn, who teamed up with my junior Alif (and eventually crowned as Champion!).
Nevertheless, I can’t change the fact that I won the award. So, there must be something that I did right, right?
Cue the final tip!
Tip #12: Pitching is all about Storytelling
In the preliminary round, there was frankly nothing remarkable about our team's pitching. The way we conducted the flow was akin to a typical presentation; start with a quick greeting, followed by a rundown of the problem statements and then the prototype demo and lastly the product business value.
But after qualifying for the grand finals, I knew from the get-go that we can’t afford to stick to that same boring pitching “problem, solution, benefit” approach if we want to even remotely have a chance to win. I told my team that even if we don’t win, we better lose with dignity knowing that we put up a strong fight. In the worst-case scenario, if we can’t win or stand out through our ideas, we can maximise our winning probabilities in another area which is our pitching.
You see, people often care too much about the content of their presentation to the point that they overlooked how they plan to deliver said content. There is no point in conveying all that information if your audience can’t retain it.
Because the pitch is only 5 minutes, how you hook your audience and grab their attention is of paramount importance. Remember: “An audience forms its impression of you in just fifteen seconds”, says seasoned executive communications coach Neil Gordon. How you deliver in those precious few seconds can set you up for success or failure.
Listeners need to be engaged from start to finish to have an effective pitch, and one of the best ways to do that is through storytelling. Storytelling is a powerful tool that allows you to connect with your listeners on an emotional level and hold their attention.
You see, no matter how technical the target audience can be, they don’t remember data. After all, the average person's attention span is now shorter than that of a goldfish — lasting roughly eight seconds.
What they do remember is a story. Studies have shown that our brains are more active when we're listening to a story because they tap into our emotions and allow us to connect with the person telling it. As the wise Maya Angelou puts it: “People will forget what you said, people will forget what you did, but people will never forget how you made them feel.”
In the context of a hackathon, you can use this storytelling approach as a way to introduce the audience to your problem statements from the perspective of your target user group or personas. You want them to feel connected with the personas as they go on a journey, empathise with their pain points and imagine what it’s like being in their shoes. Utilise anecdotes of others or even yourself.
This might feel manipulative, but I beg to differ. As humans, we are wired for stories and whether we like it or not, we desire for pathos. So, all that we're doing is to fulfill said demand.
Verbal storytelling is one thing, but it also has to be supported with the right visuals. How you craft your pitching deck matters as well, and often this is where the bottlenecking often occurs.
The trick is simple: Less information per slide, more slides. To do this, we employed a combination of 2 different alternative presentation methods.
The first is the Takahashi method. It is a technique that is all about text and uses simple and refined visuals, particularly large block fonts. By right, a true Takahashi presentation doesn’t include any charts, photos or pictures. It only includes words, and only a few on each slide, printed and in large characters. This YouTube video best explains in depth what the Takahashi method is all about, in case you want to learn more.
The next one is the Lessig method, named after Harvard professor Lawrence Lessig. The Lessig method is not an official method of presentation style per se. The name was coined by the people who have had the opportunity to witness his TED Talk. It’s related to a Takahashi style in that they both focus on the concision of time and visuals. However, Lessig also emphasises for speakers to synchronise with the text on their slides.
Aiman was also kind enough to recommend to me this 20-minute TED Talk that talks about the major sins when delivering a presentation, which I think you should give it a watch!
For this hackathon, the organiser, JomHack recommended that we have 5 slides max. for our pitching deck. “Screw them, we’re going to do this our way”, I told my team. I conveyed this criterion to Aiman who was in charge of designing the slides. I even asked him to refer to how Apple typically design their decks, to the point where we even ended up using Apple’s proprietary San Francisco fonts in our deck.
For the persona, we came up with an imaginary character called Ben, who is a 19-year-old. He was originally named Omar, but I changed it to Ben as it reminds me of this colleague of mine at Dell whose personality is rather suited to the character. Instead of just stating the facts blatantly, what we did is that we frame all the problem statements we identified in the form of a monologue or dialogue that Ben would say, which are all supported by citations embedded in the slides’ footer. Here are a couple of excerpts from the deck:
After a lot of back-and-forth in adjusting both the script and the deck, you can watch the outcome here and judge for yourself whether I was deserving of the award:
Conclusion
So, there you have it! 12 lessons or tips to share from this valuable hackathon experience.
Granted, it's only from our team's perspective as a top 10 finalist which doesn't give that much credibility to the bits of advice given unlike the top 3 winners for example. Nonetheless, I hope they will still prove useful to everyone reading them.
The best part of all this isn’t the prizes or prestige, but rather the new skills and added wisdom I picked up along the way. Earlier in the post, I mentioned how I wanted to participate as means of proving to myself that I still have it in me. I guess the point is proven(?), I let you all be the jury for that.
Regardless, I will definitely take a long hiatus before I dare try to get involved in another hackathon. 😮💨 I can see myself serving more as a mentor rather than a participant in the future. We'll see how it goes.
To wrap up the post, here's my most favourite and memorable photo of the team during our last physical meet-up at McDonalds Pantai Dalam, 2 days before the Grand Finals:
Thanks again, team! It's been a while ride and I couldn't have wished for a better group of people to experience this with. 💙