Twenty Years Ago I Was a Successful Product Manager. AI Just Made That Job Harder.
Early in my career, before InfoTrust existed, I was a product manager at Attachmate for a while. I ran the Unisys product line, which included our airline vertical. It was enterprise software in the least glamorous corner of the industry—compared to the “sexy” sectors of that era like e-commerce, autos, or finance. The lack of glamour stemmed from the unsexy, technical nature of the work: getting accurate data from ancient mainframes to modern web applications. Connectivity, mainframe access, the plumbing that large companies depended on and nobody wrote magazine covers about.
I learned more in that role than in any other role, before co-founding InfoTrust.
A friend forwarded a memo, “Good Product Manager / Bad Product Manager”, written by Ben Horowitz years earlier when he was at Netscape. If you were a product manager in the ‘90’s, and someone forwarded this memo to you without comment, they were making a very clear and intentional point, “You need to read this”. 20+ years ago there were not a lot of books on product management. The memo was direct and focused; it specifically names the things that both good AND bad product managers do.
I read the memo and freaked out. It described things I was doing badly, in specific language, with no room to argue.
Twenty years later and now running a successful company, I have a different reaction to that memo. I think it was right about the thing that mattered most, and I think the reason it was right is only becoming clear now.
The line everyone argues about
Horowitz called the product manager, “the CEO of the product”. That line has been fought over for two decades.1
The critiques are fair. A Product Manager is not the CEO of anything, because nobody reports to you. Simply having the Product Manager title does not make you anyone’s boss. You need to bring a lot of pizza, note-to-self: how do you do that in a remote-first environment?
Here is what is interesting – a lot of people believe Horowitz eventually backed off the line. He did not.
When a16z republished the memo in 2012, he added one sentence at the top warning that a document written fifteen years earlier was probably not relevant to current product managers, and that he was posting it as an example of a training document. That is the only written update he has ever made to it. At least, Claude, Gemini, and I cannot find anything else shared publicly.
The closest thing to a real revisit came in September 2025, on Lenny Rachitsky’s podcast. Horowitz told the origin story, which is that he wrote the memo when he was genuinely angry at his team. During the interview he described the situation at Netscape in 1996, and clarified his intentions concerning the memo. Horowitz claimed he was not describing authority in the memo. Instead, he was describing the job of consolidating good ideas, making decisions, and holding the whole business accountable to a coherent vision, without the org chart to back you up.
What changed
For most of my career, the binding constraint on a product company was engineering resources. Engineering capacity was the scarce resource. Roadmaps had to be a rationing exercise. A significant part of my job at Attachmate was deciding which good ideas to starve, especially when we had limited engineering resources, and my product line was not the top money maker in the company.
That constraint is quickly disappearing in the AI-powered workplace. Our own engineering team ships with AI assistance at a speed I would not have believed possible, six months ago. The cost of building the wrong thing has collapsed, which sounds like good news and is not.
When building was expensive, the expense itself was a filter. Bad ideas died in estimation. Now they survive, get built, get shipped, and become someone’s maintenance burden for the next five years.
The ability to build is no longer a scarce resource for organizations, and Product Managers are evolving to meet new challenges and constraints. The judgment to decide what should or shouldn’t be built is the product manager’s job, and there is no other seat in the company where it lives.
This is why I think product management is now the most critical role in a product company, more so than when Horowitz wrote the memo, not less.
Rereading the memo in the AI era
A few of his contrasts land differently now. I am paraphrasing him rather than quoting, and you should go read the original at a16z.com.
On writing things down.
He said good PMs commit their thinking to writing and bad ones communicate in hallways. This used to be about accountability. It is now about buildability. A spec precise enough for a coding agent is a higher bar than a spec precise enough for a person, because a person interrupts you when your reasoning is incoherent. The machine builds it anyway. Vague thinking used to cost you a meeting. Now it costs you a shipped feature.
On knowing the market.
He said a good PM’s confidence comes from knowing the market, the product, and the competition better than anyone. Every competitor now has the same model access you do. Nobody has your customer conversations.
On saying no.
He talked about defining a good product that a competent team can actually build, rather than a wish list. When capacity was the constraint, saying no was arithmetic. Now saying no is pure conviction, and it is unpopular, because someone can always demo the thing you rejected by Friday.
On accountability for the result.
His view was that effective product managers own the failure when a release flops. This ownership becomes both more difficult and more vital as the friction of building disappears. Velocity is a convenient excuse for poor results. Refuse to hide behind it.
On the CEO framing itself.
Read it as accountability, not authority. The person deciding what should exist is answerable for whether it should have.
Why I am writing this now
We are hiring our first senior product leader at InfoTrust.
We are the largest independent Google Marketing Platform reseller, and we are building a data integrity layer platform on top of that foundation – 10+ years of working with top brands in the world to understand their challenges. That’s all I am going to share publicly until we come out of stealth mode.
The person who takes this job will also own our AI engine as a product. Engineering owns how it gets built. This role owns what it must do, what evidence decides whether it is working, and how technical disagreements get settled. This role will report to me as a CEO/co-founder.
Because this role is so critical—and because it reports directly to me—I need to be transparent about the specific challenge ahead. We are moving from being an AI-powered company to an AI-first company. This is new territory for everyone: me, our subject matter experts, and even our exceptional engineering team. None of us have built an AI-first system from the ground up, and we are comfortable admitting what we don’t yet know.
We are not hiring an AI expert. We are hiring someone who can turn every one of our open questions into a test with an owner and a date, and make the answer binding on everyone, including anxious co-founders.
If you have spent your career as the person in the room who was not the deepest technical expert, and turned that into an advantage by asking the question everyone else was too expert to ask, we should talk.
Email me directly at alex@infotrust.com with the story of a time you changed an engineering team’s or co-founders’ technical direction. That is the story I care about most.
