Forward deployed designer
Issue 288: Go to the problem
In the early 2010s, Palantir coined a role that didn’t exist before: the Forward Deployed Software Engineer. These weren’t engineers building features on a roadmap. They were engineers embedded directly at client companies — sitting with analysts, operators, and decision-makers — to discover the problem and build the solution in the same motion. The role spread. Databricks, Scale AI, and OpenAI adopted variations.
The reason is simple: when you collapse the distance between the person who understands the problem and the person who can build the solution, everything moves faster. The feedback loop tightens. The game of telephone between sales, product, and engineering disappears. You stop building to spec and start building to learn.
So here’s the question I keep returning to: why hasn’t design had its version of this?
The missing leverage
For most of design’s history, the answer was practical. You could embed a designer at a customer site, but they’d still need an engineer to build anything. A designer could observe workflows, sketch solutions, and present recommendations — but the output was a deck, not working software. That’s useful, but it’s not the same as what a forward deployed engineer delivers.
Consulting and agency models tried to bridge this gap. Design sprints became the popular format: a week-long workshop with a rigid agenda — map on Monday, sketch on Tuesday, decide on Wednesday, prototype on Thursday, test on Friday. The intent was right. Compress the cycle. Get to a testable idea fast. But the format is still a workshop. It’s bounded, facilitated, and disconnected from real implementation. The prototype you build on Thursday is a clickable mockup, not software.
The forward deployed model is different. It optimizes for outcomes, not deliverables. The structure is the team, not the ceremony.
AI changes the equation
What’s shifted is that designers now have technical leverage they never had before. With tools like Claude, Cursor, Replit, and v0, a designer can go from observing a workflow to building a functional prototype in the same day.
This isn’t about designers replacing engineers. It’s about designers being able to do the first 80% of a solution independently: research the problem, design the approach, build a functional prototype, and validate it with real users. The last 20% — production hardening, systems integration, scale — still needs engineering. But by the time engineers engage, the problem is well-defined and de-risked. That’s enormously valuable.
The Forward Deployed Designer is someone who embeds with a team facing an ambiguous problem, spends time in the field observing real workflows, and rapidly prototypes solutions using AI-assisted development. They leave behind not just a solution, but clarity: a well-articulated problem, a tested approach, and artifacts the team can build on. They compress the discover-design-validate loop from months to weeks.
Not consulting. Not a design sprint.
It’s worth being precise about what this isn’t.
A consultant optimizes for the engagement. A forward deployed designer optimizes for the problem. The output isn’t a 60-page deck or a set of recommendations — it’s working software and validated insights. You have skin in the game because you’re embedded with the team, not flying in for a workshop.
It’s also different from a staff or principal designer at a company. Forward deployed designers are temporary and targeted. They don’t own a product area long-term. They bring fresh eyes and cross-pollinated patterns from other domains. They’re scoped to the hardest, most ambiguous problems — the ones where you don’t even know what to build yet. Think of it like a design equivalent of a senior engineer brought in to untangle a gnarly architecture problem.
The small team model
Here’s where it gets interesting for companies. You don’t need to hire Palantir. The most compelling version of this might be internal: a small forward-deployed squad that your own company spins up to tackle its hardest problems.
The squad: a forward deployed engineer, a forward deployed designer, and a researcher. Three people. That’s it. They operate like a startup-within-the-company, deployed against a specific, ambiguous problem.
Product discovery, design, and research have always been intertwined but organizationally separated. This team collapses those silos. The researcher identifies the real problem. The designer shapes the solution and iterates rapidly. The engineer handles systems integration and technical feasibility. All in the same room, same week. This is a product discovery team with teeth — they don’t just produce insights and hand them off. They produce working prototypes and validated direction.
Small teams move fast because communication overhead is near-zero. Three people don’t need standups, retros, or Jira boards. They need a shared problem and a whiteboard. Companies can deploy these squads: a new market to enter, a product area with high churn, an internal tool bleeding productivity, or an acquisition that needs integration thinking.
The rotation model matters. These should be temporary deployments — four to eight weeks — not permanent structures. After the engagement, the squad disbands and members rotate to new problems. This prevents the team from becoming just another product team, and it solves the career problem: instead of designers and researchers being stuck in support roles on feature teams, they operate at the frontier of the company’s hardest questions.
Deploy to customers, deploy across teams
The traditional playbook when a customer has a problem: run a design sprint or kick off a three-month consulting engagement. Both are heavy, slow, and optimized for process over progress.
Forward deployed squads flip this. Deploy a squad to a key customer’s site for two to three weeks. They observe real workflows, build a working prototype that addresses the customer’s specific pain, and come back with something tangible — not a report about what the customer said they wanted. For enterprise companies, where the gap between what sales hears, what product interprets, and what engineering builds is enormous, a forward-deployed squad collapses that game of telephone into direct observation and rapid prototyping.
The same model works across internal organizational boundaries. Deploy a squad to work with the sales team on their tooling. Embed with ops to redesign a workflow. Sit with customer support for two weeks and come back with a prototype that cuts ticket volume. These aren’t projects that need a six-month roadmap. Some problems need two or three smart people with the right skills paying close attention for a short burst.
This also changes the relationship with customers. Instead of “we’ll take your feedback and get back to you in a quarter,” it becomes “we’re going to sit with your team, understand the problem, and show you something in two weeks.” That builds trust and loyalty in a way that roadmap promises never will.
Why this matters now
AI amplifies each person on the squad. The designer can prototype at engineering speed. The engineer can explore more solutions faster. The researcher can synthesize data and run analyses that used to take weeks. A three-person team with AI tools in 2026 can cover the ground that used to require a ten-person cross-functional team. That’s the direct result of collapsing the build cost of exploration.
Design sprints were a step in the right direction as they tried to compress the cycle. Forward deployed teams are the same compression, but with real output. In ambiguous problem spaces, the company that learns fastest wins.
Hyperlinks + notes
The case for the forward-deployed designer — Nathan Lui (Medium)
What are Forward Deployed Engineers, and why are they so in demand? — The Pragmatic Engineer
Forward Deployed Engineers — Silicon Valley Product Group (Marty Cagan)
Forward Deployed Engineer: 5 Skills for This New Role — Salesforce
Blitzy Targets Design Bottleneck With New Forward Deployed Designer Role — TipRanks
How to get your entire team prototyping with AI — Lenny’s NewsletterAI Prototyping: How Real-World Teams Are Transforming Their Work — Product Talk
David - please correct me if I’m mistaken. But it looks like you had the right idea but then went onto using ChatGPT to get things out. I simply cannot engage in a written piece that has so many platitudes. Having read your writing for so many years this feels very different from your original tone. We need design leaders to write with conviction and gravitas. I’m obviously not saying you can’t use AI. But when everybody’s writing reads like everybody else’s then there’s no personality left. No soul.
Even before today's AI tools, I've seen teams have real success with a forward-leaning designer driving future vision prototypes with clients. It creates something powerful: genuine co-creation and a shared vision between a key client and the company. The tools are allowing designers to bring this to life even more quickly and tangibly.