Forward-deployed in practice
Most large organisations we talk to aren’t short of ideas. They know where the emerging value might be and the wider shifts that might call for new propositions, they just don't have a fast way to find out whether their bets would pay off, or a team to dedicate to finding out.
Instead, an idea is pitched, usually through a long and convoluted deck, the strategy is discussed in detail, the hypothetical research that would need to take place outlined, senior stakeholders buy-in patiently awaited for, and budget released even later on. Six months later there's something to look at, by which point the thing it was answering to has usually moved on or the initial idea in need of revision. It’s expensive and slow relative to how quickly the questions now change.
For the last stretch we've been running a different model with one client, almost by chance but true to our nature of working. It's worth describing, because it's the clearest picture we have of what a ‘forward-deployed’ team actually does. Our founder spoke about forward-deployment in more depth here, but it’s worth us actually illustrating what that looks like for our clients: a dedicated senior team, proximal to the business’ problems and working closely with the C-suite.
Proximity does the work a brief can't
The client is a global institution whose product is a number of things: research, events, intelligence. Our engagement there is rolling, and as part of our 16-person strong team who have been engaged in this work for almost 10 years, is a senior design-engineer embedded in their business who reports directly to select senior stakeholders. To put that into context, that means one person covering strategy, experience design and front-end build, with product management absorbed into the middle of it rather than sitting alongside as a separate role. Client-side, there are two or three people close to the work, not a board that takes several weeks to book a call in with.
Crucially, the most recent project described here didn’t start from a brief. It started from the conversations had between stakeholders who know the business best and from picking up half-formed ideas as they surface in the day-to-day life of the organisation, and turning them into something visible before anyone has written a business case for it. Some of those ideas go nowhere and some get combined with something else entirely. The point isn't a pipeline of approved work. It's presence, aka being close enough to the organisation's actual thinking and actual problems that a potential solution or idea that’s been discussed can be brought to life to be picked apart, rather than discussed in hypotheticals no one can agree on. Forward-deployed lets the work move at the speed of the conversation rather than the speed of the plan.
Close to senior stakeholders
Naturally, proximity to the problem only pays off if it's matched by proximity to whoever can actually say yes to testing a solution. The senior sponsor on this account is described as "normally peripheral" to the daily churn of ideas. They aren’t in stand-ups, but can look at the current finished ‘thing’ and say yes or no. In essence, they get to be uninvolved in most of what gets tried and discarded–because thanks to AI it doesn’t require the investment sign-off it once did–but decisive at the one moment that counts: reviewing something built and deciding whether it goes further.
Because the loop between their reaction and the next version is measured in days, their judgement is actually usable as a steering mechanism–which is not true when the loop is a quarter long. This is also where the trust comes from. Their annual review of the engagement amounts to "carry on”–not because nobody is counting, but because there is a visible stream of things that exist and work.
That's a deliberate structure. It keeps the loop fast, and it keeps the decision with someone who has both the authority to greenlight the next step and the standing to defend the spend if anyone asks why. It also changes what "buy-in" means. Buy-in here isn't a sign-off on a plan. It's a senior person seeing a working version of an idea and deciding, on the spot, that they want it. Once that happens, the rest of the organisation tends to follow the decision rather than relitigate it.
Functioning things, not decks or prototypes
One idea started as a question: they hadn’t gone live with anything that harnessed generative AI, so what could that look like? It began in Figma. Concepts, propositions, the usual. Then it stopped being Figma, and started being “let’s just make this real now”. The team took the institution's unstructured material: reports, documentation, transcripts from their flagship annual sessions, put it behind an interface, wired in a Claude API key, and wrote prompts that pulled structure out of it and into a database. Not a prototype of a product, but a rough working version of one, running on the client's own content.
This is the part that changed everything, and it's recent. Being able to walk into a room with a working app populated with real organisational data, rather than a clickable prototype, changes the nature of the conversation. Nobody has to imagine how it would “actually” look. The response isn't "interesting, what would it take to build?", it's "how do we roll it out?"
When the client's own product team saw it demonstrated internally, the reaction, was "holy shit, this is amazing, let's use this for the live blog." The conversation didn't linger on whether the idea was good–they could see it was rather than debating an idea that was hard to imagine. That's the shift this way of working is built to produce: from a document that describes a possibility to an object someone can open and use, at which point the only remaining question is logistics. Essentially, the project went from ‘might happen’ to ‘is happening’ in an afternoon.
Avoiding the gravity well
The next call was about how to get it made, and it was full of the questions you'd expect: documentation, process, architecture sign-off, the machinery that exists for good reasons and slows everything to a crawl regardless. A technology function is a gravity well. Essentially, anything that drifts too close gets pulled in, and design-led work in particular tends to get crushed at the bottom of it—or quietly cancelled by a tech team with different priorities. Unless someone senior pulls you back out, that's the usual outcome.
This is not to say we’re anti-engineering. It's more about sequencing. It means the conversation with the technology function starts from a working artefact with executive backing, instead of a request for permission to explore. And it means the route in commercially is through strategy or the business, not through tech procurement.
What AI actually changed
The honest answer is: the range of one person. What that practitioner does today is radically different from what they were doing six months ago, and the difference is that the distance between "I can specify this" and "this exists" has mostly collapsed. If you understand how something should be architected, you can get a long way into building it yourself.
There's a version of this that's over-claimed, and we should be careful. Anyone can vibe code something now–and it looks vibe coded. The polish isn't there, the experience isn't there, and a board member can tell within about four seconds. On the contrary, senior design-engineers, necessarily cross-disciplinary, experienced, and discerning possess the judgement plus the ability to build and build well. Separately, both are commodities. Together, in one or two people who are close to the business problem, trusted, and in ongoing dialogue with senior stakeholders, they're rare and they're worth a lot. That's the thing the client keeps telling us they're buying.
The budget doesn't disappear, it moves
There's a fear in all of this that AI eats the work. What we've seen is that it moves it. The same technology built for the strategic product is now being reused elsewhere in their organisation–a colleague saw it and immediately wanted it for something entirely different to create another value stream. Meanwhile, the rudimentary production work, another page on the public site, another cosmetic redesign, is exactly the work that should be automated. That used to be bread-and-butter revenue. Losing it is fine, because it frees budget and attention for the transformation work that neither side had time for before.
The direction of travel is upstream. Away from producing artefacts, towards deciding what trialling and testing what should exist based on the ever-changing future we’re walking into.
Final thoughts
The shape of the model this engagement has proven out over ten years: a small, senior, cross-disciplinary team, embedded close enough to the business to catch ideas before they're written down, close enough to the people who can say yes to move fast once they do, building the real thing rather than a description of it, and using AI to do in days what used to take months. None of that is a new philosophy for us–it's an old one, running faster than it used to.
