Forward-Deployed Engineering

What FDE Is

Forward-Deployed Engineering (FDE) is a way of temporarily bringing a product engineer close to a customer engagement. While helping the customer adopt or use Witboost, the engineer observes real product friction, identifies small product improvements, and can carry eligible changes back into the core product.

The forward-deployed engineer connects two contexts:

• the customer context, where installation, configuration, integration, and day-to-day usage reveal concrete problems;
• the product context, where those findings can become maintainable improvements available to other customers.

FDE shortens the feedback loop between customer evidence and product engineering. For example, an engineer may discover that a recurring configuration error is difficult to diagnose, then propose and implement a small validation or error-message improvement in the product.

FDE is not a separate engineering team, customer-specific custom development, or a replacement for Customer Support. It is also not a way to bypass the product roadmap. It is a bounded delivery path for small, reusable changes discovered through direct customer work.

FDE complements the standard Product Delivery Process. It is not a general fast track for product features and does not bypass security, quality, review, or release controls.

When FDE Applies

FDE may be used during or shortly after a customer engagement when the engineer working directly with the customer identifies a concrete bug or improvement.

A candidate must be:

• small and bounded, with a short and credible implementation effort;
• atomic and independent, without broad architectural changes or cross-team coordination;
• grounded in customer evidence, rather than a speculative feature request;
• owned end to end by the engineer proposing the work;
• compatible with product and release standards, including testing and documentation.

Work that is large, cross-cutting, breaking, or dependent on broader product decisions follows the normal product discovery and release-planning process.

Process

1. Identify: the forward-deployed engineer identifies a customer-backed bug or improvement.
2. Record: the engineer creates a traceable delivery item describing the problem, customer value, expected outcome, rough size, and why it qualifies for FDE.
3. Review: Product, technical, and delivery owners confirm that the item fits the FDE criteria and aligns with product direction.
4. Implement: the engineer delivers the change using the normal repository workflow.
5. Validate: the change receives peer review, targeted quality assurance, tests, security checks, and documentation as applicable.
6. Deliver: the approved change enters either the next regular release or, when customer impact and urgency justify it, the controlled patch process.

Delivery Paths

Next Regular Release

This is the default path. The completed change is merged, included in the next planned release, and communicated to the customer.

Patch Release

A patch is considered when the customer cannot reasonably wait for the next regular release. Patch delivery follows the normal release, compatibility, validation, and communication controls.

Guardrails

• FDE work must remain visible and traceable.
• Customer urgency does not override security or quality requirements.
• New behavior with unresolved product or quality uncertainty should be disabled by default or otherwise isolated until it is ready for wider adoption.
• Customer-specific evidence may motivate the work, but the resulting product change should remain maintainable and consistent with Witboost's product direction.
• If the work grows beyond the agreed boundary, stop and move it into the standard planning process.

Responsibilities

• The Forward-Deployed Engineer identifies, proposes, implements, and follows the item through validation.
• The Product Owner confirms product value and direction.
• The Product Area Lead confirms technical fit and maintainability.
• The Delivery Lead confirms that the work is bounded and can be handled without undermining committed delivery.
• Reviewers and QA apply the same standards used for other product changes.