By the end of a six-month, fixed-price project for a national public service broadcaster, we achieved three times the output usually expected within that period. Our small team of five made that possible: we were experienced, AI mature, T-shaped, and empowered to apply an AI-driven approach that pushed our delivery speed as far as it would go.

We were experienced in cutting-edge AI ways of working, and understood how to share context effectively to leverage those methods at scale. We saw this project as an opportunity to validate that approach within a specific team structure, shifting from a traditional, siloed agile model to a lean, tightly knit, high-speed unit where our roles and methodology evolved alongside our output.

How AI reshaped our team, not just our output

The design and research loop remains, but the effort ratio flips: We followed the same user-centred design (UCD) loop we always have: understand, prototype, test, iterate, validate. AI tools accelerated execution, and that flipped our effort split. We spent 70% of our time on learning and synthesis, and 10% on the build.

Evolving team structures: AI acted as a force multiplier, allowing a T-shaped team of multi-skilled consultants to tackle the work statements, calling on specialists where it mattered most.

Faster delivery raised the value of communication: AI compressed how fast we could produce work, and that shifted the emphasis for us as consultants to stakeholder engagement, communication and influence skills.

Building a single source of truth

The foundation of our approach was building our project brain as our single source of truth. Every piece of user research, client feedback, design iteration and technical documentation lived there, written in a format that AI agents could efficiently read. Feeding that context to AI agents turned them into synthesis engines: we could generate prototypes, dashboards, accurate playbacks and client-ready presentations in minutes rather than hours, flipping our traditional ‘time-spent’ ratio. We kept requirements in that same project brain rather than in Jira, written in plain language before anyone touched a prompt, so intent stayed next to the code instead of scattered across separate tools.

None of this works without discipline in the code itself: files small, names clear, duplication kept out, because sloppy code compounds faster with AI in the loop than without it. AI wrote the code; we reviewed it, corrected it, and set the architecture before a single prompt went in, then used that same discipline to accelerate the build itself, turning concepts into fully clickable web apps hosted live rather than mocked up as static designs. Stakeholders could click through a working prototype instead of looking at pictures of software.

A new loop: faster, broader concept generation

During exploration, we moved away from wireframes and traditional design tools and adopted a new loop: ideate, define, prompt, review & shortlist, test, synthesise, iterate.

We generated thirty working prototypes in the first week alone, each one live and clickable but we didn’t put all thirty in front of users. Instead, we used a funnel approach: generate, review, shortlist, test. By applying human insight to evaluate these prototypes against clear criteria, we could cull weak concepts early and focus our testing efforts on the most promising candidates. This volume mattered because it allowed patterns to emerge across a wide set of options faster than we could have reasoned out manually, and the shortlist that survived to research was stronger for having competed against so many alternatives.

Flipping the build-measure-learn ratio

We quickly discovered that our ways of working didn’t just speed up delivery, it fundamentally changed our ‘time spent’ ratio. With execution taking a fraction of the time it used to, we ran more cycles: more concepts explored, more prototypes tested, more rounds of feedback in the same window. The R&D process itself didn’t change. The volume we could put through it did, whilst giving us the space to learn, iterate and collaborate.

As a small team, we started absorbing work that would normally sit with other profession roles, running execution ourselves and calling in subject matter experts only at the checkpoints where their judgement mattered most. That had a knock-on effect on how we structured the team itself.

The rising value of communication, influence and trust

With less time spent building, our focus shifted toward the core of the client relationship: discovering the true value we were trying to unlock. The increased volume of design output wasn’t just about velocity; it created regular, meaningful engagement with stakeholders that helped us pressure-test our assumptions. This constant loop of validation allowed us to pivot toward the right outcomes, ensuring our direction was always aligned with what we were truly trying to achieve. Being able to communicate effectively, influence stakeholders, and bring them on that journey of discovery became our most valuable human skillsets.

An evolving agile team

The shift in workload and responsibilities is the part of this project I keep coming back to. In traditional models, disciplines can sometimes become siloed. AI didn’t replace those specialist roles; instead, it blurred the lines between our disciplines, allowing our core team to work fluidly across boundaries. By integrating that specialist input at key moments, we gained the heuristic knowledge needed to effectively guide and challenge the AI’s output, ensuring that high-level expertise was still driving the work even as our velocity increased.

It’s important to say that we didn’t cut those disciplines out, we just resourced their time differently. For research, a specialist spent a day or two creating the conversation guides and briefing us, then turned their attention to another project while we ran the interviews ourselves and let AI handle the bulk of the synthesis. We then had a follow up session with the UR to review and validate our insights and outputs. That pattern repeated across the disciplines we used to run full-time: less of their calendar, concentrated at the moments where their judgement could not be replaced by an agent.

Is this going to be the future for how we structure our agile teams? If a core team of four or five can absorb the day-to-day work of eight or ten, the value of T-shaped consultants may be on the rise. It also doesn’t mean there’s no room for narrow specialists, quite the opposite, they are likely to be needed across more projects at once.

The limits of fast delivery

One thing to bear in mind is although these new AI driven ways of working can move you through the design process fast and build fast, it doesn’t necessarily mean we can deliver at the same pace. Every large organisation will have its own checks and balances, often reliant on the schedules of other teams or by decision makers outside our control.

For us that gap between ready and live wasn’t dead time. We used it to keep producing, taking on more scope and more ideas while our first statement of work worked its way through those checks. In that same six-month window, the accelerated velocity allowed us to deliver three separate statements of work for the price of one.