There Is a Story in Matt Watson's Product Driven That Sent Me to His Podcast, and His Podcast Took Me Straight Back to South Carolina

I have been reading Matt Watson's book Product Driven, and one story in it sent me looking for more. The book version was short enough that I wanted the full account, so I went and found the podcast episode where Watson tells it in detail. I am glad I did, because the longer version is the one that landed.

Watson describes his early experience building software for auto dealers. He was twenty-two years old, meeting his eventual co-founder at an Applebee's in Kansas City, and what made the work real was the proximity. He was not designing for an abstracted user. He was sitting with actual dealers, watching them try to do actual things, and writing code that addressed actual friction. His own description of the experience is disarming in its honesty: he was "just a guy writing some code and having some fun." What he learned about software, about what makes it matter, came from being in the room with the people using it.

I recognized that immediately, because I had a version of the same experience.

Back in the 1900s, my first professional position was at FlexiInternational Software. My first real project was building an import utility for FlexiAssets, their asset management system. I was a developer. I knew nothing about accounting. I knew nothing about asset management. I knew what data structures were and how to write code that moved information from one system to another, and that was the full extent of my relevant qualification for the work.

So they flew me to South Carolina for two weeks.

I sat at the customer's desk, with the people whose asset records lived in the old system and needed to move into the new one, and we worked through it together. What did this field mean? What did they do when that condition was true? What broke if the import assumed one thing and the source data contained another? When I had an answer, I made the change right there, while they watched the screen. We would run it on their data, see what happened, and adjust again. Rapid application development languages like Visual Basic 3 made this possible: the feedback loop between a question and a working answer could be measured in minutes, not days.

It is worth being honest about the context. Most software development at that time was still waterfall, with significant separation between requirements, design, development, and testing. The approach I am describing was not the norm; it was a function of what RAD languages made possible and the specific nature of a data migration project that could not be fully specified in advance. But for the work that fit it, there was nothing like it. The customer's question and my answer existed in the same room at the same time, and the software reflected what we learned together almost immediately.

What Watson's book is pointing at, in part, is how completely that kind of proximity was lost, and how much the loss cost us without anyone quite deciding to pay it.

My own theory about where it went: we overcomplicated software development during the transition from desktop to web. The move to web-based systems was necessary and right, but we built processes around it that could not move the way the old tools could. What I once did in a week or two, sitting at a customer's desk with VB 3, now often takes months, with a whole team, multiple handoffs, and a process architecture that was designed to manage complexity and ended up generating it. The discipline we added was real discipline; we needed it. But we also lost something we have not fully recovered.

Watson's argument in Product Driven is that the engineering organizations paying the highest price for that loss are the ones where the distance between the engineer and the customer has become structural, not just logistical. Engineers writing code for users they have never spoken to, solving problems they have never watched anyone have, shipping things that work correctly in the technical sense and miss the point in the practical sense. His prescription is a shift toward ownership, toward customer context, toward the judgment that comes from understanding why, not just what.

I am not finished with the book. When I am, I will have more to say. What I can say now is that his diagnosis is accurate, and the experience of sitting at a customer's desk in South Carolina for two weeks while we figured out together what the data actually meant is the exact kind of thing he is trying to rebuild the conditions for. He is pointing at the right thing.

My own work tends to operate at a layer that sits underneath this one: even after you close the engineer-to-customer gap, there are tensions between systems that proximity alone does not resolve. But that is a different conversation, and it is not a disagreement with what Watson is building toward. It is what comes next after you get the foundation right. And the foundation is what Product Driven is about.

I write about structural leadership for executives and technical leaders in high-stakes operating environments. I read every reply.

---

I write about structural leadership for technical leaders in high-stakes operating environments. If you want to see where your system is load-bearing on you personally, the LeadershipOS™ Scorecard maps it: https://theleadershiposbook.com/scorecard