AI Didn't Unlock Everyone. It Specifically Unlocked Product Managers.
There's a specific profile of person AI unlocks. Not the programmer. Not the non-technical person. The one in between.
I’m not a programmer. Never have been. I’d call myself “Technical” — with 20+ years of technical experience behind me.
I can’t write code from scratch. Never could (maybe a Perl script). And yet over the last few months I’ve been building things I couldn’t have imagined building alone.
A full AI operating system (for me) running on a server in Helsinki. An AI bartender for a vodka brand — Rocket Vodka. Apps, products, agents, automations.
One person. Me.
So what happened?
I’ve been thinking about this a lot, because the easy answer — “AI lets anyone code now” — doesn’t quite capture it. That framing is too broad. Too flat. It implies the playing field just leveled for everyone equally, and I don’t think that’s true.
What actually happened is more specific. And if you’re a Product Manager, it’s worth paying attention to.
There’s a profile of person that AI specifically unlocks.
Not the seasoned programmer — they already had the code layer. Not the pure non-technical person — there are still gaps AI alone can’t bridge.
The person AI specifically unlocks sits in between. The one who always understood how things connected but couldn’t build them alone. The one who spent a career between engineering and the customer, use-cases, writing specs, translating, prioritizing, deciding — never executing the technical layer personally.
That person is a Product Manager.
Think about what a PM actually brings to the table. You understand systems. You know how things connect. You’ve spent years working with engineers without being one, absorbing how APIs work, what a deploy actually means, what technical debt feels like from the outside. You have product instincts, customer judgment, design sense. You know what to build and why. You just couldn’t build it yourself.
AI fills exactly that gap. Not all gaps. That one.
My foundation and skills went back further than I expected.
When I started tracing why this was working for me, I ended up back at jobs I hadn’t thought about in decades. Server support at Netscape in 1996, working alongside the people who literally wrote the foundational protocols of the internet — Apache, LDAP, proxy servers, SSL certificates. I lived in Unix terminals. I supported the infrastructure layer before most people knew what a browser was. Let alone HTTP or HTTPS.
Then decades building features, products and platforms. Building consumer platforms at scale. Then moved into product leadership. Working with engineers daily without becoming one. Developing the judgment that comes from shipping things and watching them succeed or fail in the real world. In fact there have been moments where I felt I moved so far away from product I had become operational — I longed for product & design reviews.
None of those layers made me a builder on their own. But combined? Maybe. AI filled the one gap I always had — coding. The circuit completed.
What surprised me was realizing how much of that foundation I’d forgotten I had. It took actually building something — not reading about it, not advising on it, but doing it — to surface it.
Building to learn. Even if it already exists.
A peer made an observation recently that stuck with me. Even if what I was building already exists somewhere, that wasn’t the point. Building it yourself is the learning. What it takes. How. The process is the value, not the artifact.
This matters because a lot of people talk themselves out of starting. “There’s already a tool for that.” “Someone’s already built this.” Maybe. But you haven’t built it. And until you do, you don’t actually understand how it works, the challenges you run into, the limitations or how to direct AI to build the next thing, and the thing after that.
The reps compound. Every build teaches you something the next build needs. Making it easier in fact.
The profile has a requirement.
I want to be honest here because the “anyone can build now” framing does a disservice to people who try it and hit walls.
This works if you have enough technical foundation that AI can meet you halfway. Comfortable enough in a terminal to not panic. A few command line commands in the back of your mind. Some sense of what an API is. A feel for how systems connect. You don’t need to be a developer. You need enough surface area so AI’s output makes sense to you — that you can review it, direct it, debug the direction if not the code.
For most technical PMs, that foundation is already there. You may have underestimated it. The Netscape era skills I thought were irrelevant turned out to be load-bearing. I can now direct, develop, commit it to a repo, my hosting solution auto-pulls it, a CNAME is setup and it’s live within minutes on my own domain.
CS students have this too — and parents of CS students, this one’s for you too. It’s fresher than they think. The fundamentals just taught. The theory still live. If you’re a CS student wondering whether your degree matters in an AI world, the answer is yes — not in the way you were told. Not because you’ll out-code an AI. Because your foundation is exactly what lets you direct one.
The question that changed.
For most of my career, the question in the room was “can we build this?” Engineers scoped it. Timelines were set. Resources were allocated. The answer shaped everything.
That question has lost most of its weight. AI has collapsed the gap between idea and working app in a way I genuinely haven’t felt since the early days of the internet.
I’m not here to convince anyone this is the future. I’m just telling you what I built last month.
The question now is “should we build this?” And that one — knowing what problem you’re actually solving, who you’re solving it for, what to say no to — that’s a question Product Managers have been practicing their whole careers.
The tools changed. The thinking that matters didn’t.
What do you think?
Thanks for reading this far!
=- Michael
Originally published on Medium ↗