# Medplum let FDEs do the PM job, and the process began to break as the team grew

> Rahul Agarwal, co-founder of Medplum, handed product management to forward deployed engineers. As the team grew, he admits, every ticket started to carry too much context.

Original: https://fdetimes.net/en/news/medplum-fdes-replace-product-managers/

Medplum has no product managers. Rahul Agarwal, its co-founder and COO, says plainly that he has never been convinced of PM as a full-time role with its own hiring profile.

At Medplum, the PM's work goes to the FDEs. Yet Agarwal himself concedes that the process "starts to break at scale".

For developers aiming at FDE roles, this is a lesson about the part of the job that descriptions rarely spell out: you do not only deploy for customers, you also carry the customer's voice back to the product.

## What does it look like when FDEs do PM?

Medplum's blog says FDEs are the main input to the roadmap. The FDE team triages every issue, feature request and bug from customers and the community, which is the whole intake process that belongs to PMs at other companies.

The company wants FDEs to help decide what the product becomes, not just to help customers make good use of the product as it stands.

The mechanism Agarwal describes is fairly simple. Each week, requests are collected in a spreadsheet, the FDEs negotiate among themselves to produce a priority ranking, and one FDE, on rotation, presents it to the engineering team.

## The break is about context, not headcount

Agarwal explains the failure briefly: once the team has ten or twenty FDEs, every ticket drags along too much context. The figure should not be read as a hard limit, though. He uses it to illustrate overload, and says he would fix the design rather than treat it as a fixed ceiling.

Picture this week's on-duty FDE presenting a ticket that reads "need a date filter". A colleague wrote it after three calls with a customer the presenter has never worked with. Engineering asks why the customer needs it, how the customer is coping now, and whether anyone else needs it. The presenter cannot answer.

Next week, someone else is presenting.

Looking back, Agarwal therefore thinks the person playing PM should not rotate weekly. He suggests a monthly or quarterly cycle, tied to customer assignments, so that presenters actually understand the tickets they bring into the room.

## The hardest problem for FDEs

Changing the rotation only eases the symptoms. Agarwal believes the root problem persists at every scale: in his view, the hard problem for FDEs is preserving context as knowledge passes through hundreds of hands.

Tandem, a company building tools for FDE teams, sees the same gap: recording what is learned in the field is real work, it competes with delivery for time, and delivery always wins.

The venture firm Northzone looks at the problem through incentives. FDEs are driven to win their own customers; product teams are driven to build things many people share. When FDEs are tied to the outcomes of individual accounts, the account side wins: they stop being product scouts and become account managers.

**Key point:** Customer signal is only worth something when someone carries it back to the product.

Northzone puts it in terms of bricks: FDEs pick up bricks in the field, but if nobody carries them back to the product team, the company does not really have an FDE organisation.

## What to practise

The skill Medplum is short of as it grows is one you can practise now: writing a ticket that someone who has never met the customer can read, understand and act on.

Go back to the date filter example. The bad version is a single line: "Customer X needs date filtering, high priority." The good version, still only five sentences, answers in advance the questions engineering will ask.

Customer X's operations team cannot filter records by date, so every morning they search by hand. They raised this on all three calls, and the call notes are attached. For now they export the data to Excel to filter it.

Two other customers have asked for something similar, so this is not one account's peculiar need. If it is not built, Customer X will keep relying on an Excel file outside the system. The reader does not need to call you back to reach a decision.

When reading job descriptions, look for phrases such as "triage feature requests" or "input to roadmap". They signal that the company expects you to do the PM's work too. In interviews, ask how signal from FDEs reaches the product team, who reads it, and how often.

Companies that drop the PM role will not run short of engineers who can code. What they lack are people who know how to package context so it is not lost along the way.

**Try this week:**

- Take a recent customer request and rewrite it as a five-sentence ticket: who needs it, what is blocked, the evidence, how the customer is coping, and what happens if it is not done.
- Reread three tickets you wrote last month and mark every place where someone else would certainly have to come back and ask you.
- Add a line to your CV describing a time customer feedback you gathered changed a product decision, and say exactly how you carried that signal back to the product team.

## Sources

- [Product Management Without Product Managers: A Conversation with Rahul Agarwal](https://www.fdehub.org/p/product-management-without-product)

- [Forward Deployed Engineering, Medplum-Style](https://www.medplum.com/blog/fde)

- [Forward Deployed Engineers: The Role Every AI Company Wants But Not Everyone Needs](https://northzone.com/insights/forward-deployed-engineers-the-role-every-ai-company-wants-but-not-everyone-needs)

- [How FDE teams work with product and engineering (without broken telephone)](https://usetandem.ai/blog/fde-product-engineering-feedback-loop)