In 1990 I graduated from Earlham College with a political science degree, an almost-minor in French, and a plan to go to graduate school at Middlebury and get back to France. Instead, I spent the next stretch of my life in the basement of a rented condo in Ann Arbor, Michigan, answering a phone.
My brother Keith and I had started a software company called StratosWare. Its only product was a debugging tool called MemCheck. That basement is where I learned most of what has mattered in my career since: how to sell, how to listen to a customer, and why the person who has the problem is usually the best person to explain the solution.
A bug worth a business
Keith was a software engineer working as a consultant, and he had a bug in his code that was causing a lot of trouble. The root cause was the C language's flexibility with memory. C let you allocate memory and never free it, and it did nothing to stop you from writing past the end of a block you had allocated.
A simple example. Say you want to store the 26 letters of the alphabet, so you allocate 26 bytes. Seems right. But every C string carries a hidden terminating character at the end, so you actually need 27. That extra byte spills past the edge of your block and overwrites whatever sits next to it. Sometimes the program crashes immediately. More often nothing happens until much later, somewhere completely unrelated, and you spend days hunting a ghost.
This was 1990: 16-bit DOS, with compilers from Microsoft, Borland, Watcom and a handful of others. Keith built an elegant fix. MemCheck intercepted every memory call the compiler libraries exposed (malloc, calloc and the rest), substituted its own, and wrapped each allocated block with check bytes on either end. When something overwrote a boundary, MemCheck caught it. It also caught null pointer assignments and a range of other allocation errors.
The same class of bug is still with us. Buffer overruns sit at the root of a large share of the security vulnerabilities exploited today, on everything from phones to enterprise systems. Keith was solving a problem that has outlived DOS by more than three decades.
The go-to-market plan was a business card
We started the business more or less on a lark. The logic was simple: if this tool helped Keith on his project, other developers probably had the same problem.
Our entire marketing launch was a business-card-sized ad in The C Users Journal, which reached a little under 40,000 developers. The phone number was 1-800-WE-DEBUG. I still think that was clever.
The phone started ringing.
That created a problem. Keith was still working full time, and we couldn't afford for him to quit. I was the one in the basement, and my knowledge of the product ran out about two sentences into any conversation. I was an inbound SDR before I knew the term existed.
The three-way call
Our solution was low tech. We added three-way calling to the landline.
When a prospect called and I hit the limit of what I knew, which in the early days happened fast, I'd ask them to hold, press the switch hook, and speed dial Keith at work. If he could talk, I'd press the switch hook again and connect him.
Then I stayed on the line and said nothing.
I could have put the phone down and done something else. I didn't, because I was intensely curious. Here I was, a poli sci grad with no background in computer science, and I wanted to understand what was happening on these calls.
What was happening was that Keith was very good at this. He was a highly skilled developer and extraordinarily articulate. More important, he was the ideal customer. He had built MemCheck for himself. When a developer described the bug that had eaten their week, Keith had lived it. There was an instant bond on those calls that no sales script could manufacture.
He almost always closed. These weren't big deals, around $140 a license. When he was done, he'd flip the call back to me. I'd pretend I'd just picked up, take the order, and ship the product.
We repeated that over and over for the first several months.
What the silent listener learned
Over time I picked up how Keith described the problem, how he tied it to what the caller was actually living through, and how he handled pushback. Neither of us knew the phrase "objection handling." We were just having conversations.
Eventually I didn't need to dial Keith in at all. I could have the conversation myself.
I thought StratosWare was my first job in software. It was also my first job in sales, my first real customer research and, though I wouldn't have called it this, my first lesson in product management. As I reflect on some of the people I admire most in Product Management (Marty Cagan and Mike Cohen), four things from that basement and their writing have held up for 35 years:
The person with the problem explains the product best. Keith sold MemCheck because he was the user. The closest a product team can get to that is sustained, direct exposure to customers, not secondhand summaries.
Listening is a skill you build by doing it on purpose. I learned more from silent hours on those calls than from anything I had studied. The teams I've led that shipped the best products were the ones where product managers, designers and engineers heard customers directly and often.
Distribution is simple when the problem is real. A tiny ad in the right publication worked because developers recognized their own pain in it. No amount of go-to-market sophistication fixes a product that isn't solving a real problem.
You rarely know what you're learning while you're learning it. I thought I was answering phones.
I've carried those calls into every product organization I've led since. When I sit down with a team today, one of the first things I look for is how close they actually are to the customer's problem. It is still the best predictor I know of whether they will build something that matters.
