Every PM an FDE? The Rotation Is Not the Loop

Atlassian published its forward deployed engineering numbers on October 7, and one sentence in the post is going to travel further than the numbers. Paavany Jayanty, who leads AI Forward Deployed Engineering in the US, said every PM or engineer should be an FDE at some point. "I think it should be mandatory."

I would take the tour. I'd also say the tour is the smaller half.

The short version

Atlassian has 46 forward deployed engineers, is moving toward 100, and says they have worked with more than 100 enterprise customers and put more than 80 AI agents into production. Jayanty argues every PM or engineer should do a stint as an FDE, by mandate. The same post says the loop back into product is what makes the program a strategic bet and not a services line, and it gives no mechanism for that half. A PM rotation is not that mechanism. A PM back from one customer carries an anecdote with a lot of conviction, and one customer is a workaround. The loop runs on the receiving side: one named PM per product area who reads every handback packet and answers in writing within two weeks, generalize, keep as configuration, or kill. Mandate that. Then send that PM on the tour.

What Atlassian said

The post is an unbylined piece on Inside Atlassian built around an interview with Jayanty. I read it in full.

The field numbers are specific. 46 engineers today, "moving quickly towards 100 by the third quarter," across the US, EMEA, and India. More than 100 enterprise customers. More than 80 agents in production. Expedia archived 600,000 Confluence pages and saves 3,200 hours a year. A financial institution went from uncertainty to a working agent in a secure sandbox in under three weeks. A motorsports organization went from zero AI use cases to six production agents in under five months. The program is open to a select group of enterprise Cloud customers using Rovo, and it usually starts through an account executive or a customer success manager.

Then the loop. "We don't just deliver solutions," Jayanty says. "We take the signal we get from customers and bake it back into our product teams, so it has a multiplier effect; every customer benefits." The post calls this the thing that makes an FDE program a strategic bet.

There's no number on that half. No count of what came back, no description of who receives it. That isn't a criticism of a blog post, which is allowed to be a blog post. It's where I'd look first if I were copying the model.

And then the line: with building becoming easier, every PM or engineer should be an FDE at some point, and it should be mandatory. Her reason is good. Embedded with the customer's team, "you don't have the luxury of building something people don't want."

Why the tour is not the loop

I've run the product side of this, and I wrote the failure down in Absorb Pain, Excrete Product: The FDE Handback. Deployment people come back from a customer with a story. The story is good. It's told in a meeting, it lands in a Slack channel, somebody says "we should look at that," and then the roadmap sales already promised eats the quarter. The learning was real and it evaporated.

A PM back from a tour is that story with more authority. Weeks inside one customer, a title that gets listened to, and a lot of conviction. I think that's the risky kind of evidence. The handback packet has a line for the count, how many other customers have the same problem, for exactly this reason. One is a workaround. Three is a feature the company has already paid to discover. The person on tour saw one.

Vinoo Ganesh ran the best-known rotation there is. He led Project Frontline at Palantir, which took software engineers and turned them into forward deployed engineers, and he writes at Latent Space that around 250 people went through it. Two sentences from his piece belong next to Jayanty's.

The first: "one deployment is an anecdote and the tenth is a pattern."

The second is about how things worked before the rotation. Product development did its customer discovery secondhand. "None of that was a process, though. It ran on relationships." A good insight from the field made it into the platform or was dropped "depending on who was in the room."

So a rotation fixes something real. Ganesh's own story is a transaction store that behaved exactly as specified until it met a bank's production data, and he became an FDE by flying out to fix it. Nobody who has stood in that building forgets it. But what he says the role is for is the thing that happens afterward. In his words, the engineers who mattered were the ones "who came back and changed what we built."

Coming back and changing what gets built is a job with a desk on the product side. If nobody sits at it, the rotation produces very empathetic people and the same roadmap.

The rewrite

Old: every PM should be an FDE at some point, by mandate.

New: every PM owes an FDE a decision, by mandate. Then rotate.

1. One named PM per product area reads every handback packet. Not a team alias. The handbook calls this role the PM-as-Editor, and The Deployment-to-Product Loop: How FDE Work Becomes Roadmap is the long version of why it's rarely staffed.
2. The packet is one page. What the customer runs that the product didn't ship, in configuration terms. The customer's eval rows. What they turned off. The count of other customers with the same problem.
3. A written decision within two weeks. Generalize, keep as configuration, or kill. "We'll consider it" isn't on the list. An FDE who sends three packets into silence stops sending them.

Then the tour, with two conditions attached. The PM writes the go-live packet for that deployment themselves, so they learn what one costs to produce. And they come home as the editor for that area, so the next packet has somewhere to land.

That order matters to me. A company that mandates the tour first has a travel program. Put the decision first and the loop exists before anyone gets on a plane.

At 46 engineers this still runs on people knowing each other. At 100 it won't.

What this means in the seat

If you run product and a PM rotation is on next month's staff agenda, say yes and add one line: who answers the packets. If you can't name the person for each product area, name them before you book the first tour.

If you're the PM being sent, bring home the count. Ask the FDE lead which other customers have the problem you just watched get solved. If the answer is none, you have a good story. Tell it as one.

If you're the FDE, a PM on your site for six weeks is the best chance you'll get to make someone in product owe you an answer. Have them write the packet with you.

This is a standalone piece next to The FDE Transition, which has the packet, the codebase contract, the sales handshake, and the month-two handoff in order. It belongs to the running argument on AI Product Management: once building is cheap, the scarce work is deciding what gets built for everyone, and a rotation doesn't make that decision. A named person with a deadline does.

One thing to try this week: take the last three things your field team told product. For each, find the written decision that came back and the name on it. Count the blanks.

Related answer: Should product managers rotate through forward deployed engineering?

Sources: Inside Atlassian, "Meet the Forward Deployed Engineer," Atlassian Blog, October 7, 2026, with Paavany Jayanty quoted. Vinoo Ganesh, "The Rise of the Forward Deployed Engineer, and How To Do the Job Right," Latent Space, September 12, 2026. Absorb Pain, Excrete Product: The FDE Handback, falkster.com, September 24, 2026.