There is a version of the identity engineering pitch that goes like this: define your software's identity, encode it in a declarative layer, and let agents build to that specification continuously.
A good VP of Product hears that and asks the obvious question: "What if the identity is wrong?"
It is the right question. A wrong identity, faithfully enforced by agents across every service and endpoint, will converge the entire system toward the wrong destination faster than any team of engineers could get there manually. The machinery works in both directions.
This is not a flaw in identity engineering. It is the central design constraint. Understanding it correctly changes who matters most in an engineering organization.
Discovery is how you figure out what to build. Identity is how you remember what you learned.
Marty Cagan and the Silicon Valley Product Group have spent two decades on a core principle: product teams must perform discovery and delivery continuously, in parallel, as two inseparable activities. Teresa Torres refined this into a practical framework in Continuous Discovery Habits -- weekly customer touchpoints, opportunity solution trees, assumption testing before building. The discipline is clear. You do not stop discovering. Ever.
Identity engineering does not compete with any of that. It operates in a different part of the workflow.
Discovery answers: What should we build? For whom? Why does it matter? Those answers come from user interviews, market analysis, experimentation, data, judgment. No identity layer produces those answers. No declarative specification replaces a PM sitting across from a customer and realizing the problem is different from what everyone assumed.
Identity engineering answers a different question: Now that we know, where do we write it down so the knowledge survives the meeting?
The identity layer captures the output of discovery, not the discovery itself. When a team learns through research that their payment service needs to support idempotency guarantees for a new class of merchant, that insight came from discovery. When they encode "this service guarantees idempotency on all endpoints" as a behavioral contract in the identity layer, that's identity engineering. The learning is human. The persistence is structural.
Without the identity layer, the learning lives in a Confluence page that three people read, a Slack thread that scrolls off-screen in a week, and the memory of whoever was in the room. Six months later, a new engineer (or an agent) builds an endpoint that violates the guarantee because nobody told them it existed. The discovery was excellent. The encoding was absent.
The strongest product teams already do this implicitly
Look at how Stripe maintained product coherence as it scaled. Blake Samic, who led Product Operations at both Stripe and Uber, described the challenge: shipping more products in parallel with more employees meant more decisions flowing through more channels, with no standardized way to capture what was decided and why. Stripe's response was to make implicit culture explicit -- encoding operating principles, building centralized coordination systems, measuring everything about their development process.
They did not stop doing product discovery. They built infrastructure to make the output of discovery persistent and propagable. That's identity engineering by another name.
Spotify's squad model is the cautionary tale of what happens without that infrastructure. Autonomy was high. Discovery happened in every squad. But the alignment mechanisms, the systems for encoding what was learned so that squads building adjacent products could stay coherent, were never completed. Jeremiah Lee, a former Spotify engineer, documented how the model's documentation focused on autonomy while the planned sections on alignment and accountability were never written. Each squad discovered independently and built independently. The product drifted in multiple directions at once.
Discovery without encoding is insight that evaporates. Encoding without discovery is dogma. You need both.
A pivot is an identity mutation
This is where the VP of Product's concern gets most precise. Pivots happen. Markets shift. Customer needs change. A startup that raised on one thesis discovers through rigorous discovery that the thesis is wrong. They need to change direction. Fast.
Does an identity layer make that harder?
The current alternative suggests it shouldn't be hard, because there is nothing formal to change. You pivot by announcing the new direction in an all-hands, updating some Jira epics, and hoping the org follows. No formal layer means no friction.
But "no friction" is not what actually happens. What happens is uneven propagation. The backend team gets the memo and starts building for the new direction. The mobile team is mid-sprint on a feature designed for the old direction and finishes it anyway because they're already committed. The data team never hears about the pivot because nobody thought to tell them. The API contracts still reflect the old model. Three months later, the system is a chimera: half old identity, half new, with seams that nobody can see because the pivot was never declared, only discussed.
Research on startup pivots shows that successful startups pivot one to three times before finding product-market fit. The ones that succeed pivot decisively -- with clear signal, fast propagation, and shared understanding of what changed. The ones that fail pivot partially, where half the organization is still building for the old reality.
An identity layer makes a pivot explicit. You change the identity (the declared purpose, constraints, and contracts) and the change produces a diff. Everyone can see what shifted. Agents can show you exactly what downstream code, services, and contracts are affected. Instead of filing tickets across six teams and hoping everyone interprets the new direction the same way, you commit the new identity and the system tells you what needs to change.
The pivot becomes an identity mutation, reviewed and committed with full awareness of the consequences. Version-controlled. If the new direction turns out to be wrong too, you can see exactly when the change was made and what it affected. Try doing that with a Slack announcement.
Speed of iteration goes up, not down
The intuition that formalization slows things down comes from decades of heavyweight specification processes. Waterfall. Big Design Up Front. Architecture review boards that meet monthly. Product leaders have good reason to be skeptical of bureaucracy between learning and building.
Identity engineering is not that. The identity layer is not a 200-page requirements document. It's a set of concise, declarative statements (purpose, contracts, constraints) that agents read before generating code. Changing it is a commit, not a committee.
Consider a concrete example. A VP of Product decides the platform needs to pivot from serving SMBs to serving enterprise customers.
In the current model: weeks of meetings. Tickets created across every team. Each team interprets "enterprise" differently. The security team thinks it means SOC 2. The sales team thinks it means annual contracts. The engineering team thinks it means multi-tenancy. The PM spends the next quarter aligning interpretations that were never formally declared.
With an identity layer: the product leader updates the declared purpose and constraints. "This platform serves enterprise customers. All data handling must satisfy SOC 2 Type II. Multi-tenant isolation is a hard constraint." Agents read the new identity and surface the delta: every service, endpoint, and contract that conflicts with the new direction. The PM sees a concrete list of what needs to change, not an abstract mandate to "go enterprise."
The second version is faster because it replaces ambiguous communication with explicit declaration. The discovery -- the decision that enterprise is the right market -- is still entirely human. The propagation is structural.
The hardest job in the building
If the identity layer is what agents read, and agents build faithfully to what they read, then the people writing the identity layer carry the highest-leverage responsibility in the organization.
Get it right, and every agent in the system builds coherently toward the correct destination. Get it wrong, and every agent builds coherently toward the wrong one. There is no safety net of slow execution to catch a bad identity. The agents will execute it as written, quickly and thoroughly.
This is "garbage in, garbage out" at organizational scale. The humans doing product discovery (the PMs, the researchers, the product leaders running experiments and talking to customers every week) are not less important in an identity-engineered world. They are more important. Their work is the input to a system that amplifies whatever it receives.
Without identity engineering, a wrong product direction causes damage slowly. Implementation friction, differing interpretations, and natural pushback create speed bumps. The wrongness gets diffused by the inefficiency of human communication.
With identity engineering, the buffer is gone. A wrong direction propagates at the speed of agent execution. The only protection is getting the identity right -- through rigorous, continuous, evidence-based discovery of the kind that Cagan, Torres, and every serious product thinker has been advocating for years.
Your job just got harder. That is the compliment.
If you are a VP of Product reading this and feeling uneasy, that unease is correct. Identity engineering raises the stakes of your work. The decisions your team makes about what the software should be -- who it serves, what it promises, what it refuses to become -- will propagate further and faster than they ever have before.
That is not an argument against identity engineering. It is an argument for investing more in the discovery capability that feeds it. More customer research. More experimentation. More rigorous validation before a direction gets encoded. The identity layer does not replace product judgment. It makes product judgment the load-bearing wall.
The alternative (no identity layer, decisions scattered across Slack threads and stale documents, agents guessing at intent from whatever context they can scrape) does not protect you from wrong decisions. It just makes the damage slower and harder to see.
An identity layer makes the product direction legible, versionable, and debatable. You can argue about it before it ships. You can see when it changes. You can hold it up and ask, "Is this what we learned? Is this what the evidence says?"
The agents are going to build something. The question is whether they build toward an identity that your best product minds defined and validated, or toward whatever ambient context happens to be lying around in the codebase. Product discovery tells you where to go. Identity engineering makes sure you actually get there. Neither works without the other.