The Product Feedback Loop

After this lesson, you will be able to describe a product Delta, turn field evidence into a useful feedback note, and work with product and engineering teams to decide what should become reusable. NorthPort Freight is fictional; the workflows and feedback examples are illustrative.

An FDE sees where a product meets a customer’s actual systems, data, and workflow. That position creates an opportunity to help improve the product, but it does not make every customer request a product requirement. A useful feedback loop carries a specific problem and its evidence back to the people who can act on it, then carries the decision and its consequences back to the customer team.

In this course, a Delta is the gap between what the product can do today and what a customer needs for a particular workflow. It may reveal a missing product capability, a platform limitation, a documentation gap, an integration need, or a customer-specific configuration. It is a description of a gap, not a promise that the product team will build a feature.

OpenAI describes FDE work as learning customer workflows, defining success, proving solutions in production, and making successful patterns repeatable. Its public explanation says field deployments can show where products or models fall short and that FDEs can bring this learning to product and research teams. That is one company’s description of its practice, not a standard process every organization uses. The core lesson is broadly useful: record what happened in the field so the next product decision can use the evidence.

Notice the Delta and gather evidence

A request is a starting point for investigation. “Add a field for dispatch zone” may be a clear request, but it does not yet explain the user’s task, the failure that makes the field necessary, or whether the same need exists elsewhere. Ask what the user is trying to complete, where the current product blocks them, what workaround they use, and what happens if nothing changes.

Separate the need from the proposed solution. A customer may ask for a permanent override button because a source record is sometimes stale. The need might be to resolve a time-sensitive mismatch while preserving an audit trail. Other options could include showing the source timestamp, adding an approval step, or fixing the feed. Write down the request in the customer’s words, then capture the workflow and evidence that explain it.

Useful evidence can include an observed task, an approved support case, a test result, a repeated integration failure, a documented policy, or a metric with a known definition. Note its scope and limits. One dispatcher struggling with a screen proves that the interaction was difficult for that person in that context; it does not tell you how common the problem is. Do not copy sensitive customer data into a product ticket when a redacted example, synthetic reproduction, or case identifier will let the team investigate.

GOV.UK’s guidance on core agile principles recommends gathering feedback from users early and often, using real service data, and improving through repeated delivery. Its guidance on sharing user research findings says findings are useful when a team can use them to improve the service or its roadmap. The public-service context differs from a commercial product, but the practical point applies: send evidence in a form the receiving team can evaluate, not only a summary that says “the customer wants this.”

Decide what should be reusable

A feature that helps one customer can still be valuable, but generalizing it has costs. Product teams must weigh repeated need, strategic fit, implementation and maintenance cost, security and support implications, and the effect on existing users. The FDE can help gather evidence and explain technical constraints; the product owner decides roadmap priority, and engineering assesses a design. The customer decides whether a customer-specific workaround is acceptable for their environment.

Use these questions to frame a discussion:

• Is this a product gap or a local setup issue? Check configuration, documentation, permissions, data quality, and integration behavior before proposing a product change.
• Who else has this need? Look for separate customer evidence or internal research. Similar words in requests do not guarantee the same underlying need.
• Does the proposed behavior fit the product’s supported use? Consider user roles, security boundaries, accessibility, failure handling, and the wider workflow.
• What would it cost to own? Include development, migration, testing, support, documentation, configuration, and future compatibility work.
• Can the need be met by a supported configuration or extension point? If so, a reusable product feature may not be necessary.
• What evidence would change the decision? A prototype, a second workflow observation, a support trend, or a technical spike can reduce uncertainty.

A practical triage often has four outcomes:

1. Use an existing capability: the need was already supported but undiscovered or misconfigured. Improve setup or documentation if users repeatedly miss it.
2. Improve a reusable capability: multiple workflows need the behavior and a product-level design can support them without creating unsafe complexity.
3. Keep a customer-specific extension: the need is valid for this customer but depends on a local policy, data model, or integration. Make ownership and support limits explicit.
4. Decline or defer: the request is outside the product’s purpose, has unacceptable risk or cost, or lacks enough evidence. Explain the reason and what new evidence could reopen the decision.

Do not treat “generalizable” as a synonym for “put it in the core product.” A reusable connector might belong in an integration catalog, an optional module, a partner extension, a reference implementation, or a documented configuration pattern. A customer-only feature can also create a long-term burden if the customer expects the vendor to maintain it. Record who owns code, testing, upgrades, monitoring, and support before the implementation proceeds.

Productized consulting and one-off work

Productized consulting is customer problem-solving work that becomes a repeatable capability others can use. A bespoke solution is not productized simply because it is written in code or demonstrated more than once. The work becomes repeatable when the team can explain its supported inputs, configuration, limits, testing, upgrade path, and owner, and when there is evidence that additional users benefit from it.

The first deployment often reveals hidden variation: one customer’s identity system differs, a second has a different source schema, and a third has stricter approval rules. A reusable capability should make these variations explicit and supported. If every new deployment requires editing a customer branch or adding another undocumented exception, the apparent reusable feature may really be a collection of custom forks.

Before investing in productization, estimate the whole lifecycle. Who will triage bugs? How will the feature be configured and documented? Does it add new data handling or access paths? How will backward compatibility work? Who validates it against future model, API, and platform changes? What happens to the first customer if the feature changes? These questions expose the ongoing cost that a quick prototype can hide.

It can be sensible to keep work specific when it encodes local policy, a proprietary data mapping, or a one-time migration. Put the boundary behind a supported interface where possible, document the exception, and avoid mixing customer-specific rules into a shared default. A product decision can also be “learn more first.” A small experiment with a fixed end date and a specific evidence question can be better than committing to a permanent feature on weak evidence.

Write a product feedback note

The note should be short enough to read and complete enough to act on. Send it through the product team’s agreed intake path. Link to approved evidence instead of attaching customer information. Make the customer impact clear, state what is known versus inferred, and identify the decision or review requested. The note records field learning; it does not guarantee a roadmap slot.

1Product feedback note
2
3Title: [customer-neutral problem statement]
4Submitted by / date: [owner / date]
5Product area and version: [component, build or release]
6Customer and workflow: [use approved internal reference, not sensitive details]
7
8User need
9- User or role: [who is affected]
10- Task: [what they are trying to do]
11- Desired outcome: [what success would let them accomplish]
12
13Current behavior and gap
14- What the product does today: [observed behavior]
15- Delta: [where that falls short of the need]
16- Workaround and cost or risk: [what happens now]
17
18Evidence
19- Observation, test, or measure: [specific evidence and link]
20- Scope and limitations: [sample, environment, date, unknowns]
21- Other evidence or customers: [separate verified sources, if any]
22
23Possible directions
24- [configuration, documentation, product change, extension, or other]
25- Main trade-offs: [maintenance, security, support, compatibility]
26
27Request to product team
28- [triage, design review, discovery, technical spike, or decision]
29- Decision owner and desired review date: [role / date]
30
31Customer communication
32- What has been promised: [exact statement or none]
33- Next update owner and date: [person / date]
34
35Status: [new / triaged / accepted for discovery / planned / declined / shipped]
36Decision and rationale: [complete when triaged]
37Follow-up link: [product issue, decision record, release note]

For the fictional NorthPort assistant, a useful note might describe that dispatchers cannot tell whether a retrieved procedure was updated after a recent policy revision. The evidence could be a synthetic test showing that the index timestamp is not exposed in the workflow. The product team would still need to learn whether freshness visibility is useful across products, which source-of-truth model applies, and what indication users can safely interpret. The note should not claim that all dispatchers have this problem or that a UI badge is the only solution.

Work with product and engineering teams

Route the note to the team that owns the relevant capability, such as product, platform, model, integrations, or developer experience. Include enough context for a first triage, then be available to answer questions. A product manager may ask which user need is unmet; an engineer may ask for a minimal reproduction; security may need the data path; support may want to know how many incidents the issue creates. These are different views of the same decision.

Agree on a feedback status and close the loop. “Received” means the note arrived. “Triaged” means a team reviewed it. “Planned” means it has a place in a plan, not that it is already available. “Shipped” should point to the version or release and describe any limitations. If the team declines or defers it, explain the rationale to the customer in terms they can act on. Do not promise a delivery date before the owner has made a commitment.

Protect the relationship when a customer asks why a request was not built. Acknowledge the need, describe the available supported path, and explain what evidence or condition would lead to another review. If a workaround is risky or creates significant operating cost, raise that plainly and discuss a customer-owned mitigation. Do not imply that the customer’s need is unimportant because it is not on the roadmap.

Once a reusable capability ships, verify it against the original use case and at least one other relevant scenario. Confirm documentation, permissions, configuration, monitoring, and ownership. Tell the customer what changed and what it still does not do. Feed adoption and failure evidence back into the next iteration. A release announcement is not evidence that the field problem is solved.

Mistakes beginners make

Forwarding a feature request without the user problem. The receiving team sees a proposed solution but cannot assess the need or compare it with other options.

Fix: Describe the task, current behavior, consequence, workaround, and the evidence behind the request.

Treating one customer's request as a universal requirement. A real problem for one workflow may be local to its policy, data, or organization.

Fix: Label the evidence scope and look for independent examples before recommending a shared capability.

Building a permanent custom fork as a quick fix. The initial delivery can hide upgrade, security, testing, and support costs for both teams.

Fix: Set an owner, boundary, maintenance plan, and review date. Compare configuration and supported extension options first.

Promising roadmap delivery on behalf of product. An FDE’s enthusiasm does not create a product commitment.

Fix: Say that the request is being evaluated, name the decision owner, and agree when the customer will hear an update.

Recap and try it yourself

A Delta is a product gap revealed by a customer workflow. Capture the user need and evidence before proposing a feature. Decide whether the issue calls for existing configuration, a reusable product capability, a customer-specific extension, or a documented no. Productized consulting means the work has a supported repeatable shape and an owner, not simply that code can be copied. Send a feedback note through the product team’s process and return the triage decision to the customer without promising a roadmap outcome you do not control.

Try it yourself: use the fictional NorthPort index freshness issue to fill in the product feedback note. Separate the observed behavior from the suspected cause. Give two possible product directions and list the evidence needed to choose between them. Decide which team should triage it, what you can tell the customer today, and when you will send the next update.

Sources

Checked on 5 November 2026. OpenAI's Forward Deployed Engineering overview describes its own approach of defining customer outcomes, validating in production, learning from use, and making successful workflows more repeatable. Its explanation of what FDE means at OpenAI describes how customer deployments can reveal product or model gaps and feed product and research work; this is a company-specific account, not a universal FDE process. GOV.UK's core agile principles supports early user feedback, iterative improvement, and use of real service data. Its guidance on sharing user research findings supports presenting research in a form teams can use to improve a service or roadmap. These are public-service references adapted as general product-learning practices. NorthPort and all examples are fictional.