Around 2009, one of our biggest customers stopped going to meetings with our executives. He would fly in, sit down at the chair next to mine, and stay there for the rest of his visit. This went on for a year, and it taught me something about product development that I am still using as a heuristic in 2026.
The company was PeerTV. We built set-top boxes for home internet TV, plus a content management system on top in Python and Django. The CMS dev team was two people. Our customers were international TV content providers, some of them with millions of users. This story is about what happened when one of those customers stopped relating to us through the formal product process.
What We Were Building
PeerTV supplied the boxes and the software, and customized them per content provider. Each provider had their own branding, their own menus, and their own content workflows. The CMS was where all of that came together: an interface where the content provider managed their channel lineup, edited the user-facing menus on the set-top box, and tracked the state of devices in the field.
For about a year, we built it the normal way. Our PMs and account managers spoke to the customer. The customer’s executives spoke to our executives. Requirements flowed down through one layer of management, then another, then arrived at my desk as a ticket. We shipped. The customer reviewed. The review came back through the same chain. We iterated. It worked, slowly.
The Year He Started Coming In
Then, about a year into the project, the head of content at one of our biggest customers started doing something unusual. He would book a special flight from his country to ours. He would have a short meeting with our management. Then he would sit down at the empty desk next to mine, open his laptop, and stay there for the rest of his visit.
He would point at the screen and tell me exactly what he wanted the next feature to look like. Where the button should go. What the field should be called. Which workflow he wanted collapsed into one screen and which one he wanted broken into two. I would build it live. He would react in real time. By the end of the visit, we had shipped, sometimes several features deep.
This pattern repeated for a year. He flew in multiple times. Each time, he sat at the same desk next to mine.
What Live Iteration Actually Looked Like
The thing that made this work was not raw speed. It was the elimination of the translation layer between intent and code. In the normal flow, a feature went through at least three people who each tried to summarize what the previous person wanted, and each summary lost information. By the time it hit my keyboard, half of the original intent was gone, and I would build the wrong thing in the right shape.
With him at my desk, there was no summary. He saw the half-built version while I was building it. He could tell me “no, smaller” or “no, this should be a dropdown” or “actually never mind, that workflow is dead” before I committed to the next twenty minutes of work. The build-feedback loop went from weeks to minutes.
It was also exhausting. Building under direct observation is not the same as building on your own. But the throughput was a different category of thing.
Why Management Let It Continue
It started as a friendly, almost accidental arrangement. The first time he sat next to me, it was because he had asked a question that needed a code change, and rather than pull me into a meeting, he just stayed at my desk while I made it. The next visit, he did the same thing on purpose.
Our management noticed. They could have stopped it. The arrangement bypassed the entire formal product process and put a customer directly into the engineering team’s day. There were obvious reasons to be uncomfortable with that.
They let it continue because shipping was the only metric that mattered, and the live process was shipping at a rate the formal one could not match. We were fifty people. We did not have the room to maintain two parallel product processes, and the live one was producing better software faster.
The 2026 Version of the Same Lesson
Seventeen years later, I think about this constantly when I work with founders on product process at seed and Series A.
One opinionated user with skin in the game, sitting next to the engineer, will out-ship any volume of PMs, JTBD interviews, roadmap reviews, and persona documents you can construct. The reason is the translation layer. Every process step between the user’s intent and the engineer’s keyboard is a place where information is lost or distorted. The fewer steps, the less distortion. Live iteration with the right user is the limit case: zero steps.
AI coding assistants have made the build half of that loop even faster. A live session that took us three days in 2009 might take three hours in 2026, because the engineer is no longer writing every line by hand. Which means the bottleneck has moved. It is no longer how fast you can build. It is whether you have the right person sitting next to the engineer to react in real time to what is being built.
If you do not, the speed of AI tooling will just let you build the wrong thing faster.
The Signal You Should Not Filter Out
The other lesson is about reading the situation when it happens to you. When a customer breaks protocol to sit next to engineering, it is almost always a signal worth honoring. They are telling you that the formal channel is not working for them. They are telling you where their real pain lives. They are telling you they have enough skin in the outcome to fly to your office and stay for days at a stretch.
Most companies’ first instinct is to gently route that customer back through the proper channels. That is usually the wrong call. The proper channels are the reason the customer is willing to fly to your office in the first place.
If a customer is sitting at your engineer’s desk, the question is not “how do we re-establish protocol.” The question is “what is wrong with the protocol that made this person give up on it.” The answer is usually that the protocol is filtering out the high-signal users in favor of the easier-to-handle ones.
Let’s Talk
If you are running an early-stage engineering team and trying to figure out how to get more real customer signal into your build loop without the process overhead of a much bigger company, that is the kind of question I work through with founders. I take on senior async architecture and product-engineering work for teams trying to compress that loop. If that sounds like your situation, reach out.
