FDE Mental Model

From customer request to deployable workflow.

A repeatable way to analyze ambiguous requirements: clarify the request, find the real workflow, set trust boundaries, and design the smallest safe deployment.

Read the framework Apply it to sample cases

Compact version

Request → Workflow → Trust → Deployment

Most customer requirements arrive as feature requests. The FDE job is to translate them into operational systems: who acts, what data moves, what risk exists, what can be automated safely, and what should be measured after launch.

01 Request

What did the customer ask for?

02 Workflow

What operational workflow is this really part of?

03 Trust

Where can AI act safely, and where does a human need to stay in control?

04 Deployment

What is the smallest version that can be shipped, used, measured, and expanded?

Detailed framework

Ten lenses for analyzing a requirement.

Each step turns a vague request into a more deployable decision: question the request, expose the workflow, define success, and protect the trust boundary.

01

Clarify the problem or request

Do not accept the requested feature as the real problem yet.

What job is the customer trying to get done?Who needs the result, and when do they act on it?How is this handled today, and where does it break?What would become faster, safer, or more consistent if this worked?
Surface

“Can AI summarize our sales calls?”

FDE translation

Sales reps need faster follow-ups, cleaner CRM records, and shared visibility into risks, objections, and next actions.

02

Find the real user and decision point

The requester, buyer, daily user, and reviewer may be different people.

Who requested this, and who will use it every day?Who reviews, approves, or rejects the output?What decision or customer action depends on this result?Who owns the workflow after the first deployment?
Surface

Requester: VP of Sales

FDE translation

Users: account executives and sales managers. Decision points: follow-up email, CRM update, pipeline risk review.

03

Map the current workflow

Before inserting AI, understand the path that data and decisions already take.

Where does the input come from?Which tools are already in the loop?Where do humans add judgment?Where do delays, omissions, or errors happen repeatedly?
Surface

Call → notes → follow-up → CRM update → manager review

FDE translation

The bottleneck is not one missing summary. It is a fragile handoff chain after every customer conversation.

04

Separate the stated request from the underlying need

Translate the feature request into the operational improvement it is pointing at.

What did they literally ask for?What business outcome are they probably trying to improve?What risk appears if we implement the request too literally?What workflow should the solution improve instead?
Surface

They asked for: AI-generated call summaries.

FDE translation

They probably need: a reviewed workflow that turns messy call data into next actions, CRM-ready notes, and sales signals.

05

Define success criteria before solution

A generated output is not success. Changed behavior in the workflow is success.

How will we know the deployment is useful?Is the goal speed, accuracy, adoption, compliance, revenue, or visibility?Who judges quality?What metric proves this is worth expanding?
Surface

Weak metric: “The AI creates a summary.”

FDE translation

Better metric: reps review in under 2 minutes; next actions include owner and due date; CRM notes update within 1 hour.

06

Classify risk and trust boundaries

Decide where AI can draft, where rules should validate, and where humans stay in control.

What is low-risk suggestion work?What touches customer-visible or business-critical records?What requires approval before writeback?What failure mode is most expensive?
Surface

Low risk: draft and summarize. Medium risk: internal writeback after approval. High risk: customer-facing commitments.

FDE translation

Start with a review workflow before automating CRM updates or customer messages.

07

Design the smallest safe workflow

The MVP is not a feature list. It is a tiny workflow that can be used, reviewed, and measured.

What is the smallest useful input?What output saves real work immediately?Who reviews it, and how long should review take?Where does the approved result go?
Surface

MVP shape: one transcript in → structured draft out → rep reviews → CRM-ready note.

FDE translation

Keep the first deployment boring, bounded, and safe enough for real users to trust.

08

Propose architecture around the workflow

Architecture follows the workflow: inputs, processing, validation, review, integration, feedback.

What data is needed, and what can be optional?Where are deterministic rules better than model calls?What needs logging, auditability, or rollback?How will user feedback improve the next version?
Surface

Ingest transcript → extract fields → validate → review UI → approved writeback → feedback log.

FDE translation

The FDE answer is not just “use an LLM.” It is a deployable system around the LLM.

09

Explain tradeoffs in customer language

Make the technical choice understandable without hiding constraints.

Why start with review instead of full automation?What risk does this architecture reduce?What does the customer gain immediately?What will become automatable later if trust improves?
Surface

“We will not auto-write to CRM on day one.”

FDE translation

“Your reps stay in control while the system removes repetitive first-draft work and teaches us what can be safely automated next.”

10

Define the expansion path

Show how the first safe deployment can grow into a more automated operating system.

What comes after the first workflow is trusted?Which parts can move from draft to approval to automation?What new dashboard, alert, or integration becomes possible?What feedback loop keeps the system improving?
Surface

Phase 1: reviewed summaries. Phase 2: CRM fields. Phase 3: manager dashboard. Phase 4: suggested follow-ups.

FDE translation

Expand automation only where the workflow proves value and earns trust.

How to use this in a case

Show judgment, not just implementation ability.

For every sample case, the page should make the thinking visible: the customer asked for X, but the workflow needs Y; the safe MVP is Z; this is where humans review; this is how we know it worked.

Case page sections

Customer request → real workflow → key questions → trust boundary → MVP → architecture → success criteria → expansion path.

Good default answer

Do not jump to full automation. Start with a draft, review, validation, and measurement loop. Then expand where trust is earned.

FDE signal

The strongest signal is not using AI. It is knowing where AI belongs inside a messy customer operation.