Chapter 10 of 12 · Aishwarya Ashok
Peanut builds something worth trying
Build beside the people doing the work. Use prototypes to test assumptions, a proof of concept to test feasibility, and a pilot to learn from real operation. Agree on what the evidence must establish.
An engineering approach that brings implementation close to a customer's real operating context.
Close contact with users and existing systems lets engineering respond to the customer’s actual operating constraints as the solution develops. That is the purpose of forward deployment. The arrangement can be remote or on-site; what matters is access to the real work and feedback.
Engineering work carried out as part of, or in close ongoing collaboration with, another team.
Embedded engineers participate in another team's ongoing work and develop context through that involvement. The team may be internal or customer-facing. Shared routines make it easier to notice recurring problems and understand why earlier fixes failed. The term describes the working relationship rather than a single standardized job description.
Designing and validating a technical solution around a customer's requirements and existing systems.
The work can include architecture, integrations, feasibility checks, and demonstrations, all organized around the customer’s requirements. Some companies place solution engineering mainly in pre-sales; others extend it into delivery. Clarify the responsibilities locally, especially where they overlap with an FDE role.
Building a limited version of a solution quickly to test a specific assumption or design choice.
Choose the assumption you need to test, then build enough to test it. A prototype might reveal whether users understand a flow or whether a model can handle representative documents. Record the shortcuts and conditions behind the result. That gives the next stage useful evidence and a clear view of what remains to be built.
A bounded test of whether a proposed technical approach is feasible under specified conditions.
A proof of concept establishes feasibility within specified conditions. For an AI extraction task, that might mean testing required fields on a selected document set. Report the evidence and the boundaries together. Scale, integration reliability, and unfamiliar inputs can remain open questions even when the core technical approach works.
A limited trial of a solution with real users or work in its intended operating environment.
A pilot puts the solution into a bounded slice of its intended environment. Real users and exceptions reveal how it fits into the workflow and what support it needs. Define the users, duration, operating limits, and success measures. The outcome should help the team decide whether to expand, revise, or stop.
Specific, testable conditions a deliverable must satisfy to be accepted.
Acceptance criteria translate requirements into tests for a particular deliverable. They may specify supported inputs, required behavior, or how failures are reported. Agree on them before delivery where possible. Broader success criteria describe the intended outcome; acceptance criteria establish what this piece of work must satisfy to be accepted.
A measured reference point used to compare the performance or outcomes of a change.
Compare the new workflow with a measured reference: the existing human process, a simpler automation, or the current model version. Keep the workload and measurement conditions comparable.
If the new version gets easier cases, the result tells you less about the improvement than the headline suggests.
The effect of a system or change on outcomes that matter to the organization.
Technical performance becomes business impact when it changes an outcome the organization cares about. Look at service quality, effort, revenue, or rework alongside implementation and running costs. Use a comparison that accounts for other changes in the business. A before-and-after difference is useful evidence, but by itself it does not establish what caused it.