There is a meeting that happens in most software companies.
Product shares requirements. Design shares mocks. Engineering asks questions that reveal the requirements were underspecified and the mocks do not account for how the system actually works. Everyone goes back to their function. Two weeks later, repeat.
I have been in that meeting more times than I can count. I have run engineering teams that lived downstream of it. And the older I get, the more convinced I am that one of the most expensive fictions in software development is the idea that great products come from clean functional lanes.
Product decides. Design shapes. Engineering builds. QA tests.
It sounds orderly. It sounds scalable. It sounds like maturity. It is also one of the fastest ways to sand the edges off a good product idea.
The best product teams had individual members with with unusual depth in particular areas (in product thinking, design taste, architecture, systems, writing, research, or programming). But they do bound their contributions exclusively to those areas.
When we operate strictly within a particular functional lane, we tend to ask ourselves "what part is mine and that part is yours"? It segments the problem and organizes solutions much more narrowly.
Why lanes produce mediocre products
When you split product development into functions, you do not just divide labor. You divide context.
You take one creative act, figuring out what to build and making it real, and break it into specialized fragments. That brings all the usual costs of specialization. More translation. More waiting. More coordination. More interpretation error. More artifacts designed to move context from one group to the next.
The work starts to move, but the understanding does not move with it. That is why so many teams feel busy but dull. They are not spending their energy on the product. They are spending it on the gaps between functions not the flow that great problem solving demands.
Product writes it down. Design interprets it. Engineering reconstructs it. Then everyone meets to reconcile the differences.
We call that collaboration, but a lot of the time it is planned waste (from context switching).
Communication is never clean enough to support this model as well as we pretend. People use the same words to mean different things. They carry different assumptions. They emphasize different risks. Each handoff introduces drift. Each artifact becomes a proxy for shared understanding instead of the thing itself.
You end up with an organization optimized for passing work along rather than staying with it.
What the best teams do instead
The best product teams stay with the work.
They do not spend their time trying to perfectly package context for the next function. They spend their time solving the problem in front of them together. They walk the board together. If something is blocked, anyone can pitch in. If a decision needs to be made, the people closest to the work make it. If a piece of work needs more thought, more testing, more shaping, or more implementation, the team responds based on the need of the hour, not the org chart.
That only works if cross-domain learning is part of the daily working agreement. It has to show up in how the team works every day. Pairing. Shared context. Working in the open. Knowledge transfer inside the flow of work. Designers getting closer to code. Engineers getting closer to user friction. Product people staying close to system constraints. Everyone learning enough about adjacent domains to be genuinely useful.
That does not make people interchangeable but it makes us more able to pitch in whenever and where ever it matters most. And that matters, because high-performing teams are the ones that preserve focus and flow.
Once you see it that way, a lot of standard product process starts to look upside down.
Teams with lanes tend to optimize for future handoffs. They produce specs for the next function. Mocks for the next function. Decks for the next function. Documentation for the next function. The system quietly rewards work that is legible to adjacent departments, even if it is still far from reality.
Teams with no lanes optimize for the immediate work and the next real source of feedback. They try to get to truth faster. They get something working then quickly see how it works in production. They look at usage. They reflect on what the market itself is telling them. Their metrics become more tactile because they are closer to the product as it is actually experienced, not just as it was described in planning.
Fewer handoffs means fewer artifacts
This also changes how many artifacts you need.
When handoffs go down, there's a lot of work we no longer need to do. We can for example document less. Not to zero, some things are genuinely complex and need to be thought through carefully. Some decisions should be memorialized. But so many of the artifacts we develop are created to help transmit context across boundaries. You create artifacts when they help the team think or remember. You stop creating them just to transfer responsibility from one function to another. Less handoff means less documentation theater.
The tools start to change too. If the team really shares ownership, then the medium of work matters a lot. For me, that means code by default. Not because code is the only thing that matters. Because code is where the product becomes real. It is where behavior shows up. It is where constraints are exposed. It is where quality can actually be tested. It is where feedback stops being abstract.
So yes, I have become more suspicious of handoff artifacts over time. Figma is not a substitute for working software. PowerPoint is not a substitute for shared understanding. Use these artifacts sparingly.
Bring everyone into the gemba. Bring them to the place where the work is actually happening. That is where the best judgment gets formed. That is where weak ideas get exposed quickly. That is where tradeoffs become concrete. That is where the team learns.
How we formalize this at CINC Systems
At CINC Systems, we make this more than a philosophy but also build it into our structure.
Two-in-the-Box
One example of this we call Two-in-the-Box
The basic idea is Product and engineering do not meet at the edges of the work. They share ownership of the outcome and pursue the work together every day.
This starts at the top. Our CPO and I do not operate as adjacent functions negotiating with each other across a boundary. They share outcomes. They work as a team. The point is not for one side to represent product and the other side to represent engineering. The point is for both leaders to hold the whole problem together.
We mirror that at the next level. Each product line has both a product lead and an engineering lead. Again, not as separate owners of separate domains, but as a paired leadership model. They share ownership of the result. They pair on the daily work. They shape priorities together. They stay close to the same signals. They carry the same accountability.
Then we mirror it again at the team level. The team is not there to receive handoffs from product or wait for direction from engineering management. The team is there to own the outcome together. Product and engineering work side by side in the same flow of work. They walk the same board. They respond to blockers together. They pair. They share context. They stay with a problem until it is solved well enough to face the market.
That mirroring matters. If you want teams with no lanes, you cannot run the company in lanes and expect the behavior to disappear lower down. The structure at the top teaches the structure below it. If the executive team behaves like a set of functions negotiating territory, the product lines will do the same. If product lines behave that way, teams will do the same.
Two-in-the-Box is our way of saying that shared ownership is the design.
Language gives the game away One of the things I have noticed is that language reveals the real operating model faster than org charts do.
There are a few phrases that give away lane-thinking immediately.
From a ___ Perspective
One is: “From a ____ perspective...”
From a product perspective. From an engineering perspective. From a design perspective.
It sounds harmless. It is not. That phrasing frames the work through a functional lens before the conversation even starts. It invites people to represent a department instead of helping solve a problem. It subtly turns collaboration into negotiation between viewpoints that have already been boxed in. We are trying to stop using it.
The better question is not, what is the product view or the engineering view. The better question is, what does the outcome require? What are we seeing in the work? What is true in the product? What tradeoff actually gets us closer to the result?
People are not "resources"
Another word we are trying to eliminate is “resources.”
That word flattens human contribution into capacity management. It reduces people to interchangeable units to be allocated. It hides the fact that what we are actually asking for is judgment, creativity, care, adaptability, taste, communication, and ownership. The best teams do not win because they were assigned enough resources. They win because capable people brought the full range of their thinking to a shared problem and stayed with it.
Language matters because it shapes behavior.
If you talk like a functional organization, you will act like one. If you talk about people like inventory, you will manage them like inventory. If you keep framing work through departmental lenses, you will keep reproducing lanes even while claiming you want collaboration.
What no lanes actually means
When I say the best product teams have no lanes, I do not mean they have no discipline. I do not mean they have no craft or that anyone can do everything equally well. What I mean is that we refuse to let functional boundaries become the organizing principle of the work.
- They organize around the product, the problem, and the feedback.
- They know that specialty is useful, but handoffs are expensive.
- They know that the point is not to protect each function’s territory. The point is to get to the best outcome.
- They know that real collaboration is not each role finishing its part. It is multiple people staying with the work long enough to make it sharp.
- That is the model I keep coming back to.
Small teams with shared ownership between everyone on the team. Pairing or mobbing as a frequent practice and cross-domain learning as a norm. Code as the default medium. Fewer handoff artifacts. Faster feedback from the market. More time in the work itself.
The companies that build the best products will have no lanes.