The Skills AI Couldn’t Replace

My laptop has become a retirement community for software projects. (Shady AI-cres...feel free to insert a groan.)

I’m not talking about abandoned Git repositories or half-finished ideas that never made it past “Hello, World.” I’m talking about real, working applications. Some of them have become part of my daily routine and save me hours every week. Others enjoyed a brief but glorious existence before I quietly thanked them for their service and dragged them to the Trash. If my wife ever opens the Applications folder on my Mac, she’s probably going to assume I’ve been secretly running a software company on nights and weekends.

In fairness, she wouldn’t be entirely wrong.

I’ve always had side projects cooking. Years ago, I started two companies. One was an absolute flop that taught me to choose business partners much more carefully. The second I bootstrapped, grew, and eventually sold before moving on to the next chapter of my career. Even after that, I never really stopped building. Throughout my career there was almost always some little application, utility, or experiment sitting off to the side. The only real difference is that those projects used to take weeks or months to build. Today, they sometimes take an evening.

I’ve started referring to the casualties as my vibe-coding graveyard, and oddly enough, I don’t regret a single one of them. Every project taught me something. Some taught me new ways to use AI. Others reinforced product instincts that had served me well long before AI arrived. Quite a few reminded me of a truth that every good Product Manager eventually learns the hard way: just because you can build something doesn’t mean you should.

That wasn’t the lesson I expected AI to teach me.

Like most people, I was initially captivated by the technology itself. I wanted to see how far I could push it. How quickly could I build something useful? Could I automate work that had always been tedious? Could I create the little utilities that I normally would have asked Engineering to build, or more likely, simply lived without? Every new capability unlocked another idea, and before long I found myself building almost every evening simply because I could.

Some of those applications have genuinely changed the way I work. I’ve built dashboards that help me monitor adoption and performance of native AI products. I’ve built tools that analyze information I previously wrestled with in spreadsheets. I’ve built utilities that automate repetitive work, freeing me to spend more time thinking about customers and products instead of manipulating data. Those are the kinds of projects that quietly pay for themselves every single day.

I’ve also built some incredibly stupid things.

The funny part is that very few of those applications were technical failures. They worked beautifully. The code was solid, the interfaces were clean, and they solved exactly the problem I had designed them to solve. The only issue was that, after using them for a few days, I realized I had built elegant solutions to problems that weren’t particularly important in the first place. Looking back, I’m convinced there are applications in that folder that future archaeologists will eventually discover and simply label, “Purpose unknown.”

The funny part is that AI didn’t make those mistakes.

I did.

That realization has been bouncing around in my head for the last several weeks because I think we’ve been having the wrong conversation about AI.

Almost every discussion eventually becomes technical. We compare models. We debate Claude versus ChatGPT. We talk about Claude Code, Cursor, agents, MCP, prompting techniques, workflows, and whatever new capability was announced sometime last Tuesday. I enjoy those conversations as much as anyone. I’m in them almost every day.

They’re just not the conversations I find myself thinking about after I close my laptop.

The question I’ve become much more interested in is what happens when building stops being the hard part.

For years, one of the biggest constraints in software development was simply getting something built. Even though I continued writing code throughout my career, there was still enough friction to force careful decisions. Libraries needed to be installed, infrastructure had to be configured, deployments required planning, security demanded attention, and every project represented a meaningful investment of time. Those constraints weren’t always enjoyable, but they had one unexpected benefit. They forced us to think carefully before we committed to building something.

Today, I can have an idea after dinner and be using a working application before I go to bed.

That’s incredible, and it’s also a little dangerous.

When the cost of building collapses, the cost of poor judgment doesn’t disappear with it. In many ways, it becomes even more important because poor decisions can now be executed just as quickly as good ones. I can build the wrong thing in an afternoon just as easily as I can build the right thing. The only real difference is whether I exercised good product judgment before I ever wrote the first prompt.

Somewhere between building my twentieth application and deleting my fifteenth one, something finally clicked.

AI hasn’t changed the skills that make someone an exceptional Product Manager. It’s reminded me how valuable those skills have always been.

As I look back over my own career, the projects I’m most proud of were never successful because someone wrote a brilliant requirements document or maintained the perfect roadmap. They succeeded because the team understood the customer, recognized patterns that others missed, made difficult tradeoffs, and had the discipline to solve the right problem instead of simply the next problem. Those are the same instincts that guided me when I was writing software, building companies, leading product organizations, and more recently, building AI-powered products.

The more I use AI, the more valuable those instincts become.

AI is exceptionally good at helping me execute. It helps me research faster, prototype faster, analyze information faster, and experiment with more ideas than I could have imagined only a year ago. I wouldn’t voluntarily give those capabilities up.

What it doesn’t do is replace the context that comes from years of customer conversations, product launches, successes, failures, and difficult tradeoffs.

It doesn’t know which feature requests represent genuine market opportunities and which ones are simply the loudest voices in the room. It doesn’t know the customer conversations I’ve had, the launches that exceeded expectations, the ones that failed despite everyone’s confidence, or the subtle patterns that only emerge after years of solving similar problems across different companies and industries.

That context still matters.

In fact, I think it matters more now than it ever has.

I was reminded of that recently while working through a strategic analysis. AI helped me organize information, identify themes, and formulate recommendations. The document it produced looked fantastic. It was polished, logical, and persuasive. It also contained conclusions that weren’t actually mine. After spending more time with the underlying information, I realized parts of the analysis didn’t align with what I genuinely believed. The writing was convincing enough that I almost accepted conclusions I hadn’t fully earned myself.

That experience eventually became the basis for my previous blog, The Battle of the Claudes, but it also reinforced something I hadn’t fully appreciated.

AI is remarkably good at helping me think, challenge assumptions, and explore possibilities. It cannot own my thinking, and I don’t believe I should ask it to.

I want AI to make me more productive. I want it to help me uncover signals I might otherwise miss. I want it to challenge my assumptions and force me to consider perspectives I hadn’t thought about. What I don’t want is to slowly outsource the judgment that comes from curiosity, customer empathy, experience, and years of making difficult product decisions.

Ironically, I think that’s good news.

The administrative work of Product Management will continue to become easier. Research will become easier. Prototyping will become easier. Documentation will become easier. Building software will continue to become dramatically faster.

What becomes more valuable are the qualities that always differentiated exceptional Product Managers in the first place. Understanding customers. Recognizing patterns. Exercising sound judgment. Making difficult tradeoffs. Leading teams toward the right problems instead of simply the next ones.

I’ve written before that I believe the future belongs to Product Builders, and I still believe that. But becoming a Product Builder isn’t simply about learning how to use Claude or writing better prompts. It’s about combining timeless product instincts with an entirely new level of leverage. Whether we continue to call them Product Managers or Product Builders is almost beside the point. The title may evolve, but the underlying skills are more important than ever.

The tools are changing faster than anything I’ve seen in my career. But the qualities that make someone exceptional haven’t changed at all.

Every time another application quietly joins the vibe-coding graveyard, I’m reminded that building software was never the hard part.

Knowing what deserved to be built always was.

Wishing you all the best

Mike