Prioritizing Reusable Product Work
A monthly synthesis review is a half-day meeting where FDE and product teams meet to examine what FDEs shipped.
Work That Could Have Been Reused
Imagine an FDE finishes a deployment for one customer and builds something useful along the way. The customer benefits, but the rest of the company may never see the work. The same problem could be solved again from scratch for the next customer, and the product team would learn nothing from the field. This is the gap that the monthly synthesis review is meant to close. It is a regular meeting where FDEs and product teams look back over what was actually shipped and decide what deserves wider use.
This article follows one shipped item through the process, from the moment it leaves the field to the point where it may become a candidate for product paving. Along the way you will see who does what, how the two categories of work are told apart, and why the review happens monthly rather than at some other interval.
Following a Shipped Item Through the Review
Start with a single item that an FDE built during a customer deployment. At the moment of shipping, the item is simply work the FDE delivered. Nothing has yet been decided about whether it matters beyond that customer. The review is the step that asks that question, and it does so in a fixed order.
The path in the diagram is a single line, but it narrows at the end. Each FDE presents the items they shipped during the month. Those presentations pay attention to two categories, what was generalizable and what was customer-specific. The product team then looks across the presentations for patterns. Only a small number of generalizable items move on to prioritization for paving, and the source states that the number is two or three per month.
Who Does What in the Monthly Review
The review is a monthly half-day meeting between the product team and the FDE team. The two groups do different jobs, and the division of labor is the key to how the meeting works. The FDEs each present what they shipped during the month. Their presentation is not just a status update. The source says they pay attention to two categories: what was generalizable and what was customer-specific.
The product team's job is different. It looks across those presentations and identifies patterns. A single presentation tells the team about one customer's deployment. Several presentations side by side let the team notice what recurs, which is the view that no single FDE has from their own desk.
Neither group can do the other's job well from its own side of the table. The FDEs supply raw material from the field, because only they saw the customer context. The product team supplies the cross-customer view, because it can compare several presentations at once.
Telling Generalizable From Customer-Specific
A generalizable item is one that can be applied beyond a specific customer or context. A customer-specific item is one whose value stays tied to a particular customer's situation.
The source does not give a checklist for telling the two apart, so the distinction rests on the definition itself. A useful test follows directly from it: ask whether the item would still be valuable if the original customer's name, data, or setting were removed. If it would, it is a candidate for generalization. If its value depends on that particular customer's situation, it stays customer-specific, even if it was hard to build.
| Attribute | Generalizable item | Customer-specific item |
|---|---|---|
| Where its value lives | Beyond a specific customer or context | In one customer's situation |
| Test of removal | Still valuable without the customer's name, data, or setting | Loses its value once that setting is removed |
| Effect of difficulty | Not the deciding factor on its own | Not the deciding factor, even if hard to build |
| Next step in the review | Can be prioritized for paving | Does not move toward paving |
Attributes that separate the two categories, based on the source's definitions
From Pattern to Paving Candidate
Identifying a generalizable item does not automatically mean it gets built as shared product. The source makes a narrower claim: generalizable items are prioritized for paving, and two or three per month get that treatment. Prioritization is the step that turns a recognized pattern into a commitment for implementation.
Sorting one month of shipped items
In one month, five FDE items are presented at the review. Item A is a data-mapping helper that worked for one customer's schema and depends on that schema's field names. Item B is a generic export routine that any customer could use. Item C is a reporting tweak built for one customer's internal dashboard. Item D is a connector pattern that the product team sees recurring across three presentations. Item E is a configuration check that could apply to any deployment. Which items are classified as generalizable, and how many move on to prioritization for paving?
- 1Apply the removal test to each item
Ask whether each item stays valuable without the original customer's name, data, or setting. Item A depends on one schema, so its value is tied to that customer. Item C depends on one internal dashboard, so it is also tied to that customer.
- 2Classify the remaining items
Item B, Item D, and Item E would still be valuable outside the original customer, so they are classified as generalizable.
- 3Look for patterns across presentations
The product team notices that Item D recurs across several presentations. That cross-customer view is the product team's contribution, since no single FDE sees all three deployments.
- 4Apply the stated rate
The source says two or three generalizable items per month are prioritized for paving. Three generalizable items are available here, so the team selects two or three of them. The selection among them is a judgment the source does not spell out.
Items B, D, and E are generalizable. Items A and C stay customer-specific. Two or three of the generalizable items move on to prioritization for paving, and the rest are not prioritized this month.
Notice what the worked example does not claim. Being generalizable is necessary for paving, but it is not sufficient. The source's stated rate is what keeps the review focused, so even a long list of generalizable items may produce only two or three prioritized choices in a given month.
Why the Monthly Cadence Matters
The source describes the timing of the review as a balance between two pressures. The cadence is slow enough that FDEs are not in constant context-switching. In other words, they are not repeatedly pulled out of customer work to report. It is also fast enough that the product team is genuinely learning from the field, so field lessons do not sit unused for long.
The source gives the monthly interval as its choice but does not analyze other intervals in detail. Reasoning from the two pressures alone, a much shorter interval would press harder on FDE context-switching, while a much longer one would let field lessons wait longer before the product team sees them. The source does not state what a different interval would produce, so these are only inferences from its stated balance.
Mistakes When Reading This Process
Common mistake Treating every shipped item as a paving candidate
What it looks likeAssuming that because an FDE built something useful, the product team should build it as shared product.
Why it failsOnly generalizable items are prioritized for paving, and only two or three per month.
Do this insteadApply the removal test first, then remember that the stated rate keeps selection narrow.
Common mistake Judging generalizability by effort
What it looks likeCalling an item generalizable because it took weeks to build.
Why it failsThe definition depends on whether the item's value survives beyond the customer's context, not on how hard it was to build.
Do this insteadAsk whether the value survives removal of the customer's name, data, or setting.
Common mistake Thinking the FDE alone decides what gets reused
What it looks likeAssuming the FDE who built an item also decides whether it becomes shared product.
Why it failsThe product team looks across presentations to identify patterns, which an individual FDE cannot see from one deployment.
Do this insteadTreat FDE presentations as raw material and the product team's cross-customer view as the step that finds recurring patterns.
Common mistake Assuming the review is a status update rather than a classification and pattern-finding meeting
Practice: Classify a Month of Shipped Work
An FDE presents an item that automates a data-cleaning step. The step is useful for the current customer's specific file format, which uses custom column names that exist nowhere else. Another FDE presents an item that handles retries for any failed API call in any deployment. For each item, decide whether it is generalizable or customer-specific using the removal test, and say whether it is a candidate for prioritization for paving.
Hints
- Ask what the item's value depends on, and whether it survives without the customer's file format or column names.
- The retry item does not mention any one customer. Consider whether its value depends on a single context.
- Remember that being a candidate is not the same as being prioritized, since only two or three per month are chosen.
Key Takeaways
- The monthly synthesis review is a half-day meeting where FDE and product teams examine what FDEs shipped, with FDEs presenting their work and the product team identifying patterns across presentations.
- A generalizable item can be applied beyond a specific customer or context, while a customer-specific item's value stays tied to one customer's situation; a useful test is whether the value survives removing that customer's name, data, or setting.
- Generalizable items are prioritized for paving, and the source states that two or three per month get that treatment, which keeps the review from trying to pave everything at once.
- The monthly cadence balances keeping FDEs out of constant context-switching against keeping the product team learning from the field, and the source claims the review helps keep FDE work tied to reusable product learning.