5 Product intent: Reverse-engineer the PRD
This chapter shows how to recover a product’s true intent from source code instead of relying on implementation details or marketing copy. The core warning is that experts can become so fluent in the schema, routes, and tech stack that they stop seeing the user’s actual problem, while the code itself still records the product decisions the team really made. By asking the right AI prompts, you can reconstruct a product brief from the repository: the pain it solves, the one-sentence pitch, the competitive bet it makes, and the features or absences that reveal where the team is headed.
The chapter’s main technique is to translate code into product language. It encourages describing the problem as a concrete scene before it becomes a feature list, then compressing the product into an “It’s X, but Y” sentence that names both the familiar category and the key difference. It also frames every codebase as something built for a specific customer with a specific rival, whether that customer is a consumer, a business owner, a developer, or an enterprise buyer. That lens helps you spot where the intent is hidden in a web app, library, CLI, or data tool, and it makes positioning visible as the single trade-off competitors cannot easily copy.
Using Cal.com as the running example, the chapter shows how code reveals a strategy built around white-label embedding, developer-first integration, and counter-positioning against branded competitors. The repository suggests a business aimed not at solo schedulers but at companies that want scheduling to disappear inside their own products, even if that means giving up viral growth loops. The same method uncovers hidden bets like AI phone-calling for follow-up, and strategic omissions like refusing to build video calling or comments when those would pull the product away from its core focus. In short, the codebase functions like a product roadmap written in decisions, constraints, and deliberate sacrifices.
The single-page product story for Cal.com, generated from a prompt run against the source code, covering the pain scene, the variant sentence, a competitive analysis table, code-derived surprises, and deliberate absences.
The Curse of Knowledge: the engineer sees code that "checks if two date ranges overlap," while the user feels the relief of turning a mess of sticky notes and nine emails into a single click.
You open a web app, import a library, run a CLI, or pipe data through a tool. Each interface reveals the specific customer the codebase is built to win.
A vague pitch like "We transform the relationship between individuals and information" conveys nothing, while a concrete one-liner like "Calendly, but open-source and embeddable" lets you picture the product immediately.
An end-user (left) cares about the surface: a clean UI, a fast page, one-tap checkout. A developer (right) cares about the plumbing: a clean API, SDKs, and reliable webhooks. A product is built for whoever pays, so the part of the codebase with the most complexity reveals the true customer.
Cal.com and Calendly as two icebergs, each with a different product strategy. Cal.com has a small visible tip (a booking link) supported by a large, deep base of developer features: an embed system, a platform API, white-label branding, and an OAuth layer. Calendly's iceberg is the reverse: a large, branded surface with a much smaller platform underneath.
The four competitive moats, or reasons a rival can't catch up: switching costs (leaving costs too much), network effects (each new user adds value), brand (a trusted name), and counter-positioning (copying you would break the rival, just as matching a "free" price would drain an incumbent's revenue). Cal.com combines counter-positioning with switching costs, and the moats a product holds predict where it invests next.
The marketing pitch is "just a scheduling tool," but the code reveals three features the company doesn't advertise: an AI agent that phones customers to confirm meetings (the Agent model), routing logic that sends each booking to the right team member (the RoutingForm), and white-label theming that re-skins the app for each customer (the brandColor field). The real strategy is in the code, not the marketing copy.
Summary
- The Curse of Knowledge makes it harder for senior engineers to see the product as a user does. The more fluent you are with code, the more you see the database schema instead of the user's problem, like their scheduling anxiety disappearing.
- A feature list is an inventory of what a product does, not an explanation of why it exists. The user's pain provides the "why." Cal.com's real competition isn't Calendly; it's the four-day email chain that starts with "let me check my calendar."
- A good product description passes Paul Graham's "reproduce-it" test: after reading one sentence, is someone closer to building a copy? "It's Calendly, but open-source infrastructure for embedding" passes the test. "A scheduling platform leveraging modern technologies" does not.
- Counter-positioning means refusing to do something a larger rival can't afford to stop doing. By saying "no" to building a consumer brand, Cal.com can build a deep embedding system that Calendly can't copy without destroying its own viral growth model.
- The code reveals a company's strategy long before the marketing team does. These bets are not in a roadmap; they are in the implementation. Cal.com has an unadvertised AI phone agent. Ghost treats blog posts and emails as the same database object. Plausible deletes your identifying data every 24 hours.
Crack Any Codebase with AI ebook for free
