I recently analyzed an enterprise AI workflow project. The client wanted two weeks on site to diagnose workflows, design data structures, build AI workflows and brand memory, validate historical projects and prepare for a company-wide AI OS.
The proposal looked complete: tasks, schedule, deliverables and acceptance criteria. Yet it felt difficult to begin. Initially I thought tasks needed finer decomposition, then realized that several goals had been combined without resolving their tradeoffs.
FDE value extends beyond understanding the business quickly and building workflows. Before execution, it helps clients decide which problem is most worth solving and what this stage should validate.
These are nine lessons from that discussion.
First, identify what the project is meant to validate
A proposal can contain three different goals:
- Technical feasibility or PoC: can AI organize requirements, generate strategies, assess candidates and connect systems?
- Business value: are users faster or more accurate, is rework lower, and will they keep using it?
- Long-term foundations: shared data structures and IDs, permissions, state transitions, knowledge and future AI OS expansion.
All are reasonable, but require different deliverables, technology and acceptance. Before decomposing features, ask:
Which uncertainty does the client most want removed by the end of this stage?
Limited time requires tradeoffs between short-term value and foundations
The two can connect strategically but compete for the same resources in a two-week project.
If short-term value comes first, narrow the scope to one time-consuming, rework-heavy workflow and build something employees can actually use. Invest in live trials, experience, feedback and iteration.
If foundations come first, invest in processes, data models, IDs, boundaries, permissions and interfaces. Immediate impact may be less visible, but future systems gain clarity.
Trying to complete both can leave neither value validated nor architecture complete. FDEs help clients choose between reasonable but conflicting goals, not just limit scope.
A working process does not prove value
A demonstration using a historical case can establish that inputs produce outputs, but cannot establish employee adoption. Historical materials are relatively complete and results known; real work contains missing requirements, changing clients, inconsistent inputs, AI mistakes and unplanned exceptions.
Distinguish three levels:
- Technical operation: a result is generated.
- Business operation: the result broadly fits business logic.
- Actual use: employees use it in live projects and gain observable benefits.
Use historical projects for calibration, fixed samples for testing and real projects for value validation. If no live project is available, at least run a blind historical test using only information available at the time, not the full answer.
How employees use AI matters more than what it generates
Proposals may detail prompts, knowledge bases and workflows while leaving actual usage unclear. Where are materials submitted? Where are outputs viewed? How are errors corrected? Who confirms? How is the next participant notified? Must staff keep copying between systems?
Without answers, the design starts from AI capability rather than people's work. Good output will not sustain adoption if interaction costs exceed doing the task manually.
Map the human–AI collaboration: when people act, on which page, with which information and judgement, including exceptions.
Human correction is a core mechanism, not a temporary compromise
Early AI versions will omit, misunderstand or misjudge. Staff editing briefs, recommendation reasons and evaluations does not itself indicate failure. What matters is whether those corrections are retained and used.
Record at least:
- Original business inputs
- Original AI outputs
- Human-confirmed final versions
- Differences and reasons for changes
- Operator and reviewer
- Prompt or workflow version
- Final client acceptance, rejection or adjustment
Without this, teams cannot locate recurring errors or verify improvement. Human in the loop means making judgement recordable, analyzable and useful for future optimization, not merely adding a confirmation button.
Brand memory is a feedback loop, not a summary
Summarizing client preferences does not establish a usable memory mechanism. Each memory needs its project and feedback source, whether it is temporary or stable, applicable product line, price segment and market, confirmer, expiration conditions, retrieval conditions and evidence of usefulness.
The loop is:
Client feedback → AI extraction → employee correction → lead confirmation → memory update → similar-project retrieval → revalidation.
Without provenance, confirmation and retrieval mechanisms, memory risks becoming another uncontrolled AI hallucination.
Architecture should follow the validation objective
Choosing a multi-dimensional spreadsheet, Dify or a custom frontend and database should not depend only on build speed.
For rapid process validation, low-code tools allow quick field and workflow changes; replacement may be acceptable. For a lasting product, relationships, versions, feedback, permissions and analytics may justify a relational database and minimal business interface from the first phase.
Ask first:
Is this a disposable validation prototype or the first version of a long-term product?
Only then can we judge whether quick assembly saves time or creates migration costs.
FDE helps clients define the problem
Clients know their business better than outsiders but may not know what should be validated now. Immediate results, foundations, integrations and a future AI OS can all be reasonable goals that cannot fit the same short period.
FDE value is identifying the real problem, separating stated requests from goals, locating the largest uncertainty, designing minimal credible validation and explicitly excluding work that does not serve it.
Sometimes the professional answer is:
These goals conflict within the available time. We need to choose one first.
Feeling confused may signal a problem above execution
A detailed proposal that feels impossible to start may contain unprioritized goals or mix long-term vision, short-term delivery, architecture and acceptance.
Further decomposition creates more tasks without clearer direction. Step back and ask:
- Is there one central objective?
- Has the complete business process been mistaken for this phase's development scope?
- Has long-term vision been forced into the MVP?
- Are real users and usage defined?
- Which result would establish effectiveness?
My strongest lesson was:
Before goals align, careful decomposition can make a mistaken direction more complete.
An FDE kickoff checklist
Before features and technology, clarify the following.
Goals and value
- Why does the client want this now?
- Which step consumes the most time, causes rework or carries risk?
- Which uncertainty should this phase remove?
- Is this a PoC, business value validation or long-term system development?
- Which goal takes priority when they conflict?
Use and feedback
- Who actually uses the system?
- Through which entry points and pages?
- How are mistakes corrected and confirmed?
- How are edits and final client feedback retained?
- Who decides whether feedback becomes a rule or long-term memory?
Validation and acceptance
- Historical demonstration or live trial?
- Which metrics establish effectiveness?
- Who accepts the result, and are criteria objective enough?
- Which materials, accounts, permissions and feedback must the client provide?
- What is explicitly outside this phase?
Technology and evolution
- Disposable prototype or first lasting version?
- Does the technology match that objective?
- How will a successful prototype migrate or evolve?
- Can collected data support evaluation, improvement and automation?
- Who owns ongoing use, maintenance and iteration afterward?
A final thought
FDE is often seen as a broad engineer who quickly understands a business and delivers. Speed is not merely faster coding or workflow assembly. It includes defining the problem and prioritizing under uncertainty and time constraints.
Enterprise AI projects often fail because features, tools and schedules are chosen before anyone clarifies what is being validated.
The kickoff question may therefore be less “What can we build in two weeks?” and more:
What exactly do we want to establish by the end of those two weeks?
Thanks for reading.