Twelve people. One login page.
You know the standup. Fourteen people on a Zoom call. The Product Manager, the Product Owner, the Business Analyst, the Scrum Master, the UX Researcher, the UX Designer, the UI Designer, the Tech Lead, the Front-End Developer, the Back-End Developer, the QA Engineer, and the Delivery Manager — all convened to discuss the sprint status of a form with four fields and a submit button.
Nobody mentions this is absurd. It's the process. The process is the point.
I've been in these rooms for sixteen years. And I noticed something: most of the conversation was about coordinating the people in the conversation. Status updates passed between people whose only job was to pass status updates. Translation layers between people who spoke the same language but had been assigned different role titles that required an intermediary.
The thing being built — the actual product, the user problem, the decision — appeared briefly, got obscured by process, and disappeared again into a backlog.
What a PM, PO, and BA actually contribute
I want to be fair here. These are not bad people doing pointless jobs. They were solving real problems. The question is whether those problems still exist.
The Product Manager was the bridge between business strategy and product execution. They learned the domain — who the customers were, what the market wanted, what the business needed. They translated that understanding into product direction. The critical word is “learned.” They were learning the domain. Often slower than the domain was changing. Often from two people removed from the actual users.
The Product Owner managed the backlog. They prioritised what got built and when, and they owned the relationship with the delivery team. In practice: they attended the ceremonies, they maintained the tickets, and they shielded the delivery team from stakeholder noise. They were a buffer. A very expensive buffer.
The Business Analyst documented requirements. They turned stakeholder wishes into specifications. They sat between the people who knew what the business needed and the people who could build it, and they wrote things down so the gap didn't swallow the project.
All three of these roles exist because of a translation problem. Business speaks one language. Engineering speaks another. Stakeholders say what they want, not what they need. The BA/PO/PM triad was a human middleware layer — translating, buffering, prioritising, coordinating.
The middleware problem was real. The human solution made sense before AI.
But here's the deeper problem: “learning the domain” isn't neutral. A PM's domain knowledge is already out of date by the time they've synthesised it. Worse, it can actively point in the wrong direction — shaped by last quarter's assumptions, last year's strategy, a competitive landscape that has already shifted. They're not just slow translators. They're translators working from an old dictionary.
And they are structurallyrisk-averse. PMs, POs, and BAs are constrained by roadmaps that were outdated before they were published, timelines set by people who've never built anything, and budgets allocated against assumptions that no longer hold. Their job incentivises them to protect the plan, not challenge it. They manage risk by avoiding it. That's not a character flaw — it's the job description.
When I NorthStar prototype with AI, I change the trajectory of a company. I don't learn the domain as it was — I explore what it could become. The prototype doesn't confirm the roadmap. It renders the roadmap obsolete by showing something better. That requires autonomy, risk tolerance, and adhocracy — the exact things the middleware layer is designed to suppress.
Now ask: what changes when I can learn a domain in three hours of deep research with Claude? What changes when I can write the requirements as a CLAUDE.md context file that any agent in the system can consume? What changes when the prototype I generate overnight is more persuasive than a BA's specification document, and more honest than a roadmap nobody believes?
The translation problem doesn't disappear. But the human translators become optional.
Three things I can't generate.
I've thought hard about this. And I keep arriving at the same answer. There are three things I cannot fabricate, synthesise, or prompt my way to. Three things that require a real human in the room with me.
Domain Knowledge
The clinician. The compliance officer. The warehouse manager at 3am. Experience that isn’t in any document and can’t be synthesised from public data. This is the raw material the system cannot generate.
Decision Authority
Someone whose yes is binding. Executives, board members, budget holders. Not approval in principle — approval that unlocks resources, removes blockers, and commits the organisation. Without this, I’m building on sand.
Lived Experience
The actual user. Not a report about them. Not a persona derived from them. Them — reacting to a prototype in real time, in the context they actually work in. Twenty minutes of this is worth six months of secondary research.
That's it. Domain knowledge, decision authority, lived experience.
Everyone else was middleware.
The PM was learning the domain — I can learn it faster. The PO was managing a backlog — I own the backlog. The BA was writing requirements — I write them into the system itself. The Scrum Master was protecting the team's focus — I am the team, and my focus is my own responsibility.
“Domain knowledge is the only irreplaceable thing. Everyone else was middleware.The Middleware Problem — a restructured room
This isn't free.
Collapsing the middleware layer places a demand on me that the middleware was previously absorbing. And I need to be honest about that.
I have to communicate better. If there's no BA between me and the stakeholder, I have to translate fluently — not just design-to-dev, but vision-to-board, constraint-to-user, risk-to-exec. I have to speak every language in the room, because I am every role in the room.
I have to document better. The BA's specification document served a purpose: it created a shared record that didn't live only in someone's head. When I'm working alone with agents, the CLAUDE.md file is that record. The context files are the specification. The N layer in I<N>C is where domain knowledge gets encoded so it persists beyond the conversation, beyond the project, beyond the person who held it.
I have to listen harder. Without a researcher doing the listening for me, I have to develop the discipline to stop building long enough to observe. The agentic design system gives me speed. Speed without pause is just a faster way to build the wrong thing.
And I have to earn trust directly. The PM and PO were, among other things, political buffers — they managed the relationship between the team and the organisation. Without them I am exposed directly to every stakeholder anxiety and every executive mood swing. That exposure is clarifying. But it is not comfortable.
The room is smaller. The accountability is larger. That's the honest trade.
The N layer is the middleware that doesn't leave.
Here's where the INC framework makes this precise.
In the old model: the PM learns the domain, the BA writes it down, the PO holds it in their head, the whole triad carries the institutional knowledge. When they leave — and they always leave — the knowledge walks out with them.
In the I<N>C model: the N layer IS the encoded domain knowledge. Not a person who knows the domain. A system that has absorbed it. CLAUDE.md files, structured context, component decisions informed by domain constraints, token names that carry semantic meaning about the problem space. The N layer is persistent. It doesn't resign. It doesn't get promoted to another team. It doesn't go to a competitor and take the roadmap with them.
This is the deeper argument for agentic design systems that I rarely see made: they solve the knowledge retention problem that every organisation pretends to address and never actually does. Every project I've been on has had a “knowledge transfer” session at the end. Everyone attends. Nobody absorbs it. The knowledge evaporates.
The N layer makes knowledge structural rather than personal.
Domain experts don't need to attend every meeting — they need to inform the system once, and the system carries that knowledge forward into every output.
I— I bring the exploratory vision. The provocative NorthStar prototype that nobody commissioned but everyone responds to.
<N>— Domain experts inform the context layer. Their knowledge becomes machine-readable. Persistent. Scalable. Not locked in a person.
C— I ship production outputs that are already informed by domain expertise, because it was encoded into the system from the start.
The PM, PO, and BA were an analogue solution to a knowledge management problem. The N layer is the digital one. It scales. It compounds. And it doesn't need a calendar invite.
If you're a PM reading this — good.
I'm not writing this to be cruel. I'm writing it because the most useful thing a PM can become in an AI-first organisation is a domain expert who can talk directly to a builder. Stop being the translator. Become the person with something irreplaceable to translate.
If you have domain knowledge, decision authority, or lived experience — and you want to work with someone who can move at the speed this moment requires — I'd like to talk. Not about headcount or process. About what's possible when the room contains exactly the right people.