Why designers make good forward deployed engineers

I’ve always been a product designer, whether or not that was the title. Music, cinema, setting up a good evening at the house. I like arranging things so the experience comes out right, and that carried into the design work without any decision on my part.

Then Lovable and Claude showed up, and the ideas I’d been prototyping could become working products. I’m not a traditional coder. I think in pathways, though, the way an engineer or an architect does, and that turns out to be most of what the tools need from you.

It’s product design, taken further

Forward deployed work is product design with the last step included. Sit with the customer, find the real problem, shape the answer, and then build the thing instead of handing over a prototype. The same instincts, running longer.

Collaborate is the clearest case I have. The brief was to modernize an event site and help sell tickets. Talking it through with the event team, the question underneath was different: is this event worth it for someone in my role, and how do I get it approved?

So the site got built around those two questions, and the visual refresh came along for the ride. A designer who stops at the mockup never gets to make that call.

The habit that carries over

One rule I apply every week: everything has an intention and an explanation. Nothing gets built because it seemed like a good idea in the moment.

If I can’t say what a thing is for and how it fits the larger whole, it isn’t ready to be built. That sounds like a design habit. It’s also what keeps an AI-assisted build from sprawling, because the tool will build whatever you ask for.

What I had to unlearn

The hard part, and it still catches me, is seeing how small decisions scale. A choice that looks cosmetic on day one is structural by month three. Designers are used to iterating freely, and in a product that’s growing, every iteration has a cost downstream.

The other lesson was learning where the efficient build lives versus where the design wants to go. There’s a balance between what’s buildable in a reasonable time and the experience you’re after. AI made that balance much easier to find, but you still have to want to find it.

So what I unlearned was attachment. A design idea that makes the product slow to build or awkward to run has to go, however good it looked in Figma.

Who shouldn’t do this

What kind of designer would hate this work? I don’t have a good answer, because I don’t think that designer is in the field anymore. The pure hand-off role, the one that ends at the prototype, is going away.

A designer working today is already doing FDE-shaped work: talking to the people who have the problem, and more and more often, making the thing themselves. If that sounds like your day, you’re closer than the job titles suggest.

---

Thanks for reading. If you’re working on something like this, email me.