How Forward Deployed Engineering is done at Kepler — Vinoo Ganesh
Kepler frames forward deployment as product discovery: observe real work, ship the smallest useful fix, then turn repeated pain and customer vocabulary into durable product leverage.
A customer requested a **47-page specification**, 14 metrics, and a three-month BI project. On-site observation revealed the immediate need was one late-truck alert, built in **4 hours**; another pipeline reportedly fell from 17 hours to about 2.
Builders should watch users perform the job, ask what happens next, and solve a small repeated pain before expanding scope. Treat copied data, tab switching, recurring tasks, and overloaded terms as evidence for tools, integrations, and a product ontology.
A customer requested a **47-page specification**, 14 metrics, and a three-month BI project. On-site observation revealed the immediate need was one late-truck alert, built in **4 hours**; another pipeline reportedly fell from 17 hours to about 2. Builders should watch users perform the job, ask what happens next, and solve a small repeated pain before expanding scope. Treat copied data, tab switching, recurring tasks, and overloaded terms as evidence for tools, integrations, and a product ontology. Small fixes are rarely temporary: one improvised retention script spread across a nearly **100,000-person customer** and remained in use a year later. Fast delivery therefore still needs production assumptions, ownership, and a path into the core product.
This makes field observation the mechanism for finding the minimum useful deployment, not merely a discovery ideal: a large requested project can collapse into one production-worthy alert. It reinforces prior advice to encode real workflows and resist one-offs, while adding that even four-hour fixes need ownership and a route into the product because local tools can spread unexpectedly.