I held a "Design Marathon" with my team to push our technical abilities, enhance collaboration, and utilize AI in ways we weren't used to, and I think your team should do the same (or similar).
My Team
My name Jose (but I usually go by "King"), and I am a founding member of team Haraya, the first global team of Data Hub. We have members in Japan as well as in Cebu, Philippines. Naturally, this presents some challenges in communication due to differences in culture as well as nuances in communication.
In July 2025, our Japan side members had the chance to visit Cebu for the first time, and this presented us with the opportunity to hold an event to help us improve as a team. We initially wanted to hold a hackathon, but we figured that’d be too time-consuming. However, shortening a hackathon didn’t make much sense for us, so we went for a “Design Marathon” instead.
What's a "Design Marathon"?
(In hindsight, this name is not the best for what this activity really is, but we just kind of ran with it.)
The "Design Marathon" is essentially a hackathon but for systems design. Rather than trying to create a functional application in 24 hours, we would have 1 hour to create a system design based on some product requirements (which I'll talk about in more detail later).
This solved the main issue of a hackathon: Time. One hour was more manageable for us due to upcoming project deadlines. And compared to a Hackathon, our design marathon had more of a high level focus.
Group Compositions
As a team we *could’ve* collectively contributed to the same design together; however, there's an issue when working in larger groups in that communication becomes *slow*, and that's just not ideal for an activity that's meant to be fast-paced. Because of this, I decided that our team should be split into three groups of two. Working in pairs allows for much faster-paced communication, maximizing collaboration between the two members!
When we held this activity, our team consisted of three members in Japan and four members in Cebu (including myself). Since I was facilitating, I couldn't participate directly, which created an equal 3:3 split between Japan and Cebu participants. Because our Japan-Cebu communication had been exclusively remote, I paired each Japan member with a Cebu member at random. This gave everyone the opportunity to collaborate face-to-face with colleagues they normally only interacted with online.
Event Mechanics and How AI Fits In
The main goal of each group was to create a systems design document (in Notion) based on the product requirements. There was no specific format that they had to follow, so it was completely up to them as to how they structure the document, as well as decide how detailed or concise the document is. This was later exported as a PDF file and judged by an AI, which I’ll go over in detail later.
As far as tools and AI usage goes, anything goes! Well, except for one caveat: an AI should not DO the entire design for the group. The point of this is to allow the engineers to express and push their technical skills while giving room to enhance them with AI. This approach allowed for a healthy balance between human creativity and AI assistance, encouraging engineers to think critically while leveraging AI for efficiency. It also helped team members develop their judgment about when and how to appropriately integrate AI tools into their workflow.
AI Entrepreneur and Its Product
For the product requirements, I could have simply provided a document with specifications. Instead, I saw an opportunity to add an interesting twist: having an AI act as an entrepreneur/product manager to deliver requirements through conversation. This approach mirrors real-world software development, where engineers must communicate with various stakeholders to gather requirements. In practice, requirement gathering is rarely straightforward—so why should our design marathon be any different?
Enter "Rowan Calder," a custom GPT I created to serve as an entrepreneur who interacts with our engineers about their desired product. This added layer of communication challenged our engineers to think carefully about how they extract accurate and comprehensive product requirements through conversation—a skill that mirrors real-world interactions.
Rowan's product concept was a real-time messaging app that translates tone, mood, and environment into messages, adding emotional depth to conventional text communication. This presented a significant design challenge, especially when considering the need to scale to millions of concurrent users—all within our one-hour timeframe.
To keep things consistent, I provided a detailed product spec to the GPT about the product they wanted to build. That way each team had their own conversation with the AI but worked toward building the same product. I also gave it a persona just to give things a bit of "flair."
Design Marathon
The team was split into the following groups:
- Dan (JP) and Grace (Cebu) as Group A
- Max (JP) and Silver (Cebu) as Group B
- Masa (JP) and AL (Cebu) as Group C
As the marathon began, I arranged for each group to sit together to facilitate easier collaboration, as shown in the picture above (with Dan being the only one standing). I initially thought this seating arrangement would suffice, but soon all three groups requested access to the whiteboard at the back of the room.
Although all groups worked with the same product concept (via the GPT Rowan), each team developed different interpretations based on their conversations with the AI. Group A took a direct approach by focusing solely on addressing the core solution. Group B expanded on the original requirements by adding their own set of features. Most surprisingly, Group C went beyond technical design to create a complete business plan!
This demonstrates how team members, even when working closely together, can develop remarkably different approaches and interpretations of the same product requirements.
When the marathon concluded, we moved to the judging phase. Since an AI handled the product requirements, I thought it fitting to have another AI evaluate the results. Meet "Lena Corell":
After exporting each group's Notion design document to PDF, we had Lena evaluate them based on four key metrics in system design: simplicity, scalability, elasticity, and availability. This evaluation process gave each team valuable insights into how their designs would perform under various scenarios and provided learning opportunities they could apply to future work.
While I won't share the complete judging results, here are some highlights from each group's feedback:
- Group A: "Group A's use of Cassandra and S3 reflects good judgment for write-heavy ingestion and long-term, cost-effective storage respectively, but lacks explicit strategies for scale under peak loads."
- Group B: "Group B's design for the Emotional Lens Filter shows thoughtful feature mapping and user experience considerations. However, the system architecture could use some adjustments to meet the demands posed by SubText's scale, latency, and durability requirements."
- Group C: "Group C presents a well-reasoned and technically sound architecture for SubText. It shows good understanding of the scale and emotional complexity of the product. However, to elevate the design further, introducing failover strategies and ensuring all services meet the ultra-low latency requirements would be beneficial."
Conclusion and Takeaways
This activity yielded several valuable insights that can benefit our team and similar initiatives in the future.
- There are low-cost and low-risk activities that can elevate your team's skills and collaboration.
- Although we all work in the same environment, our interpretations and approaches to matters can vary widely, so improving our means of communication can help us be more effective.
- With AI, we can simulate real-world scenarios that would be difficult to perform in a controlled environment.
- With AI, we can introduce a feedback system to help us improve that would otherwise be very time-consuming or costly.
In conclusion, I hope this blog has given you valuable insights into how brief, focused activities can significantly benefit your team. Whether or not you implement a similar design marathon with your own colleagues, I hope you've gained useful takeaways from our experience that you can apply to your own teamwork approaches. And, as our team likes to say after every meeting: "Change lives!"
