Product Strategy

The agent is instructed to run autonomously, completing all tasks it can handle without human intervention. It also checks working hours to prevent calling outside designated times.

When the agent reaches a critical decision point (e.g., Lead on Value vs. Lead on Price), it triggers an escalation, presenting structured options and recommendations rather than asking for generic input.

Following the human decision (e.g., 'Lead on Value'), the agent automatically logs the approved decision and creates a follow-up task (e.g., 'follow up in 7 days') directly into the project files, ensuring decisions are never lost within transcripts.

The Level 1 builder is intensely passionate about a specific idea, viewing it as their entire world. They focus solely on the product concept without considering go-to-market strategy or the wider problem space. This stage often leads to discouragement when faced with new AI model launches.

The Level 2 builder retains passion but gains openness by interacting with customers. They are able to adjust their idea based on feedback from multiple users (e.g., talking to 10 different customers), leading to profitable side gigs without needing a broad market thesis.

At Level 3, the builder understands that distribution and telling a story are critical. The unique AI element is realizing that AI can supercharge these go-to-market efforts (e.g., using custom messaging on LinkedIn, Twilio voice models, or HeyGen for storytelling).

The Level 4 builder has deeply marinated in a specific problem space and possesses a unique thesis on how to attack it. They must articulate an AI-based thesis that is disruptive, such as recognizing 'voice' as the next computing paradigm (e.g., WhisperFlow).

The Level 5 builder doesn't just use current AI; they deeply understand the trends and trajectory of AI within their domain. They build for capabilities (like longer-running agentic sessions or better tool calling) that are not yet possible, allowing them to be first to market.

The core insight of FDE is that it must function as an extension of the product team to identify areas for generalization. The goal is to define and solve the underlying problem, not just implement the requested solution.

When a customer presents a massive requirement (e.g., a custom BI tool), focus on solving the most immediate, trivial problem first (like a Slack alert). This builds trust and allows the product team to gain ownership of the solution narrative.

The most valuable intelligence is found by observing user behavior (e.g., repetitive tasks, copying/pasting between tools, or using a phone during workflow). These actions indicate missing features or bugs that documentation will never reveal.

FDE must define the domain's terminology (the ontology) to standardize ambiguous terms. By canonicalizing nouns (entities, e.g., 'clients') and verbs (operations), the engineer controls the language that the entire system is built upon.