Putting the PM builder to the test
What our hackathon taught us about the realities of vibe coding
It’s 3.30pm on a Thursday afternoon and the third floor of the office, occupied by around 20 product managers, is uncharacteristically quiet. That morning the space had buzzed with excitement as we kicked off the AI hackathon and teams got stuck in to building. Now, with an hour to go before we had to demo the results, an intense and nervous focus had taken over. Some aspects of building with AI had turned out to be harder than we thought.
Why we ran an AI hackathon
It only takes a quick scroll through LinkedIn or X now to see how vibe coding is changing the software world. Apps and websites abound, solving new problems and built by people with little-to-no actual experience in coding. A member of our very own product team has recently launched her own app (check out the beta version here).
As a thriving, growing product team we need to equip our people with the skills to benefit from advances in AI. We need to ensure we can realise the huge potential benefits for our clients that AI offers. And we need to be prepared for how the role of product manager is changing: what does it mean when we no longer have to rely on an engineer to code a prototype or fix a bug?
So, we organised a team hackathon to put our vibe-coding skills to the test and design tangible solutions that could solve client problems.
How we designed the hackathon
We ran the hackathon over a single day in our London office, but the preparation started a few weeks before. First, we identified problems to solve based on our real experiences working in an international consultancy for clients that vary in size and sector. We prioritised and refined the problem statements, split up into teams of three, and assigned one problem to each team.
We decided to use Claude chat, Claude Design and Claude Code as our vibe-coding tool suite because we have enterprise licences and we thought they would be interoperable (more on that later). We kept the brief pretty loose: build and deploy a product that solves your team’s problem statement, and be ready to demo it to the rest of the teams at the end of the day.
We deliberately emphasised having something tangible to demo over aiming too high or broad. The point was to practise building and launching a thin slice of a product with AI.
How it went
On the day, the room started filling at 9am and was soon buzzing with excited chatter and the sound of the coffee machine. Some of the keener teams sequestered themselves off in a corner to get ahead on a plan for the day. We congregated at 10am for a quick kick-off that set out the aims and rules of the day, then the hackathon began.
Most teams started with tasks that are the bread and butter of product managers: defining the problem, prioritising insights and ideating and scoping potential solutions. Walking round the room, you could hear “create synthetic data” here and “define the persona” there.
The problem statements teams tackled ranged from helping product managers choose the right framework to use in any client situation, to supporting people to identify the skills they needed to develop to equip themselves in a rapidly changing world.
As the day progressed, it became clear that the typical PM tasks weren’t going to be the hardest ones to complete, even under time constraints. The areas where teams started to struggle were in deploying the outputs of Claude Code, working on a shared project via Github, and setting up integrations via APIs. As the clock ticked closer to the 4.30pm cut-off, some teams gave up on deploying altogether and focused instead on demoing a prototype via Claude Design.
Regardless, each team succeeded in building a prototype or working proof-of-concept in five hours. The demos were high quality and engaging: from a tool that synthesised Team channel messages and transcripts to identify potential project blockers, to a ‘project brain’ that centralised all information about a project and helped team members get up-to-speed much quicker than usual.
What we learnt
The area that teams struggled with the most was making their code available on Github so they could collaborate on it as a team. We also found that without API credentials, it was hard to prove out product integrations or feed our tools with real data. We’re now planning to run follow-up sessions to build our Github and API skills.
We also learnt that the tools we use for vibe-coding are still young and lacking maturity in places. While they’re all part of Claude, it wasn’t very easy to integrate what you’d created on Claude Design with Claude Code. Projects that existed in Claude chat couldn’t be referenced in Code and Design. The interoperability we thought would exist wasn’t quite there, and this added challenges to collaborating within our teams.
Side note: it’s likely that by the time this write-up is a month old, Anthropic will have solved the interoperability issue; they’re moving that fast.
The key takeaway
Our hackathon was so much fun. It was great to get together as a team, think outside the day job and do some hands-on learning. And we came up with some tools that will be genuinely useful to our clients and our organisation.
If you’re thinking of running something similar, make sure to build a solid grounding in the technical concepts and tools that you need to use alongside your vibe-coding suite. But most importantly, just give it a go! You won’t regret it.
 | A guest post by
|