At WebExpo 2025, Karel Smutný’s talk, “The path to end-to-end teams”, challenged one of the most common assumptions in product development: that organising people into specialist teams makes organisations more efficient.
Karel opened with a simple room survey. Most attendees worked on large-scale products, organised around specific components or functions. But when asked if this setup was actually efficient, almost no hands stayed up.
That was the central tension of the talk. Specialist teams feel logical. They seem clean and organised. But when multiple teams need to collaborate to deliver one customer-facing product, that structure creates queues, dependencies, delayed feedback, and work that may be locally efficient but globally pointless.
The garden fence problem
Karel described specialised setups as having separate gardens. Each team grows its own crops, works its own backlog, and protects its own territory. The fences between them aren’t accidental; they are a byproduct of the structure itself.
“And behind the fence, there is another team being specialised in something we don’t understand.”
Single specialty silos are everywhere: front-end, backend, UX, product management, database, or architectural. Even cross-functional teams that own only a fraction of the customer journey fall into this trap.
The dysfunction appears when a customer-facing feature needs several of these gardens to cooperate. A slow API becomes the backend team’s issue. The backend developers blame the database. The database team points to architectural guidelines. The architects mention Confluence. Nobody owns the outcome.
“Remember one thing, behind the fence, there is them. And they always suck.”
The structure encourages people to think in terms of “our work” and “their problem”, even when everyone is technically building the same product.
Coordination is not the cure
A typical corporate response to friction is adding coordination: product vision workshops, OKRs, demos, and large planning events. Karel singled out PI planning as a procedure designed specifically to manage multiple specialised silos chained together by dependencies.
Used well, PI planning can reveal the problem. It visualises an impractical structure, highlighting bottlenecks and underused teams. But used badly, it just keeps a flawed system alive.
“So you can have either going by priorities or have a utilisation of your resources. And then, organisation by single specialty teams, you must pick one. You can never have both.”
Business priorities rarely distribute evenly across specialist teams. If they appear to, Karel offered two explanations: a rare conjunction of Saturn and Jupiter, or cheating. One is more likely.
Backlogs are queues, and queues are delays
The deeper problem is flow.
When work passes between teams, each maintains its own backlog. Every backlog is a queue, and every queue creates delay. The more silos involved, the longer the cycle time becomes before a customer-facing feature is complete enough to generate meaningful feedback.
This delay is critical because product development relies on real-world feedback. Research and market data are useful, but the ultimate test is customer usage. If the organisation takes five, six, or ten sprints to deliver something end-to-end, feedback comes too late.
He also warned against the illusion of making features bigger so that waiting time feels proportionally smaller. In queueing theory, larger batch sizes only make the problem worse.
Local efficiency can still deliver nonsense
A specialist team might be highly competent and complete its tasks quickly. But if their output isn’t attached to the highest overall priority, that local efficiency is useless.
“If the team working on the complete bullcrap is working three times more efficiently, they are still delivering complete bullcrap because they can’t have anything else which is important.”
He gave the example of banking teams split between lending and servicing. Servicing might deliver a useful feature, like premature instalment handling, before the actual lending flow is ready. The work is valid, but if the business can’t lend money yet, it isn’t the priority. Even full-stack units specialised around narrow domains suffer from this uneven distribution of priorities.
Redefining the product
For Karel, the path forward begins with redefining the product from the customer’s perspective.
In e-commerce example, the product isn’t the website, mobile app, API layer, CRM, or ERP. Those are components. The actual product is the entire buying experience: finding an item, purchasing it, receiving it, and handling any claims.
What end-to-end teams need
Next, define what “done” means. Not just coding or testing, but everything necessary to put a working increment into users’ hands: documentation, training, marketing materials, and whatever else the product requires. That definition then determines the skills needed inside each team.
End-to-end teams aren’t built around job titles. They are built around the ability to take valuable backlog items and deliver them fully. People contribute through their skills and experience, rather than hiding inside a narrow role.
Fewer backlogs, better flow
Karel wrapped up by contrasting agile frameworks based on one backlog per product with those that tolerate or encourage single specialty teams. Simply put, for one customer-centric product, fewer backlogs are better.
If you work in a larger product organisation, Karel’s examples, diagrams, and PI planning simulation make the structural problem glaringly clear. Watch the full recording including slides below.