Ten years in product design. Fintech, startups, companies scaling from scrappy to serious. And in every single one of them, I walked into the same room, looked at the same faces, and felt the same low hum of friction between design and engineering that nobody wanted to name out loud.
It was not a communication problem. Everyone kept calling it that. Buy better tools, run more syncs, write cleaner tickets. That was the playbook. And it never worked, not really, because the problem was never communication. It was the system itself.
The Pattern That Lives Everywhere
Here is what actually happens at most product companies, regardless of size.
Design finishes something. It looks beautiful in Figma. Somebody walks an engineer through it in a meeting that probably could have been an async Loom. The engineer nods. The ticket gets created. Three weeks later, the thing that ships looks about 70% like the thing that was designed, the edge cases are missing, the error states were never discussed, and design is frustrated. Engineering is annoyed that they are being asked to redo work they already shipped. Product is in the middle trying to explain why the sprint is behind.
And then the retrospective happens. Someone says we need better handoffs. A new template gets created in Notion. Nothing changes.
I watched this cycle repeat at every company I worked at. Not because the people were bad at their jobs. The people were talented. The cycle repeated because nobody had stopped to look at the actual shape of the problem.
The handoff is treated like a finish line. Like design's job ends and engineering's job begins at a clear moment in time. But that is not how building a product actually works. By the time an engineer sees a design, a hundred decisions have already been made, and nobody briefed them on any of those decisions. So engineers build with incomplete context, and then we are all surprised when the output has gaps.
The Aha Moment That Changed How I Work
At Opto, I started to notice something that I could not unsee once I saw it.
Sales was in front of customers every day. They were hearing real pain points, real requests, real confusion about what the product could and could not do. And almost none of that was making it back to product in a structured way. It was landing in Slack threads, in half-written emails, in verbal conversations that faded by Thursday. Meanwhile, product was building a roadmap based on their own read of the market, which was thoughtful but incomplete. The frontlines and the planning table were operating on different information.
At the same time, engineering was drowning. Sprints were bloated with a mix of feature work, quick fixes, random requests that came from nobody knows where, and the occasional fire drill. There was no triage. There was no clear distinction between what was innovative, what was maintenance, and what was somebody's pet idea that snuck onto the backlog. Engineers were grinding through work that had no context attached to it, and that grind was making them slower and more reactive over time.
Opto was at real risk of becoming a feature factory. Shipping things. Not building toward anything.
I had seen how Airbnb and Stripe thought about this differently. Not perfectly, but intentionally. They built systems where product and engineering were not just collaborating, they were sharing the same understanding of the problem before anyone wrote a line of code or pushed a pixel. Discovery was not something that happened to one team and got handed to another. It was something both teams did together, with sales and customer context baked in from the start.
That was the model I wanted to build.
What I Actually Built
I started by changing when engineers were brought into the conversation.
Not at handoff. Not at sprint planning. Earlier. During discovery. I wanted engineers in the room when we were still asking "what problem are we solving?" because their instincts about system constraints and technical shape change the conversation in ways that make the eventual design more real. When an engineer understands the user problem before they see the solution, they build differently. They ask better questions. They catch things designers miss. They stop being order takers and start being partners.
The second thing I built was a structured walkthrough process for designs. Not a meeting where someone screenshares Figma and narrates. An actual walkthrough that showed engineers what was new, what had changed from a previous version, and why specific decisions were made. The "why" was the part that had always been missing. When engineers know why something is designed a certain way, they can make better judgment calls when the real world does not match the spec. And the real world never matches the spec.
Third, I created a feedback pipeline from sales into product. Not a suggestion box. A real structured process where what sales was hearing in the field got categorized, triaged, and routed. Some of it belonged on the roadmap. Some of it belonged in a quick fix sprint. Some of it was valuable signal that was not ready to be a feature yet but needed to live somewhere it could be seen. That distinction mattered enormously. Before this, everything from sales felt equally urgent, which meant nothing was prioritized well.
The ticket system got redesigned around that same logic. Proper triage. Clear labels. A separation between work that was innovative versus work that was corrective versus work that was enabling. Engineers stopped opening a sprint and seeing an undifferentiated pile. They could see the shape of what they were walking into.
The result was that Opto did not become a feature factory. We built a pipeline for innovative ideas that had a home, a process, and a path to the roadmap without cannibalizing the capacity for doing the actual core work well.
What Leadership Actually Looks Like Here
I want to be honest about something. None of this was technically complicated. The tools existed. Figma existed. Jira existed. The concepts of discovery and triage were not new.
What was hard was getting people to change the shape of their work. Engineers who had been handed designs for years had to unlearn the idea that the design is something that happens to them. Designers had to get comfortable with engineers pushing back on their ideas before anything was finalized, which can feel like critique but is actually the best kind of collaboration. Sales had to believe that their frontline observations were not just useful anecdotes but actual product intelligence that deserved a system.
That is the leadership part. Not the system design. The belief change.
And the most important belief I had to sell was this: slowing down at the start of a feature actually makes everything faster. Bringing engineers into discovery feels like overhead until you realize it eliminates two rounds of revision at the end. Getting sales signal before roadmap planning feels like extra work until you realize it prevents you from building the wrong thing entirely.
The companies that look like they are moving fast are usually the ones who have figured out how to slow down in the right places.
The Thing I Would Tell Every Product Team
You do not have a communication problem. You have a system problem.
The handoff is not broken because people are not trying hard enough. It is broken because the system treats design and engineering as sequential steps when they are actually parallel workstreams that need shared context from the beginning.
Sales is not siloed because nobody cares what they think. Sales is siloed because there is no infrastructure for their knowledge to travel into the room where decisions get made.
Engineers are not overloaded because they are slow. They are overloaded because nobody has done the work of triage, and everything feels equally urgent.
Ten years of watching this happen across different companies, different team sizes, different tech stacks. The pattern is remarkably consistent. And so is the fix: not a new tool, not another retro, not a revised Jira workflow. A genuine redesign of when people touch work, in what order, with what information.
Build that system and the collaboration problem largely solves itself. Because the problem was never the people.
