Hackathons as a Product Discovery Tool
Hackathons as a Product Discovery Tool
At Cognizant I organised two hackathons that produced 13 new consumer banking ideas, and then worked with technical teams to build a working prototype. That experience changed how I think about hackathons. They are often run as morale events. Run well, they can be a real source of product ideas.
Give people a real problem
The best hackathon briefs are specific. "Build something cool" produces demos. "Help customers manage their bills more easily" produces ideas that connect to a real need. A clear problem statement, grounded in what you already know about users, gives teams something to aim at.
Mix the skills in each team
Ideas get better when engineers, designers and business people work on them together. Engineers see what is possible, designers see how it will feel, and business people see whether anyone will pay for it. A team with only one of those views tends to build something lopsided.
Judge ideas as products, not as demos
A polished demo can hide a weak idea. When reviewing hackathon output, I find it useful to ask product questions: who is this for, what problem does it solve, and how would we know it worked? Those questions separate a clever build from something worth taking further.
Plan what happens on Monday
The most common failure of a hackathon is that nothing happens after it. Before the event, decide how winning ideas will be picked up, who will own them and what support they will get. Turning an idea into a working prototype with the technical team is the step that makes the effort count.
Small events, real signals
A hackathon will not replace user research or a product strategy. It is one more way to surface ideas from people who know the domain, and to test them quickly before committing more time.
Sidhartha skipped presentations and built real AI products.
Sidhartha Pooboni was part of the August 2026 cohort at Curious PM, alongside 24 other talented participants.