Context
At Perforce, I am the product design lead for two products in the ecosystem: P4 DAM, an asset management platform, and P4 Plan, which is a bit like Jira but built for Perforce products.
P4 itself is a version control system, much like GitHub. Game studios typically use Perforce because it handles huge, enterprise-scale projects, then layer on tools like DAM and Plan. That is the world this work sits in.
Like a lot of companies in this new AI world, we had internal redundancies. Front-end capacity on my product dropped from six developers to two. That is a 66.67% cut. You would expect product delivery to fall by about the same. Instead, we ended up releasing 25% more features per quarter, at the same quality as before.
Figma handoffs were simply taking too long to implement with the team we had left. I knew we needed to change how we worked. At the time we had been granted a generous Claude Code allowance, and I decided we really needed to lean into it.
The strategy
I installed P4 DAM locally and worked like a real developer on real product code. Pushing code to branches, getting code reviewed and working in the same ways and standards as our senior developers.
We still needed the same quality of handover we used to get from Figma. So I generated spec files, handover documents, and other outputs through skills and agents I built. Developers reviewed code that worked in some areas and did not work fully in others. I do not think anyone has fully cracked designing working code yet. Even so, clarification questions dropped by an estimated 50% to 60% per feature.
Despite working in code, I took full responsibility for the front-end features I owned. Developers reviewed the final output rather than reconstructing it from Figma. The process was faster, produced more features, and needed less rework than the workflow we had six months earlier.
Proof point 1: Product execution
One of the features we released was realistic lighting in P4 DAM. We replaced the flat grey background in the asset viewer, the one that made 3D models look dull, with switchable image-based environments, so users and reviewers could judge shape, materials, and quality in realistic lighting.
This was not a basic coding task. I prototyped it in the live product, handed it over as working code rather than static screens, and shipped it with minimal developer feedback. It was a concrete example of code-level handoff protecting delivery when front-end capacity was thin.
Proof point 2: Process innovation
Shipping features myself was only half the job. If the workflow stayed with me, the wider design organisation would not benefit. I did not want to gatekeep it. I wanted to share it across the company so others could move faster too.
So I turned the approach into reusable Claude skills. One of them, built to help me ship features quickly and efficiently, won Best Designed at the company’s annual AI hackathon in 2026. Other teams across the business now use it.
The outcome
In the end, access to Claude Code became a functional delivery system. When the team shrank, output stayed high and went beyond what seemed possible: more features with less capacity, without compromising quality.
