Earlier this week, I had the opportunity to lead a focused B2B hackathon with a small cross-functional team. The goal was simple, but ambitious: take a real business pain point, move quickly through ideation and execution, and leave the day with something working enough to demo, evaluate, and potentially pilot within 30 days.
The final output mattered, but the real value came from the process: how we framed the problem, how the team aligned, how quickly we made decisions, and how we turned a broad idea into a usable workflow.
The Problem We Set Out to Solve
The challenge we focused on was one many product, design, marketing, and engineering teams know well: it takes too long to move from a business idea to something realistic enough to test.
Business users often have strong ideas for landing pages, funnel changes, messaging tests, or experiment variations. But turning those ideas into branded prototypes usually requires multiple handoffs across product, design, engineering, and quality assurance (QA). Each handoff creates translation overhead. The idea gets interpreted, reinterpreted, scoped, designed, ticketed, built, reviewed, revised, and eventually tested.
That process is necessary for production-quality work, but it is often too slow for early experimentation.
So our hackathon question became:
How can we help business users turn product and marketing ideas into realistic, brand-aware prototypes that engineering can act on faster?
We were not trying to fully automate production deployment. That would have been too much for a one-day sprint and the wrong place to start. Instead, we focused on improving the front end of the process: moving from idea to prototype to implementation-ready handoff.
The Core Idea
The team centered on a rapid landing page and funnel prototyping workflow for A/B testing.
The concept was to let a business user start with a simple prompt, answer a guided set of questions, generate experiment variations using Claude Design, and produce a branded prototype based on an existing design system. From there, the workflow could support a clearer handoff into Jira, including a preview link, downloadable assets, and enough context for engineering to understand the intended experiment.
For the hackathon, we used a real Clover example and focused on proving that a non-engineer could get materially further than they can today.
That became one of the most important filters for the day. We were not asking, “Can artificial intelligence (AI) replace designers or engineers?” We were asking, “Can AI help business, product, design, and engineering teams collaborate earlier, faster, and with less ambiguity?”
That framing kept the team focused.
Why the Process Mattered More Than the Product
One thing I appreciated about the day was how quickly the team moved from abstract discussion to practical execution.
We started by defining the expected flow end to end. Before building anything, we aligned on the target user, the pain point, the minimum viable product (MVP), the definition of done, and the major technical risks. We also made explicit decisions about what we were not going to do.
That last part was critical.
For a one-day hackathon, scope control is everything. It is very easy to turn a good idea into a sprawling platform concept. We could have expanded into Figma automation, staging deployment, pull request creation, traffic throttling, quality assurance, analytics, and production rollout. All of those are valuable. None of them needed to be fully solved in one day.
Instead, we focused on a credible workflow:
A business user provides an experiment idea.
Claude Design uses a branded template and design system.
The user answers guided questions.
The tool generates a prototype variation.
The output can be packaged into a Jira ticket or engineering handoff.
That gave us a clear demo path and a practical way to evaluate value.
Teamwork Was the Real Accelerator
The strongest part of the hackathon was the cross-functional collaboration.
We had people thinking about the business workflow, the user experience, the design system, the front-end implementation path, the ticketing process, and the final demo package. Everyone had a lane, but the team stayed connected around the shared outcome.
That balance is hard to get right. Hackathons can easily become either too chaotic or too rigid. In this case, the structure helped. We had kickoff alignment, build blocks, midpoint check-ins, a scope freeze, final polish, and a recorded demo plan.
The midpoint check-ins were especially useful. Each workstream had to answer three practical questions:
What is working?
What is blocked?
What should be cut if the scope is too large?
Those questions forced clarity. They also helped the team avoid wasting energy on lower-priority polish before the core path was working.
By the end of the day, the team had produced not only a prototype, but also a recap, a demo video, getting-started instructions, and a list of next steps. That made the work shareable, not just demoable.
What We Built
The final product was a working prototype workflow that helps a business user move from idea to branded prototype more quickly.
Using Claude Design and a Clover-specific template, the workflow guides the user through a structured set of questions:
What page are you working on?
What is the goal of the experiment?
What content should be included?
Are there examples, references, or design styles to consider?
Which section should be edited?
Once the user answers those questions, the system summarizes the intent and generates a first version of the design variation. The user can then review, refine, and select a version for handoff.
The next step in the workflow supports creating a Jira ticket with context such as the variant, project key, assignee, experiment purpose, domain, board type, channel, and prototype preview link.
That may sound simple, but it addresses a very real bottleneck: getting from business intent to a concrete, visual, implementation-ready artifact.
What Worked
The biggest win was demonstrating that a non-engineer could get much further into the prototyping process than they can today.
The prototype improved three things at once:
Speed: It shortened the path from concept to prototype.
Alignment: It gave product, design, business, and engineering a more concrete artifact to react to.
Handoff quality: It created a more structured bridge between ideation and implementation.
The workflow also showed the value of brand-aware AI tooling. Generic AI-generated pages are interesting, but usually not useful enough for real business teams. The power comes when the tool understands the brand, the design system, the page context, and the experiment goal.
That is where this started to feel less like a toy and more like an operational workflow.
What Is Still Manual
This is not a full production automation system yet.
Quality assurance, deployment, pull request creation, staging, production release, and traffic throttling are still manual. That is appropriate at this stage. In fact, keeping those steps manual was part of the discipline of the hackathon.
The goal was not to bypass engineering or governance. The goal was to improve the quality of what gets handed to those teams.
A good next version could connect more deeply into Figma, Jira, GitHub, staging environments, and analytics. But even without those integrations, the current workflow is useful as a faster way to create and evaluate experiment concepts.
The Outcome
By the end of the day, we had a working prototype, a clear pain point, a defined target user, a measurable short-term signal, and a set of recommended next steps.
The most immediate next step is to socialize the workflow and begin using it for Clover. From there, the team can refine the template, add additional brands, track improvements in Claude Design, explore pull request or staging integration, and evaluate how design systems can be expanded for other brands such as Global Payments.
The team also identified a broader set of future ideas, including AI-guided lead funnels, AI-driven survey and testing engines, and automated legal copy updates across landing pages.
Those ideas are exciting, but the biggest takeaway is more fundamental: once teams see that they can move faster from idea to testable artifact, the way they think about experimentation starts to change.
My Main Takeaway
The hackathon reinforced something I believe strongly: AI is most valuable when it is applied to a real workflow, not when it is explored in isolation.
The best use cases are not abstract. They live inside the messy handoffs between teams. They reduce friction. They help people communicate more clearly. They make work visible earlier. They give teams something concrete to evaluate.
In our case, the final product was a rapid prototyping workflow. But the more important outcome was proving that a cross-functional team could take a real operational bottleneck, apply AI thoughtfully, and produce something practical in a single day.
That is the kind of experimentation I want to keep pushing: fast, grounded, collaborative, and connected to measurable business value.
Huge thanks to the team for bringing the energy, focus, and creativity needed to make the day successful. This was a strong first step, and I am excited to see where the pilot goes next.
