The Clay Cup format asked for three things in 20 minutes: understand a GTM problem, build the solution in Clay, and prove it works. That is a narrower test than a real campaign, but a good one. Here is what I take from it, and how I would practise it.
I watched from Islamabad, so everything below comes from the public format and the finalists' own posts. I do not know what the winner built, and I will not pretend to. My winners post has the field: 128 competitors, 14 time zones, six knockout rounds, and a final at Sculpt on 8 October 2026 won by Ben Broadley, with Leszek Lammel and Avik Ghimire alongside him.
What does a 20-minute limit actually test?
Whether you can decide what matters before you touch a column. With no time to look things up, the first three minutes shape the other seventeen. I read it as a test of problem framing more than Clay knowledge.
Notice the third verb in the format: prove it works. A table with columns is not proof. A sample of rows showing the output you promised is.
What would I do in the first five minutes?
A fixed order. This is a method, not a record of something I won.
- Write the output in one line. "A list of N companies with a verified contact and a reason to email." If you cannot write it, you are not ready to build.
- Name the cheapest signal. The one field that separates good rows from bad. Often it is a filter, not an AI column.
- Decide what you will skip. Say what you will not build. Time-boxed work fails from adding, not from missing.
- Pick three test rows. Run every step on them before you widen.
That fourth step is the same habit that protects credits in real work, as I described in how to stop burning Clay credits.
What breaks under time pressure?
Mostly the same things that break real builds, only faster.
| Failure | Why it happens | Guard |
|---|---|---|
| Expensive step first | Building in the order you thought of it | Cheap filters before waterfalls, see waterfall enrichment explained |
| No proof | Running out of time before checking output | Reserve the last four minutes for checking rows |
| Over-building | Adding columns "just in case" | Stop when the one-line output is met |
| Unreadable table | No naming, no order | Name columns as you create them |
How do I practise this?
Run your own drills.
- Pick a real problem from your own work, with a clear output.
- Start a 20-minute timer. Stop when it ends, finished or not.
- Afterwards, write down the minute you lost time and why.
- Repeat on a different problem within the week.
Do not score yourself against the finalists. You do not have their problems or their results; compare yourself to your last drill.
Proof beats claims here, which is the argument in how to prove GTM skills without a Clay certification. A saved, dated drill with its output is a small piece of that.
Where this advice stops working
A 20-minute build cannot tell you whether emails land in inboxes, whether a data provider holds up across months, or whether replies get handled fast. Those parts of the job are where campaigns win or die, and they are why what a GTM engineer actually does is longer than a Clay table. Treat the format as a test of speed and framing, and judge the rest elsewhere.
I'm Malik, a GTM engineer in Islamabad. More about me.