CUST.5 - Run Field Learning and Return a Productization Candidate

Type: Method pattern Status: Stable

CUST.5:1 - Problem frame

Use this method when work in a customer setting can resolve an uncertainty that matters to local delivery and to a possible shared contribution. It applies to a bounded probe and to repeated inquiries within a continuing field function.

Start with the decision that could change, the smallest attainable answer and the current work that must remain supported. A customer site is not automatically a research setting, and a field engineer’s presence does not authorize every experiment or reuse.

If a known method already obtains the needed result, perform it. If further inquiry cannot change the decision at reasonable effort, retain the supported choice or state the limit.

CUST.5:2 - Problem

Local delivery produces rich experience but often returns only requests, anecdotes or a working artifact. Product development cannot recover which conditions caused the result or what can transfer. Conversely, a probe optimized for general learning can leave the local customer with an unfinished obligation. Both receiving uses must be made explicit and protected.

CUST.5:3 - Forces

CUST.5:4 - Solution

CUST.5:4.1 - Establish the live question and protected work

Name the local decision and the shared-development decision. They may need different answers. “Can this private environment support the monthly service?” is local. “Which setup and support conditions can define a repeatable private-hosting profile?” is shared.

Describe what a useful answer would change: proceed, alter the scope, choose another way, keep the result local or stop. Identify the uncertainty that prevents that choice. Recover already available evidence before designing new work.

Protect the operating baseline: current service, support commitments, access conditions and people whose work the attempt could disrupt. Set a bounded resource and observation window, a recipient for each answer and stop conditions tied to harm, exhausted means or lack of decision value. These bounds can be revised explicitly when the receiving decision changes.

IS.1 — Agree a Useful Implementation-Support Undertaking supplies an agreed implementation-support undertaking; IS.2 — Find the Implementation Difficulty and Obtain the Next Useful Contribution supplies inquiry into the difficulty and selection of the next useful contribution. Obtain those results where needed, then state how the proposed field action will serve both receivers.

CUST.5:4.2 - Construct a discriminating attempt

List the plausible explanations that imply different actions. For a deployment failure, candidates might include missing access, inadequate preparation, an incompatible interface, an unsuitable family assumption or insufficient support. Choose observations or small changes that can distinguish them.

Use MKT.12 — Investigate a Customer or Market Question for a Decision for a customer or market question and its evidence/permission conditions. Use the relevant engineering method for a technical trial. A live intervention is not necessary when an existing trace, safe simulation or qualified analysis answers the question adequately.

Preserve the conditions needed to interpret the result: relevant configuration, input meaning, performed actions, observed outcome, help supplied and significant deviations. Record enough to distinguish a product limitation from exceptional rescue. Do not accumulate personal or sensitive information merely because the setting makes it accessible.

The connected example in Engineering.Reference:22 — How can a team organise search while keeping current service workable? explains developing a new customer integration beside current service. Use its complete treatment when that is the live engineering situation; receive the bounded technical and operating result, then perform the additional local/shared interpretation below.

CUST.5:4.3 - Arrange people, decisions and permitted information use

Compare using the current team, a bounded field team and an outside contributor against the same result and protected work. Include access, domain understanding, time away from existing delivery and the ability to return learning. A separate FDE unit is one possible arrangement.

Use the decision-bearing contributions in CUST.1:4.3. Field performers may propose a common change without having authority to admit it; the product holder may reject a shared form without cancelling a separately supported local service. An assurance contribution should have the independence required by the consequential claim.

Distinguish permission for local performance, observation, use of findings, disclosure and artifact transfer. State the next recipient and purpose before collecting or transmitting material. Where the product team cannot access underlying customer material, obtain an adequate permitted statement, independently obtained evidence or a qualified contribution. If that cannot be done, leave the shared inference open. Lack of access is not permission to disclose.

CUST.5:4.4 - Perform the attempt and keep deviations interpretable

Carry out the permitted work with the support and stop conditions established. When a deviation occurs, preserve what it changes in the question. If a specialist quietly performs the hard part, record that contribution; do not later describe the result as independent repetition.

Address urgent local failure through its proper operating response. Do not delay it for a convenient research report. Conversely, a repair that restores service need not answer the shared hypothesis. State the narrower result when that is all the evidence supports.

If successive improvisations change the object of the trial, re-establish the question and conditions. Continuing under the old label can produce an impressive outcome with no interpretable basis.

CUST.5:4.5 - Produce two qualified answers

For the local receiver, explain whether the intended result is obtainable, what help and conditions it needs, what remains unresolved and what can happen next.

For the shared-development receiver, recover the consequential deltas, the proposed transferable function or method, the supporting conditions, the local residue and the nearest contrary case. Include hidden work, permission limits and a suggested next construction or inquiry. CUST.3 receives a family candidate; CUST.6 receives a delivery-method candidate. Neither receives an automatic admission.

Stopping can protect resources and expose a boundary that prevents a broader false claim.

CUST.5:4.6 - Return the result into actual product and practice work

Have the receiving practitioner use the answer in a real next decision: revise the family boundary, build a member, change the delivery method, retain a local service or reject a proposed common form. Resolve missing authority or access that prevents this use. “Feedback sent” is not evidence that the receiving work can continue.

A permanent field function repeats this method across changing questions. It needs ongoing connections with product and operating work, not an endless unfinished probe. Review recurring results for general knowledge implications: does the pattern of cases challenge a claim about transfer, support or scale? Keep that knowledge revision distinct from a change to one customer’s configuration.

CUST.5:5 - Archetypal Grounding

A private-hosting attempt initially appears to fail because installation is difficult. The field team recovers two explanations: the deployment tool is inadequate, or the customer’s access policy prevents the ordinary setup path.

A permitted simulation and one supervised setup show that the tool works when a named access contribution is supplied. During the local attempt, the author’s manual correction also reveals an undocumented input precondition. The local service can continue with that precondition and scheduled assistance. The shared answer is narrower: a private profile is plausible, but its preparation and support are not yet independently repeatable.

CUST.3 receives the access and input constraints; CUST.6 receives the missing preparation operation. The product maintainer does not infer that every private environment is supported. The customer does not receive an unagreed commitment that the supplier will eliminate all manual work.

Change the result: the customer cannot provide the required access. The attempt stops before live deployment. The negative finding still excludes that environment from the proposed family. The local receiver obtains a feasible hosted alternative or an explicit inability to provide the requested service.

For a public service, field inquiry might compare whether a difficulty comes from translated instructions, device access or missing facilitator help. The method still needs permitted participation and a useful local response; it supplies no automatic causal attribution from one session.

CUST.5:6 - Bias-Annotation

Field accounts can overrepresent accessible, cooperative or commercially prominent customers. Choose differing cases for the question and avoid treating a convenient sample as the target population.

The method can favor what product teams can incorporate. Preserve local benefits and negative knowledge even when neither becomes a product feature.

CUST.5:7 - Conformance Checklist

• Do local and shared receivers have distinct questions and attainable answers?
• Is current work protected by actual resources and stop conditions?
• Can the attempt distinguish the explanations that change action?
• Are deviations, assistance and evidence limits recoverable?
• Are collection, use and transfer permitted for the receiving purpose?
• Can the inquiry end with a local-only, negative, uncertain or stopped result?
• Has the answer changed or enabled receiving work, rather than only been transmitted?

CUST.5:8 - Common Anti-Patterns and How to Avoid Them

Demo success becomes production evidence. Preserve the difference between the demonstrated conditions and ordinary use.

Every field engineer is a product approver. Obtain the actual common-admission decision.

Only success is reported. Return the supported negative boundary and its implication.

Permanent field presence means no stopping point. Bound each inquiry while maintaining the continuing function.

CUST.5:9 - Consequences

The method can turn field experience into usable local and shared knowledge while protecting customer work. It adds the cost of interpretable observation and receiving interaction.

It can legitimately conclude that a promising local solution should remain local. That result may be better than supporting an inadequately generalized product.

CUST.5:10 - Architectural Rationale

Two receiving decisions explain why field work needs both delivery and learning boundaries. A single “handover to product” output loses local continuity; a local-only report loses the transferable conditions. The method joins them without equating them.

CUST.5:11 - SoTA-Echoing

Official FDE descriptions from Palantir and OpenAI describe work spanning customer implementation and feedback to product teams. The full-text practitioner account by akshayk emphasizes continuing field/product learning rather than a temporary deployment squad. These sources establish described practice, not comparative effectiveness.

CUST adopts the continuing feedback connection and qualifies it with bounded questions, permissions, current-service protection and all legitimate outcomes. The complete Implementation Facilitation methods and Engineering.Reference:22 already explain substantial inquiry and support work; they are retained instead of reconstructed from job descriptions.

Compared with a success-only pilot or a feature-request pipeline, the selected line changes what returns: conditions, hidden assistance, exclusions and the next receiving action. Reopen it when field inquiry repeatedly fails to produce a usable or permitted contribution.

CUST.5:12 - Relations

CUST.5 can start from an unresolved delivery question without a full CUST.1 cycle. CUST.2 supplies recovered differences where available; CUST.3 and CUST.6 receive qualified common candidates; CUST.7 bounds resources; CUST.8 protects dependent customers when a shared change follows.

IS.5 — Sustain, Transfer, Extend or End Implementation Support supplies sustaining, transferring, extending or ending implementation support. Receive its continuation result and retain its conditions when concluding the field attempt.

CUST.5:End