Joey Koh

Recent Notes

See 36 more ā†’

How to Win

7 min read

Want the key takeaways extracted from 24/34 wins, 40+ hackathons and 26k+ words of learnings?
Follow me on LinkedIn and Twitter to hear first šŸ˜‰ or if you prefer videos subscribe to my YouTube!

Jump to the Table of Contents

Train hard, fight easy

Hackathons are both an art and a science.
There are many ways to ā€˜winā€™ a hackathon and to ā€˜loseā€™.

How can a team of first-time hackers working together for the first time win grand prize over the veteran teams who planned it all out? How can small scrappy startups beat big companies with better engineers and more resources? There is simply more to it than the ā€˜traditionalā€™ and ā€˜on-paperā€™ advantages.

I'm not here to tell you how to win in ideal situations

By gathering a team of 10x engineers & elite hackers and do enough prep to min-max whatever you build?

To me, thatā€™s unrealistic ā€“ the real-world is never that ideal or timely. Just think of when you joined any new team at work, that uni group assignment, that startup idea you have, even your relationship with your family ā€“ are those conditions ever ideal? Do you just give up then?

So instead, Iā€™ll offer my perspectives and experience from the position of delivering under constraints and limited resources ā€“ the position of reality.

My rather atypical path taught me how to execute in the toughest situations ā€“ over and over again. If you can perform when itā€™s difficult, and learn to empower your team to also do so ā€“ imagine how powerful you would be any situation.

This is for those who enter hackathons alone, who know few, who donā€™t have an elite team, who work with strangers, who donā€™t have a background in CS or industry experience ā€“ but who make the most out of any situation.

For those who hold a spark, who try, who want to make something people want, who dream big, who think different, who can empathise with people, who want to grow, who surpass themselves, and who donā€™t make excuses.

Summarising

Iā€™ve consolidated my learnings, feedback and personal reflections from all my hackathons and other experiences into concepts and principles both non-technical and technical.

What are we are trying to do? We as a team of people want to build a product that people want.

Essentially, a system with inputs (you, the team) and outputs (product).

How to Win - Table of Contents

Non-technical Standpoint

Mindset šŸ§ 

How you perceive reality and act upon it. What determines your trajectory. Foundational and core to everything. The Why, before the How and What.

People, Teams, Leadership šŸ‘„šŸ¤

Soft-skills. Downstream of mindset. What makes the journey more fun and likely to succeed.

Product šŸ“¦

Navigate the fog of war and seek truth

  • Alignment
  • The Skillset Domain Requirements
  • The Ideas Bank - interest, appreciation, depreciation, withdrawal, derivatives
  • What is a Product?
  • Product-Market Fit
  • Founder(s)-Product Fit
  • Fog of war and Discovery
    • Problem segmentation
    • Talking to Users
    • The User and User-stories
    • Narratives and Storytelling
    • The Vision
  • Paradigm Shifts - what if we empowered anyone to litter
  • Differences between hackathon products and products for real-users
  • Stupid Questions and Stupid Ideas
  • Validation
  • Which idea to work on
  • Hedging Bets, Low-hanging fruit, and Identifying Opportunities
  • Shaped Ball Analogy - Fitting Problems into Solution Which came first? the problem or the solution?
  • Being scrappy
  • North star
  • Whiteboarding
  • Design Thinking
  • Frameworks
  • Templating
  • Design - UIUX
  • PM Tools
  • Kanban - a good task
  • Meeting minutes and notes
  • Refinement of insights
  • Time-boxing
  • Pivoting
  • Mentors
  • Stakeholders
  • Stretch Goals and Core Features
  • The Pitch
  • Conveyance - biases, the 5 senses,
  • The Deck

Technical Standpoint šŸ› ļø

1x engineer, then 10x, and hacker-mode

a small disclaimer on sharing context while respecting privacy

Frankly, I have no idea whatā€™s the perfect way to fully share a story and respect the privacy and identities of any parties involved. Itā€™s something Iā€™ll get better at over time.

I have many stories of good and bad experiences working with people. I love sharing the full details when itā€™s a positive experience and shoutout great people Iā€™ve worked with. For the less positive experiences, they still yield important lessons to be learnt ā€“ hence I believe itā€™s still valuable to share.

Show, donā€™t tell.

Just like in product demoā€™s, I try to show and not just tell.

If a concept could be conveyed, digested and internalised by simply reading or hearing the key takeaway ā€“ most non-fiction books would be 2 pages, and talks could be cut down to a couple sentences.

Humans love stories, itā€™s how our past cultures passed down lessons and how we resonate in a particular way to a message ā€“ drawing from similarities and comparisons to our own unique experiences.

For any negative example of working with someone, Iā€™ll always try to respect and maintain their privacy. Unfortunately, some stories I share have more weight with corresponding facts and context revealed. Iā€™m still finding a balance in the trade-off between sharing the full story context vs respecting the privacy of those mentioned.

One of the biggest reasons I put myself out here is to share learnings and experiences. And I hope some resonate. So, I want to and have to provide enough context in my stories.

As much as I try, Iā€™ve realised that a seriously determined individual could put all the scattered pieces together and make guesses on the identity of whoever I might talk about. Iā€™d encourage you to not waste your effort and energy doing so ā€“ itā€™s not worth it. Focusing on the takeaways would be more fruitful.

Graph View

Backlinks