When I joined Twiggle as VP of Product, the company had an incredible piece of technology. They had built an early version of what we now call an LLM, designed specifically for e-commerce search. But back then, no one was using that term, and the technology was far ahead of the market.

The team had developed an amazing demo and was showing it to potential customers. Those customers were generally excited and wanted to move forward, which typically meant running a POC to see it in real life. But the company wasn’t ready for that step. It wasn’t that the technology didn’t work. It was that there wasn’t yet a product. The team hadn’t defined what they actually wanted customers to do with this technology, at least not with the level of clarity and detail needed to start using it in a real-world scenario.

That was my first task: figure out what product to build. The challenge wasn’t a lack of ideas, quite the opposite. The technology was powerful enough to enable several valuable directions. But without a decision and focus, we couldn’t move forward.

That’s when I decided to run a hackathon. Not a generic “let’s innovate” event, but a focused two-day hackathon designed to generate real product directions that we could later consider and choose from. I knew it had to be structured right if we wanted to get meaningful outcomes.

This article takes you through the principles that made that hackathon such a success – and how you can apply them when you run one of your own.

Innovation Needs Context

Hackathons often carry the promise of breakthrough thinking, but without the right framing, they rarely lead anywhere useful. Innovation for its own sake is exciting. It creates energy. It brings people together. But it doesn’t always create value. And when you’re leading a product team with real goals, limited time, and tough decisions ahead, excitement without direction can quickly become a distraction.

I’ve seen this firsthand when I was Head of Product at eBay. The company used to hold a massive hackathon every year. It was a big event: a full week, company-wide, well-produced, and full of creative energy. But I rarely joined. Not because I didn’t value innovation, but because it didn’t feel relevant to the real work we needed to do. The projects were often playful and clever, but rarely grounded in the company’s actual strategic challenges. The result was a lot of fun ideas and very little impact.

That’s the trap of contextless innovation: it creates output, but not outcomes. People get excited. Teams bond. You might even get a few great demos. But the value ends there, because the effort isn’t tied to what really matters for the business.

True innovation isn’t just about generating ideas. It’s about solving problems – the right ones. When you focus people’s creativity on a real, well-defined challenge, you don’t just get novelty. You get progress. And when you’re sitting on a powerful piece of technology and trying to figure out what to do with it, that’s the kind of innovation you need.

That’s why, when I decided to run a hackathon at Twiggle, I didn’t start by asking for ideas. I started by defining what kind of ideas we needed.

Know What You’re Going to Hack

Eventually, eBay realized that contextless innovation wasn’t enough. They started shaping each hackathon around one or more themes – a specific area the company wanted to explore. It was a step in the right direction, but it wasn’t enough. The problem was that it was still too broad and people company-wide who didn’t have daily interactions with the relevant topics had only a vague idea about what it meant. Not only were there too many interpretations, but most teams didn’t know how to think about these interpretations and use them in the best possible way.

To help teams understand better what they want to hack, I often use my product circuit model. It breaks down product thinking into three distinct layers: the problem, the solution, and the product. Each layer requires a different kind of exploration.

A problem hack is about uncovering or reframing real customer needs. A solution hack is about thinking through how you might solve a known need in a new way, and sometimes checking whether it’s even feasible from a technical perspective. A product hack is about bringing it all together into something customers can use and buy.

If you’re not clear which layer you’re aiming to explore, your hackathon won’t generate anything truly useful. At best, you’ll get interesting noise.

Define the Playground Together

At Twiggle, the goal of the hackathon was clear: we needed to explore the problem space. The technology was impressive, and the general problem was well known. E-commerce search was broken, and we believed we could help fix it. But that insight alone wasn’t enough to build a product. Even after pivoting from B2C to B2B, the company’s understanding of the problem was still too broad to act on.

So I started the hackathon with a detailed talk to frame the challenge. I shared what we knew so far from conversations with e-commerce companies, what problems they described, and what outcomes they cared about. Then I shifted the focus to the team: what could we do, with our technology, that would truly help these people?

I made it clear that we weren’t aiming for polished solutions. At this stage, we were going for volume. I asked everyone to write down as many ideas as they could, as quickly as they could. Quantity first. I knew that within a big pool of ideas, stronger patterns would emerge.

Once we had a full board of raw ideas, we grouped them by theme. Then we ran a fast voting round to identify the ones worth exploring further. These weren’t the final answers. They were starting points. But they gave us enough shape to split into teams and start building out more complete concepts.

This part requires management and consideration. You can’t just run a casual brainstorming. You must create a structured discussion focused on getting somewhere useful.

Innovate on Paper First

After we narrowed down the ideas through voting and discussion, I assigned teams to each of the shortlisted ideas. The goal at this stage wasn’t to build anything. It was to define the idea: to treat it like a product concept, not just a creative spark.

Each team got a clear task: write a detailed product brief. Not a spec, but a deep exploration of what the idea was and who it was for. I gave them a list of guiding questions to answer. Who is the idea meant for? What specific problem are they facing? What have they already tried that didn’t work? What would they need from a new solution?

While they were working on it, I walked around the office and helped the teams sharpen their answers. Once the previous questions had clear answers, we moved on to defining the actual product – what it does, what it looks like, and how it behaves.

This extended thinking was critical. It turned raw ideas into clearer, more grounded concepts. Teams had to confront the realities of their ideas: the customer context, the underlying assumptions, and the practical implications. In some cases, it made the idea stronger. In others, it revealed that the concept didn’t hold up under scrutiny.

That was a good outcome, too. Not every idea that made it to paper made it to code, and that was by design. By slowing down and forcing clarity early, we avoided spending time on ideas that sounded good but didn’t make real sense once you looked closer.

The building phase came next, testing the feasibility and bringing the concept to life. Since it followed in-depth product work, the coding part was relatively easy, and today it would be even easier with the various AI tools. Hackathons aren’t about coding. They are about finding answers and solving problems. To make the most out of them, make sure you know what you are looking for and guide everyone accordingly.