The FDAE Mindset: Ship First, Refine Later

How to work effectively under customer-site time pressure, handle incomplete data and unclear requirements, and measure success by adoption rather than technical elegance.

The Time Problem

When you build a product for anonymous users, you can iterate for months before anything ships. A slow iteration that ships a better product is usually the right call. The FDAE works under a different constraint: the customer has set aside a finite block of time - two days, two weeks, four weeks - and has organized their team, their calendar, and their expectations around a deliverable at the end of it. That deadline is not a project deadline. It is a trust deadline. If you arrive at the end of an engagement with nothing working, you have not delivered late. You have destroyed the relationship.

This makes speed a first-order value for FDAEs in a way it is not for most engineers. But it is not speed at the expense of working software - it is speed through deliberate simplification. The FDAE mindset is: what is the smallest working thing that demonstrates real value? Build that first. Refinement follows, but only if the core works.

Working With Incomplete Data

Product engineers typically work with datasets they have already validated, structured, and understood. FDAEs work with data as they find it: inconsistently formatted exports, undocumented spreadsheets, databases with column names like “field_77”, and systems that require a senior employee to run a manual report. This is normal. Expecting clean data before you start building is a form of scope creep disguised as rigor.

The practical approach: assume the data is messy and build cleaning into the prototype. A sample of 50-100 rows is usually enough to understand the shape of the problem and build a working first version. You can improve data handling iteratively once the core value is proven. What you cannot do is pause the engagement while waiting for a clean export that may never arrive.

The Unclear Requirements Problem

Product teams have product managers. FDAEs are often their own product managers. Customers rarely come with precise specifications - they come with descriptions of pain: “our team spends three hours a day summarizing customer feedback” or “we can never find the right clause in these contracts.” These are discovery signals, not requirements. The FDAE’s job is to convert the pain description into a buildable specification within the first day of the engagement.

The best technique is the “show me once” exercise: ask the stakeholder to walk you through one complete example of the painful workflow right now, while you watch. Not described in theory - actually done, with real data, in front of you. Thirty minutes of watching the real workflow is worth three hours of requirements meetings. You will see exactly where AI can intervene, what inputs it will receive, and what “good output” looks like to the person doing the work.

Measuring Success by Adoption

The product engineering definition of success is technical: does the system work correctly? The FDAE definition of success is behavioral: do people actually use it? These are related but not the same. A technically correct system that requires three workarounds and six clicks to invoke will not be used. A rougher system that slots naturally into an existing workflow will be used every day.

Design every system for adoption from the first prototype. This means: place the AI where the work already happens (the existing spreadsheet, the existing CRM, the existing chat tool), minimize the number of new interfaces users must learn, and make the first interaction produce a result fast enough to feel like magic rather than a tool that needs warming up.

The Prototype Quality Bar

FDAEs navigate a quality bar that is different from both startup “move fast and break things” culture and enterprise software rigidity. The right bar: