How to Scope Your First Project With a Forward Deployed Engineer
“We want to use AI” is not a project. “Our support team spends two hours a day finding order details across three systems” is. The first is a wish; the second is something an engineer can fix by next month.
The one-page scoping checklist
1. The problem, in one sentence
Describe the pain, not the solution. “Invoices are entered by hand from PDFs, which takes a full day each week and causes errors” is better than “we need OCR.”
2. Who has the problem
Name the team and, ideally, two or three people the engineer can sit with in week one.
3. How you’ll know it’s solved
Pick one or two measures: hours saved, errors reduced, time to answer a customer, number of manual steps removed.
4. Systems and data
List the tools involved (ERP, CRM, spreadsheets, email) and what access the engineer will need. Flag any sensitive data and the rules around it.
5. The decision-maker
One person who can approve trade-offs within a day. Slow decisions are the most common reason embedded projects stall.
6. The first two weeks
Agree what a useful first result looks like, such as a working prototype on real data used by one person. Then plan the next step from what you learn.
What makes a good first FDE project?
- Painful and frequent: it happens every day or every week.
- Contained: one team, a few systems.
- Measurable: you can see the difference in numbers.
- Visible: success will be noticed by people who decide on the next project.
What to avoid in a first scope
- Company-wide “transformation” goals with no single owner.
- Projects that depend on another team’s roadmap.
- Problems where nobody can give the engineer real data.
Bring your checklist to a call
If you can fill in most of this page, you’re ready. If you can’t, that’s fine too: helping you define it is part of the job of a Forward Deployed Engineer. Talk to an engineer at Rabbit’s Hat.
Frequently asked questions
How small should a first FDE project be?
Small enough to show a working result on real data within a few weeks, and important enough that people will notice when it works.
Do I need a detailed specification?
No. You need a clear problem, a way to measure success and access to the people and data. The engineer turns that into a specification as they learn.
What happens after the first project?
Usually one of three things: the solution is handed over to your team, the engagement expands to the next problem, or the engineer stays on to run and improve what was built.
Need an engineer inside your team?
Tell us the problem. We'll tell you honestly what fits.