When someone first suggested I join our team's hackathon, my gut reaction was polite skepticism. Hackathons are for developers, right? People who can actually build things? What was I going to contribute? A well-structured problem statement while everyone else pulled an all-nighter?
I went anyway. And it changed how I think about my job.
If you're a PM who's never done one, this is for you.
They're not really about the code
Yes, something gets built. Yes, there's a demo at the end. But the actual value (for you, for your team, for the way you all work together) happens in the gaps. In the arguments about what to cut. In the moment someone realises the thing they've been building for three hours isn't what anyone agreed on. In the look on a stranger's face when they try your prototype for the first time.
Hackathons are a pressure cooker. And pressure cookers are remarkably good at showing you what's actually in the pot.
You'll do your job in public, and that's a good thing
In day-to-day product work, so much of what you do is invisible. The decisions that prevented the wrong thing from being built. The clarity you brought to a problem that would otherwise have taken weeks to untangle. The quiet work of keeping a team aligned while they're heads-down building. None of that shows up anywhere people can point to. It's infrastructure. Critical, but unseen.
In a hackathon, you're working in real time, in front of everyone. When you run a quick problem framing session to stop the team from jumping to a solution too early, people see it. When you make a prioritisation call under pressure and it turns out to be right, people feel it. When you push back on scope creep at hour six ("we said MVP, let's stay there") and the team ships something polished instead of something half-finished, that lands differently than any strategy doc ever could.
I came away from our hackathon with stronger working relationships than I'd built in months of regular work. Not because of any grand gesture, but because my colleagues finally saw, up close, what I actually do.
It's the lowest-stakes place to test your riskiest ideas
Most product work carries weight. Ideas get scrutinised, roadmaps get defended, failures get noticed. That's as it should be. But it also means genuinely bold ideas rarely make it off the whiteboard. The cost of being wrong is too visible, and the path from idea to experiment is too long.
A hackathon removes that weight entirely. You have a day or two, a small team, and very little on the line. It's the one place where "let's try the thing we've always been too nervous to try" is not just acceptable. It's the point.
Some of the sharpest product insights I've encountered came from hackathon experiments that technically failed. The idea didn't work, but the reason it didn't work taught the team something they hadn't known to ask. That's not failure. That's the kind of fast, cheap learning that product development is supposed to deliver and so rarely does.
You'll find out how good your team's communication actually is
There's a version of your team that exists under normal conditions, where there's time to clarify, realign, and course-correct before anything breaks. And then there's the version that exists under real pressure, when the clock is running and nobody has the luxury of waiting for the next planning cycle.
A hackathon shows you the second version.
You'll discover which handoffs break down. Where assumptions go unspoken. Whether your team can make a confident decision without three rounds of validation. These aren't always comfortable findings, but they're honest ones, and they're far easier to address when you've seen them play out in a contained environment rather than halfway through something that matters.
The real skill is what you do with those observations afterwards. Bringing them back into how your team works day-to-day is where the lasting value lives.
The skills you use every day feel different when the timeframe is compressed
Scoping, prioritisation, user testing: these are things you do constantly as a PM, usually with enough runway to revisit and refine. A hackathon removes that margin. You can't schedule a follow-up. You can't wait for more data. You make the call with what you have and live with it for the rest of the day.
What's surprising is how often that works out fine. Not because the call was perfect, but because the speed of it forces a clarity that slower conditions tend to dilute. You stop optimising for the decision that's hardest to criticise and start optimising for the one that moves the team forward.
That instinct, making a confident call on incomplete information and adjusting as you go, is one of the more useful things a PM can have. Most product environments don't create the conditions to develop it. A hackathon does.
If there's one coming up at your company and you're on the fence, go. You don't need to write a line of code. You don't need to have all the answers walking in. Your job is to help a team build the right thing in the time they have, and that is exactly the same job you do every other day, just with the volume turned up.
You might find that the volume is exactly what you needed.