Agentic product development: recomposing the team
This is part 3 of 4 in a series about Product Development teams with AI agents. The other parts are linked at the end.
The team was never just a coding unit
A product team needs marketing, business strategy, and delivery skills inside it, not beside it. It always did.
If you’re applying a Kanban strategy, the “Kanban System Members” are encouraged to pursue cross-functionality: the ability to swarm and contribute anywhere in the workflow. And if you’re practicing Scrum:
The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. — The Scrum Guide™
That list doesn’t stop at code. Unfortunately, too many managers treated the team as a coding unit because code was scarce (see part 1), and then staffed numerous roles upstream to keep the coders fed (see part 2). Now agents write most of the code, and the people/processes orbiting the coders are the slowest part of the system.
Some organizations are starting to recompose their teams. Good! But I see the same error in almost every case.
The common error: adding roles instead of skills
Some leaders acknowledge that the team needs marketing, UX, and release skills. But rather than upskill the existing personnel, they add a person for each. A UX designer role. A marketing liaison role. A release manager role. Each role reinforces bureaucratic gates. The hand-offs that used to occur outside the team now occur inside it, and nothing flows any better.
Let’s make that distinction clear:
- A role
- A slice of the work owned by a specialist. Everyone else waits for that person.
- Example: “We can’t ship. James writes the release notes and he’s away until Monday.”
- A skill
- A capability several people on the team hold, at different depths. One person may be proficient in that skill and lead it, others are sufficient. Work doesn’t wait for a specialist.
- Example: “James usually writes the release notes. Samantha wrote these. James will read them when he’s back.”
A specialty has a place, of course. Someone with years of UX or marketing experience should lead that skill on the team. But leading it is not owning it. Everyone on the team grows in that direction. Kanban and Scrum encourage exactly this kind of skill-fluidity, and Reinertsen named it in The Principles of Product Development Flow:
“Develop people who are deep in one area and broad in many.” — Reinertsen
Cross-functional team composition: a musical metaphor
For most of the last century, machinery stood between every musician and their listeners: recording labels, studio executives, session engineers, release calendars, and distribution pipelines. That machinery dictated when a record came out, in what form, and how fans heard about it.
Software teams have suffered from the exact same corporate machinery. Consider three ways to structure that dynamic.
1. The Beatles: great cross-functional execution within a limited boundary
The Beatles were a remarkably fluid unit.
Ringo played drums, Paul played bass, John played guitar, and George played lead. But when a song needed piano, acoustic guitar, or a new vocal arrangement, anyone stepped up. They swarmed the work within the bounds of composing, arranging, and performing.
Yet beyond those bounds, they remained dependent on external machinery. EMI owned the studio, assigned the producer, ran the mixing consoles, and controlled the release calendar. Capitol Records even altered album titles and tracklists for North America.
The Beatles were a brilliant cross-functional team, but their scope ended at the studio door.
2. Prince: the solo craftsperson trapped by go-to-market bottlenecks
What happens when an individual absorbs all the production skills themselves?
Prince famously played every instrument, sang every vocal line, and arranged every track on his early records. Equipped with AI agents today, individual developers are attempting the same thing: writing the backend, generating the UI, crafting tests, and drafting copy.
Prince could create at an astonishing pace, but he collided with a massive downstream bottleneck. His record label restricted his release frequency to avoid market saturation. Solitude gave Prince total creative control, but it didn’t give him a complete path to the customer. As a result, hundreds, possibly thousands, of completed tracks still sit locked in his vault.
Single-person units using AI agents risk building their own digital vaults. They may accumulate work faster than their external go-to-market channels can ship it.
3. Radiohead: bringing end-to-end delivery inside the team
Radiohead took a different path when their record contract expired: they brought the entire go-to-market mechanism inside the band’s operational boundary.
Instead of handing completed masters to a label and waiting months for a campaign, the band took direct control of release, pricing, fan communication, and digital distribution. When a record was done, they announced it on their own terms and delivered it straight to their audience.
The Roster Lesson:
- The Beatles had team fluidity but limited scope.
- Prince had complete production control but got trapped in inventory.
- Radiohead integrated production, distribution, and audience connection into one autonomous unit.
Cross-functional teams are the most valuable performance unit
Most software organizations build teams like legacy record labels. Frontend here, backend there, QA in another pod, and product marketing in an external silo. Each specialty boundary creates a queue. Each queue becomes a gate.
When AI agents handle the bulk of writing code, hand-offs between specialists become the primary source of drag. To accelerate, some managers lean into the existing silos and multiply them.
If AI only speeds up the code, and the people far from the code just get more help, the bureaucracy gets stronger and slower. But if AI is used to expand what a fluid, cross-functional team can manage, then dependencies can disappear and each team unit can act independently.
With AI, a team can complement their skillset with agents capable of market research, writing release announcements, writing code, running tests. Teams no longer need external departments to ship, nor do they need a sub-team of programmers. Dependencies can dissolve because all the complementary skills are inside the team boundary.
End-user advocacy: pacing releases to absorption
Code is now the fastest part of the process. The new limit isn’t deployment capacity, it’s user absorption.
Agents enable a team to alter a user interface daily. That doesn’t mean users can absorb a daily interface change. Every unannounced UI shift forces users to relearn workflows, retrain colleagues, or call support.
Therefore, it is more important than ever for teams to own end-user advocacy. This must be a skill internal to the team, not another external approval gate:
- Closing the distance to users: Team members speak directly with real users frequently, bypassing intermediate hand-off chains.
- Coordinating outbound communication: Release notes, messaging, and in-app guidance are built alongside the feature, ensuring users expect and welcome the update.
- Pacing change to absorption: Releases are staged or batched deliberately so customers gain value without experiencing change fatigue.
As Donald Reinertsen noted: “Proximity enables small batch sizes.” The closer your team sits to its actual users, the smaller and more frequent the changes those users can smoothly absorb.
How roles vs. skills show up on the team
- The working agreements
- Role-heavy: “Release notes are written by the release manager.” Everyone waits.
- Skill-fluid: “Whoever finishes the increment drafts the release notes; the team reviews together.”
- The Definition of Done
- Role-heavy: “Merged, tested, deployed to staging.”
- Skill-fluid: “Live in production, verified with real users, and announced in clear terms.”
- The Sprint Review
- Role-heavy: A demo performed for internal managers.
- Skill-fluid: Working software handed to key stakeholders.
- The core metric
- Role-heavy: Deployment frequency or story point velocity 😒
- Skill-fluid: Time-to-learn: the interval between taking action on an idea and learning from feedback directly from end users.
Key Takeaway:
- A product team was never just a coding unit. Add cross-functional skills, not specialized roles, and make sure your team directly manages how every release lands with the people using the product.
What to do next
Today
- Map your skills roster: List every skill required for an increment to reach users and be absorbed by them (messaging, user research, release communication, code, data, telemetry). Write down the team members who can perform each skill.
- Bring users into the feedback loop: Invite at least one active customer to join your team’s next product review.
Tomorrow
- Add columns to your workflow: Expand your board past “Deployed” to include “Announced” and “In Use”.
- Update your Definition of Done: Include a user-facing check, such as: “Impacted users have been notified via clear in-product communication.”
This Week
- Shift functions inward: If marketing, UX, release, or go-to-market steps reside entirely outside the team, pull those responsibilities inside or begin upskilling existing members to handle them.
- Measure absorption: Track support requests and user adoption rates following releases.
The goal
The outcome to strive for is:
- Cross-functional, independent team units.
- People stop asking “Who is supposed to do X?” and instead ask “Who can do X?”
- Analysts and SMEs stop thinking their job is to shove requirements at the coders. They instead realize their job is to sit with them.
Want to challenge me? Maybe your context is unique. (Embedded hardware, safety-critical systems, and some heavily-regulated domains still have expensive code.) If writing code is still your constraint, tell me where and why. I’d like to hear it!