Skip to main content
Every product team has a backlog of “what if we tried this?” ideas that never make it onto the roadmap. Not because they’re bad - because there’s no space to explore them. Hack days create that space 🛠️ A hack day (or hackathon, depending on scale) is dedicated time - usually one to three days - where teams step away from the sprint and build, explore, or experiment with anything they find interesting. No deadlines, no stakeholders, no backlog grooming.

​
Why they work

The roadmap is a filter for certainty. It contains things you’re confident enough about to commit resources to. Hack days are for everything that doesn’t clear that bar yet - the speculative, the risky, the “I’ve been thinking about this for months but never had time.” Some of the best product ideas come from this space. Gmail started as a hack. So did the Facebook Like button. Not because hackathons reliably produce hits, but because they create conditions where unexpected ideas can surface without the usual friction of justification and planning. There’s also a team culture angle. Hack days signal that exploration is valued, not just execution. That matters for retention, motivation, and the kind of creative thinking that makes products better over time.

​
What makes a good hack day

Clear constraints, not clear outputs - The best hack days have a loose theme or problem space (“improve onboarding”, “reduce support tickets”, “make the product more delightful”) rather than prescribed outputs. Constraints focus energy without killing creativity. Whole team, not just engineering - PMs, designers, engineers, CS, data - the best hacks happen at the intersection of disciplines. An engineer and a CS rep building something together often produces ideas neither would have had alone. Real demos, honest outcomes - End with a show-and-tell, not a polished presentation. The point is to share what was learned, not to impress. The hack that failed fast and learned something is as valuable as the one that produced a prototype. A path for good ideas - The biggest waste in hack days is a great idea with nowhere to go. Have a lightweight process for surfacing hack outputs into the discovery process - not a promise to build everything, but a genuine way for promising ideas to get evaluated.

​
The trap to avoid

Hack days that turn into internal marketing exercises 😅 When the implicit goal is “impress leadership” rather than “explore and learn”, teams optimise for demos that look impressive rather than experiments that test real assumptions. The ideas get polished, the learning gets lost. Lesson learned: the hack days I remember most weren’t the ones with the flashiest demos. They were the ones where someone built something in a day that made the whole team go “wait, why don’t we have this already?” 👀