Product Literacy Is the New Core Engineering Skill

Product Literacy Is the New Core Engineering Skill

Originally published at tddbuddy.com. This is the third and final post in the "Vocabulary Is the Product" arc. The first, The Hidden Output of TDD Was Never Code, made the case that naming was always TDD's primary artifact. The second, Agents Amplify Whatever Vocabulary They Find, showed how agents compound both good and bad vocabulary at machine speed. This post names what that means for engineering roles and what teams should do about it.

Product literacy is the engineering skill that didn't get automated, and most teams aren't hiring for it yet.

Product Literacy Was Always the Leaky Part

Every engineering organization in the last thirty years ran on a shared fiction: the translation problem could be divided cleanly. Product translated business reality into specifications. Engineering translated specifications into code. The division looked clean on the org chart.

In practice, the engineers who understood the business shipped materially better software than the engineers who didn't. Not marginally better. Structurally, measurably, unmistakably better. The concepts they chose for their domain models fit the problem. Their names survived beyond the next sprint. Their abstractions bent in the right directions when requirements changed.

Everyone knew this. Nobody made it a hiring criterion.

The leakage was tolerated because the translation-to-syntax problem was hard. If an engineer was fluent in whatever the stack happened to be, and capable of turning a spec into working code in a reasonable time, that was enough signal. The understanding-the-business part was treated as a bonus. You hired for syntax, and if the hire happened to also understand the domain, that was a pleasant surprise worth celebrating at the retrospective but not something to screen for on the way in.

The whole arrangement was a reasonable tradeoff for an era when writing correct code was genuinely difficult. Not everyone could do it. The people who could were expensive and scarce. You didn't filter out the ones who understood the business, but you didn't filter for them either. Syntax fluency was the bottleneck. Product literacy was the rounding error.

That era is over.

The Boundary Just Collapsed

Agents translate spec-shaped intent into syntax. Not slowly, not imperfectly, not only for simple problems. They do it for the whole range of implementation work that used to consume most of an engineering team's calendar.

This is not a claim about the future. It is an observation about now. Teams using disciplined agentic workflows are implementing features from a well-formed prompt. The prompt, not the code, is the primary authoring act. The agent handles the translation to syntax. The engineer handles the translation from business reality to correctly-stated intent.

Which means the boundary between product and engineering didn't move. It collapsed.

The engineer who can take a business concept and turn it into a correctly-named, correctly-shaped specification has a full day of valuable work. The agent executes against that specification. Tests get written. Code gets generated. The implementation fits the domain because the specification said what the domain actually needed.

The engineer who cannot do that has a different problem. The agent doesn't need a human to translate a correct spec into syntax. It's already doing that. What it cannot do is decide what the spec should say, or whether the concept being specified is the right concept, or whether the name the PM proposed maps cleanly onto something that already exists in the system under a different label.

That judgment is the job. Not a nice-to-have adjacent to the job. The job.

Engineers who can operate in business reality are the ones writing the spec-shaped intent in the first place. Engineers who can't are watching an agent do the only translation they were reliably good at.

The uncomfortable corollary: the engineer who spent ten years becoming fluent in a framework and not much else now has a narrow value proposition in a world where frameworks are cheap to use but domain understanding remains expensive to develop.

Product Literacy Is Not "Knows the Roadmap"

There is a version of product literacy that engineering organizations already recognize: the engineer who reads the quarterly OKRs, attends the roadmap review, and can speak to business priorities in a leadership meeting. That version is real. It is not the version that matters here.

Product literacy, in the sense that now constitutes core engineering skill, is something narrower and harder than roadmap awareness. It means:

• Being able to name a new domain concept in a way the business will recognize five years from now. Names that survive are load-bearing. A concept named well at inception becomes the stable anchor around which future requirements accrete. A concept named poorly is a debt that compounds: every new feature touches it, every new engineer learns the wrong word, every agent generation produces code in a vocabulary that doesn't match the rest of the system.

• Being able to recognize when a PM's proposed framing is hiding an unnamed concept. The proposal sounds like a new feature. A product-literate engineer reads it and notices that the vocabulary is ambiguous, that two different business concepts are being collapsed into one ticket, and that shipping the ticket as described will produce a domain model that won't survive the next quarter's requirements.

• Being able to refuse a feature whose vocabulary doesn't fit the existing model, with a clear explanation of why the fit is wrong and what the right question is. Not as a gatekeeping move. As a design act. The refusal is a design contribution.

• Being able to pull a meeting back to the naming question when the meeting has drifted into implementation detail. "Before we talk about how to build this, what do we actually call this thing?" That question is often the most valuable engineering contribution in a sprint, and it is almost never on the agenda.

None of these skills appear on a resume. None of them are screened for in a standard interview loop. They are the skills that didn't get automated.

The Engineer as Lexicographer

The most valuable hour of a senior engineer's week is often spent in a shared document with a product manager, naming a concept correctly before anyone has written a test.

That framing will feel strange. Engineers are supposed to be in the code. The value is in the implementation. The naming is what happens on the way to the implementation.

This is exactly wrong. The name is upstream of everything. The test that gets written, the code the agent generates, the PR that gets reviewed, the model that future engineers extend: all of it descends from the name chosen in that document. Get the name right and everything downstream benefits. Get it wrong and everything downstream inherits the error, and the error compounds with each generation.

Consider what happens when a team treats naming as a casual decision, made quickly, adjusted later if necessary. The domain vocabulary fragments. Words that should be synonyms aren't recognized as such. Words that should be distinct are conflated. Concepts that have a natural relationship in the business domain are orphaned in the codebase because the names don't reflect the relationship. An agent working in this vocabulary recombines what it finds. It produces code that reads like the codebase, because it samples the codebase. The fragmentation propagates, faster than any human team could produce it.

Compare that to a team that treats naming as a design review. A new concept gets a naming session before it gets a ticket. The result of that session is written down. The written-down name becomes the test name, the class name, the prompt vocabulary, the PR review vocabulary. The agent recombines a coherent vocabulary and produces coherent output. The codebase grows without fragmenting.

The difference between these two teams, after one year of agentic development, is not a tooling difference or a process difference. It is a vocabulary difference. One team has a domain model that fits the business. The other has a domain model that accumulated under machine-speed drift.

The engineer as lexicographer is not a metaphor. It is a job description for the part of engineering that agents cannot absorb. The lexicographer's output is the glossary entry written before any ticket opens, the naming review in the design doc, the vocabulary decision documented alongside the architectural decision. That work is invisible in every velocity metric and central to every outcome that matters.

The Warehouse Credit Case Study

Concrete example. A PM proposes a feature called "warehouse credit." The framing: when a returned item goes back to the warehouse, the warehouse should receive a credit that can be applied against future invoices. The PM has named this concept, proposed a data model (a WarehouseCredit entity with amount, date, and warehouse ID), and estimated it at a few days of work.

An engineering team without product literacy opens a ticket, generates a WarehouseCredit model, writes the persistence layer, wires up the API endpoint, and ships. Here is what that implementation looks like before any tests catch the drift:

// New model introduced to satisfy the "warehouse credit" feature
public class WarehouseCredit
{
    public Guid Id { get; set; }
    public Guid WarehouseId { get; set; }
    public Money Amount { get; set; }
    public DateTimeOffset CreditedAt { get; set; }
    public string Reason { get; set; }
}

Six months later the team is maintaining two parallel models: WarehouseCredit and the existing InventoryAdjustment (an event already modeled in the system that fires whenever returned stock is re-shelved, captures the warehouse, the quantity, and the restocking value). They aren't the same entity, exactly. But they represent the same business moment. Every returned item generates both. The reconciliation logic between them grows quarterly. Reporting across them is a multi-join nightmare. New engineers ask why there are two and get answers that amount to "historical reasons."

A product-literate engineer in the original meeting asks a different question: "When you say warehouse credit, what moment in the business process are you naming?" The PM explains: a return gets processed, the item goes back to the shelf, the warehouse gets financial recognition for receiving the inventory.

The engineer recognizes this. The system already has a ReturnStockedEvent. The financial recognition is a policy applied to that event. The "feature" isn't a new concept. It's a new policy on an existing concept, and the existing concept already has a name the warehouse operations team uses: return-to-stock.

The implementation becomes:

// No new model. The existing event drives the new policy.
public class WarehouseCreditPolicy : IHandles<ReturnStockedEvent>
{
    public void Handle(ReturnStockedEvent evt)
    {
        var credit = evt.RestockValue;
        _ledger.ApplyCredit(evt.WarehouseId, credit, evt.OccurredAt);
    }
}

One class. One handler. No new entity. No parallel model. The vocabulary already existed in the system. The "feature" was already modeled. The only question was whether anyone recognized it.

That recognition is product literacy. It is also the difference between a week of clean implementation and a year of reconciliation debt.

Now consider the same story at scale, across a full quarter of explicit lexicographer work. A team that pairs engineers with product on every new concept before any tickets are written produces a domain glossary that looks qualitatively different at the end of the quarter than it did at the start.

Before:

• "credit" used in four different contexts with four different meanings
• "adjustment" overloaded across inventory, pricing, and accounting
• "warehouse event" (an informal term with no code equivalent)
• "return credit" and "warehouse credit" proposed separately and never unified
• "restock" and "return-to-stock" as two names for the same event

After:

• "credit" scoped to the accounting context only
• InventoryAdjustment renamed to StockAdjustment across the codebase
• ReturnStockedEvent as the canonical event for any return-to-stock moment
• WarehouseCredit retired before it ever shipped, recognized as a duplicate
• "restock" deleted from the vocabulary; "return-to-stock" promoted as the domain term

Concepts deleted: 3. Concepts renamed: 2. Concepts unified: 1. New concepts added: 0.

That is a successful quarter of lexicographer work. No new features shipped by that vocabulary effort. Every future feature shipped more cheaply because the vocabulary was tighter. Every agent generation against that codebase produced less drift. Every PR review spent fewer cycles on naming questions, because the naming questions were already answered upstream.

The BDD movement promised cross-functional shared language as an outcome of three-amigos sessions and Gherkin files. The promise was right. The implementation was a coordination overhead that most teams eventually stopped paying. What makes the outcome non-negotiable now is not a new process artifact. It is engineers who know how to do this work directly, in a naming session or a design doc, without a ceremony wrapper around it.

Hiring Hasn't Caught Up

Engineering interview loops are almost uniformly calibrated for a world where syntax was the bottleneck.

• Leetcode-style algorithm questions screen for a kind of abstract reasoning that correlates weakly with domain modeling skill.
• Framework recall and system design interviews screen for familiarity with known patterns applied to canonical infrastructure problems.
• Code review exercises screen for identifying bugs in code that has already been written.
• Pair programming exercises screen for fluency in a language and a problem type that typically has nothing to do with the business the candidate would actually be working in.

None of these screens ask: can this person recognize that a proposed feature is already modeled under a different name? Can they sit in a room with a PM and name a concept that will survive three years of agentic development? Can they refuse a feature because its vocabulary doesn't fit, and explain why in terms the business understands?

Those questions are not being asked. They are the only questions that matter.