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.

It means 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.

It means 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.

It means 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 candidate recognize when a business concept doesn't have a name yet? Can they name it clearly and correctly? Can they tell when a PM's proposed vocabulary is going to cause a domain model to fork? Can they sit in a discovery conversation and pull it toward naming before anyone has opened an IDE?

The signal is rarely looked for. When teams do see it, they often mislabel it: the candidate "had good communication skills" or "asked interesting questions in the debrief." The deeper thing being observed is product literacy. It didn't have a label in the interview rubric, so it didn't accumulate as a criterion across hiring cycles.

The teams that fix this will run a different kind of exercise: give candidates an underdefined business problem and watch how they name it. Not how they implement it. How they name it. Do they ask clarifying questions about vocabulary before reaching for a class diagram? Do they notice when two proposed concepts are actually the same thing? Do they resist premature implementation until the naming is stable? Do they produce a glossary as a natural first artifact, treating it as load-bearing rather than decorative?

That is the interview for the skill that matters now.

Most teams have not built it. The bar they hire to is the bar from the previous era. The candidates they select for are skilled at exactly the translation that agents now handle.

What Teams Should Do Now

The adjustment is not complicated. It does require a deliberate choice to redirect attention.

Rotate engineers into PM-adjacent work before the tickets are written, not as observers but as active participants in concept formation. An engineer in the discovery conversation, before the ticket exists, can ask the naming question at the moment when it costs the least to answer it. After the ticket is written, the naming question is a change request. Before it is written, it is just good design. The cost difference is not marginal.

Treat naming decisions as design reviews. The same culture that requires a review before a new database schema is introduced should require a review before a new domain concept is named. Both are structural decisions. Both compound in the wrong direction if they're wrong. One gets reviewed as a matter of standard process; the other gets decided in a ticket title between one standup and the next.

Pair product managers with engineers on builder API design. The test builder vocabulary (the aWarehouse(), the aReturn().withValue(), the anOrder().pending()) is the domain vocabulary made executable. When product managers participate in shaping that vocabulary, the builders reflect the language the business actually uses, and agents generating tests against those builders produce output that product managers can read without a translation step. The feedback loop closes. Vocabulary drift becomes visible as soon as it introduces friction in a conversation, rather than only after it produces reconciliation debt in the schema.

Run vocabulary kata sessions. The kata format from Katas Are Rehearsal applies here without modification: controlled exercise, known scope, deliberate reps. Give a team an underdefined business scenario. Their task is not to implement it. Their task is to name every concept in it, clarify which concepts are distinct and which are the same thing under different labels, and produce a glossary entry for each new term. Then do it again next week with a different scenario. The rep-building is the same logic as the TDD kata: the skill is not knowing how but being fast enough and practiced enough that the naming question is asked before the implementation decision is made. Naming under pressure, during a discovery call, while a PM is describing an urgent requirement, is a skill that decays without practice.

None of this adds process. It is a reorientation of where engineering judgment gets applied. The implementation is now cheaper to produce. The specification is now more expensive to get wrong. The investment should follow the cost.

Naming Was Always the Job

The job was always naming the domain correctly. The code was the side effect.

This is uncomfortable for an industry that spent decades measuring output in lines of code, in tickets closed, in features shipped. All of those metrics were proxies for something real: the software does what the business needs. The thing being measured was the artifact. The thing that mattered was whether the artifact was correctly named, so it could be extended, corrected, and understood by the next engineer, the next agent, and the next business requirement.

Agents made the side effect free. Or close enough to free that the cost no longer drives the decision. What remains expensive is the judgment about what to make and what to call it. That judgment was always the actual work. For thirty years it was obscured by the cost of the translation to syntax that followed it.

The BDD movement's sharpest insight was that shared vocabulary between business and engineering is not a soft benefit. It is a structural requirement. The movement wrapped that insight in a coordination ceremony that most teams couldn't sustain, and the ceremony got dropped while the insight got buried with it. The outcome BDD was pointing at (everyone using the same words for the same concepts, across product and engineering and the test suite) is now non-negotiable, not because a new framework mandates it, but because agents amplify vocabulary drift at a speed that makes the structural damage immediately and visibly expensive.

The bar for TDD moved when agents became the implementation vehicle. The bar for engineering judgment moves the same way, for the same reason, in the same direction. What gets harder is getting the name right before the agent generates against it. What gets cheaper is everything after that.

Product literacy is not adjacent to engineering. It is the part that didn't get automated. For the first time in the industry's history, the part that didn't get automated and the part that actually determines whether the software fits the business are the same part.

The job is now visible.

Product literacy is the new core engineering skill. The code was always the side effect.