Product-Centered Team for the AI Era

Part 3 of the Post-Scrum series

Removing Scrum doesn't simplify the team. It demands more from every person on it. Fewer roles, fewer ceremonies, but each role carries more weight. The product owner must deliver precise input without refinement to fall back on. The developer must deliver end to end without a specialist to hand off to. The technical leader must stay ahead of tools that change every month.

The previous parts covered why the ceremonies break down and what replaces them. This one is about the people.

Product Developer: One Feature, One Person

The frontend/backend split is a coordination cost we tolerated because crossing the boundary was expensive. Even in a fullstack Rails codebase, one feature typically meant a handoff: someone on the view side waiting for someone on the data side, or the other way around. AI changed this equation: a backend-focused developer with AI can ship the view and the interactions, a frontend-focused developer with AI can write the model and the migration. The barrier dropped enough that the coordination cost of splitting work across specialists stopped making sense.

The product developer takes a task and delivers it end to end, through the full stack. The name says something specific: the product developer delivers the product as a whole, not a slice of it. The position in the chain doesn't change. The developer still depends on the Product Owner for input quality. Still delivers rather than defines.

Characteristics of the Product Developer

• Goes through the entire stack. One feature, one person. The coordination cost drops to zero for most tasks.
• AI levels the gaps. A product developer doesn't need to be an expert in the view layer to deliver an interactive screen, but needs to know what to expect from it. AI multiplies existing knowledge. A developer with solid fundamentals and AI produces more than a specialist without it.
• Continuous learning is mandatory. The developer's knowledge is a multiplier. AI multiplies what's there. Multiplier times zero is still zero.
• Can make micro-decisions and iterate. "What if the list is empty?" Make a decision, deliver, change it in minutes if wrong. One person holds the full context. The principle is still "ask the PO," but the threshold shifts. For trivial micro-decisions, it's cheaper to try and adjust than to wait for an answer on Slack. For significant decisions, the developer still asks. And here seniority matters: a junior doesn't know which decisions are trivial and which aren't.

Obie Fernandez made this point in his keynote at Ruby Community Conference 2026 in Krakow: removing developer faction divisions lowers barriers and lets everyone think about the product, not about writing lines of code.

Specialization doesn't disappear. Someone still needs to understand distributed systems architecture, frontend performance, or database internals. But that expertise becomes consultative, needed at architectural decision points, not at every task.

Product Owner: From Backlog Manager to Input Provider

Part 1 made the case that input quality determines everything downstream. In a post-Scrum model, the PO isn't a backlog manager or a story point prioritizer. The PO is the provider of quality input and the guardian of outcome. Both sides of the delivery: defining what to build, and verifying that what was built matches the intent.

The shift is operational. Before, a PO could be vague because refinement gradually extracted precision over several meetings. Now there's no refinement buffer. A developer takes a task, does research, writes a plan. If the task is vague, either the plan will be bad or the developer comes back with questions immediately.

The PO arrives at the developer with a task that already passed a first round of scrutiny, prepared with AI assistance (as described in Part 1). After the developer delivers, the PO reviews the result against the original requirements. This feedback loop was always implicit in Scrum demos, but in Pulse it becomes direct and continuous. Refinement didn't end. It changed form and shifted closer to the PO.

Product Manager: After the Scrum Master

The Scrum Master guarded ceremonies. No ceremonies, no Scrum Master. But the need for process oversight doesn't vanish. Someone must ensure work flows from business through developers to delivery.

When this role is needed depends on team size:

• 2-3 people: not needed, self-organization suffices
• 5-7 people: team lead with additional responsibility
• 10-15 people: dedicated person, otherwise nobody does it and the process rots silently

The name matters. Not "Scrum Master," because there is no Scrum. Not "Project Manager," because a project has boundaries and a product does not. Product Manager fits the naming: Product Owner defines what to build, Product Developer delivers it, Product Manager ensures the flow between them works.

What the Product Manager Does in the 3/1 Cycle

During the three weeks of flow:

• Ensures the developer has work. Queue not empty, PO delivered tasks.
• Ensures work doesn't stall. Someone blocked? Forgot to update? PO didn't respond?
• Pushes to action. Business doesn't create tasks by itself, developers forget to update.
• Escalates if something systemically doesn't work.

During the breathing week:

• Runs retro and ensures it doesn't dissolve into nothing.
• Follows up on retro outcomes. A retro without follow-up is wasted time.
• Reviews metrics with the tech lead: throughput, cycle time, bottlenecks.

This isn't a strategic role (that's the technical leader) or a product role (that's the PO). It's operational. Ensuring the defined process actually works day to day.

Technical Leader: From Stack Architecture to Process Architecture

The technical leader (CTO, Head of Engineering) isn't an element of the Pulse process but its foundation. Without this person, transformation won't happen. The tools are available to everyone, but having AI alone won't change the process.

This person can't be "catching up to the team." Must be ahead of it. Must teach both the team and the business (mainly the PO).

Selecting Tools and Defining the Development Process

The technical leader defines how the team works with AI, not just which tools to use. This goes beyond selecting an IDE or a coding assistant. It means defining the workflow, project standards, and code review rules, but also deciding what instructions the AI receives, what code standards it generates, and what guardrails exist. CLAUDE.md files, custom instructions, skills, automated workflows. The technical leader used to define application architecture. Now they also define the architecture of the development process, with AI as a component.

Bridging Transformation Stages

The technical leader sees where the team is (stage 1, 2, 3 as described in Part 2) and knows what to unblock. When a developer isn't learning AI, the leader shows the workflow on a real task. When a PO can't prepare tasks with AI, the leader sits down and walks through the process. When the team has no throughput data, the leader sets up metrics. The role is a constant reading of the transformation bottleneck.

Building a Knowledge-Sharing Culture

Weekly meetings, presentations of new solutions and technologies. Not one-directional "CTO teaches team." A developer may find a technique the CTO didn't know about. The CTO moderates and sets direction, everyone learns.

Protecting Against Extremes

On one side: enthusiasm without discipline. Vibe coding, no tests, "AI will write it for me." On the other: resistance to change. "We've always done it this way." "I don't trust AI." Balance: AI yes, but with tests, with plan review, with developer accountability for the output.

Guarding Hard-to-Reverse Technical Decisions

In a world where AI writes code and review changes form, someone guards the data model, security, architecture. Not in every PR, but in hard-to-reverse decisions. Consultative, not gatekeeping.

This role always existed but becomes more important in the AI era. A CTO used to define stack and processes once a year and adjust quarterly. Now tools and capabilities change every month. A CTO who set up a workflow in January and didn't revisit it in March is already behind.

Benefits of the Post-Scrum Model

An autonomous product developer with AI delivers faster than a team synchronizing through ceremonies. That's the obvious gain. Two less obvious ones matter more.

Individual performance becomes visible. Scrum masks it. Velocity is team-level, responsibility is spread across the group, and it's easy to hide. Known phenomenon: someone has been "participating" for years but delivers little. In Pulse, every developer takes a task and delivers it end to end. Everyone is visible. The strongest contributors stand out too.

The team composition shifts. This isn't about eliminating people. It's about building a team of individuals who genuinely want to solve problems. Scrum allowed functioning with "average." Pulse demands engagement but gives autonomy and satisfaction in return.

What We Lose by Removing Ceremonies

We definitely lose bonds. Ceremonies gave a pretext for interaction. Refinement, planning, daily were moments of conversation. You discussed architecture during planning. You learned about someone's weekend in the two minutes before daily started. Without those moments, the team can atomize. Especially remotely.

Part 1 covered how demo and daily standup adapt (async formats, flexible frequency, the team decides in retro). The question here isn't what replaces the ceremony, but what replaces the human connection it provided.

Knowledge Sharing

Weekly meetings (mentioned in the technical leader section). New techniques, tools, discoveries. Everyone can bring something. This replaces the knowledge transfer that refinement gave incidentally.

Learning and Development

Ceremonies gave juniors (and not only juniors) a chance to observe, ask, build context. Without them, you must replace this consciously: pair programming, mentoring, code review sessions as learning rather than just verification.

Burnout in AI-Assisted Development

We've had several burnout waves in our profession. This is another one. AI-assisted development is more intense: more decisions per hour, less "mechanical" coding that gave breathing space.

We won't solve this within a process framework. But we must give space to talk about it. In retro. In 1:1s. In the breathing week. Everyone faces this, not just developers. The PO with AI makes more decisions. The tech leader constantly learns. The PM feels a faster pace.

Pulse gives systemic breathing (one week per month), but that's not a "burnout solution." It's a space for conversation about it. Sweeping it under the rug is the worst thing you can do.

Junior Developers: An Open Topic

The entire model assumes a senior team. Juniors need what ceremonies gave incidentally: structure, learning, context, chances to ask questions and observe seniors. If we remove ceremonies, we must replace this consciously.

Remote work makes this harder. A junior should observe, ask, have short feedback loops. AI answers questions but doesn't build judgment. This leads to what could be called the "Silent Silo" problem: a junior stops asking people and relies only on AI, which accelerates output but erodes the learning that comes from human interaction.

We don't have an answer for this yet. The topic is important and challenges the universality of the model.

Scaling: Up to 15 People, Not Beyond

Pulse is described for a team of up to about 15 people. The number is subjective, from my experience, but the reasoning behind it isn't. A team of 15 autonomous developers already needs coordination to avoid stepping on each other's work and drifting into knowledge silos. One product manager can handle that. Beyond 15, you likely need two product managers, and then you have a new problem: who coordinates the product managers? That's where you cross from a single team into an organization, and Pulse doesn't cover that.

Beyond 15 means building parallel teams, splitting by domains. Different scale, different problems. That deserves its own discussion.

Building a Team for Post-Scrum Development

The shift from Scrum to Pulse isn't just a process change. It redefines roles, expectations, and what the team needs to function. It requires stronger input from the business, more autonomy from developers, and active leadership driving the transition. Not every team is ready. A lighter Scrum with AI-assisted workflow is already a significant improvement, and for many teams that's the right next step rather than a full transition.

We used Scrum at Visuality for years, across many teams, with multiple clients. It worked. Not perfectly, but it worked. Now clients ask me, as CTO and consultant, how to set up process for AI. Not "whether AI" but "how to work now." These reflections are my answer. Not academic, not theoretical. Coming from daily work with teams and clients. Visuality joins products or takes over their development as a long-term partner. Our people are specialists ready to be product developers. This is the perspective of someone who must answer the client "what next" and deliver a team that works in that "next."

Articles in this series

• Why Scrum Stops Working in the AI Era
• Pulse: Software Development Without Sprints
• Product-Centered Team for the AI Era