The Rise of the Product Builder

Throughout my career, I've always had some side project cooking. Sometimes it was a website. Sometimes it was a mobile application. Sometimes it was a piece of software designed to solve a problem that annoyed me. Sometimes it was just an idea that seemed brilliant at the time and considerably less brilliant a few weeks later.

Along the way, I've also started a couple of companies. One was a complete flop. Looking back, it provided a very expensive lesson in choosing business partners carefully. The second worked out considerably better. We bootstrapped it from scratch, grew it to roughly ten employees, opened an office, and eventually sold it.

The common thread through all of those experiences wasn't the technology itself. It was the act of building. I've always enjoyed creating things. I've always been curious about how things work. I've always found it difficult to walk past a problem without wondering if there might be a better way to solve it.

That's probably why I never completely stopped coding.

As I moved from Engineering into Product Management and eventually Product leadership, I made a conscious effort to stay technically current. Part of it was simple curiosity. Part of it was practicality. I wanted to understand the technologies my teams were working with and have meaningful conversations with Engineering. I never wanted to become the Product leader who walked into a room, declared what should be built, and then had no real appreciation for what it would actually take to build it.

What has changed over the last year isn't that I suddenly started building software again. What changed is that building software became accessible in a way that I've never experienced before.

Like many people, I started experimenting with AI-assisted development tools when they first appeared. My initial experience was underwhelming. I could see the potential, but I could also see the limitations. I'd ask Claude to fix one issue, and it would happily fix that issue while simultaneously creating three new ones somewhere else. It felt less like collaborating with a software engineer and more like playing an endless game of whack-a-mole.

Fast forward nine months and the experience is dramatically different.

What's fascinating to me isn't just the quality of the code generation. It's everything surrounding it. Historically, the coding itself wasn't always the hardest part of software development. Finding the right libraries, installing dependencies, configuring environments, managing source control, standing up infrastructure, deploying applications, and troubleshooting strange configuration issues often consumed more time than the actual feature development.

I can't count the number of times I sat down with the intention of building something useful and ended up spending half the day trying to figure out why a package wouldn't install correctly or why a server refused to cooperate. If you've spent enough time in software development, you've probably experienced the same thing. You start with a feature idea and somehow find yourself four hours later reading GitHub issues written by people you've never met discussing a problem that may or may not be related to yours.

Today, many of those barriers have become dramatically easier to navigate.

The distance between an idea and a working application has collapsed. As a result, I've found myself building more software over the past year than I have in a very long time.

Not all of it has been good.

In fact, I now have what I affectionately refer to as my vibe-coding graveyard. It's filled with applications that seemed like fantastic ideas at the time. Some solved problems that didn't actually exist. Some solved problems that existed but weren't important enough for anyone to care about. Others solved useful problems but in ways that turned out to be less useful than I originally imagined.

The interesting thing is that I no longer view those projects as failures.

Historically, bad ideas were expensive. We gathered requirements. We built business cases. We secured funding. We assembled teams. We spent months building solutions. By the time we learned whether the idea actually created value, we had already invested significant time, money, and energy into making it successful.

Today, I can build a working version of an idea quickly enough to determine whether it deserves additional attention. If the idea isn't good, I move on. If it shows promise, I continue investing. The speed at which we can learn has fundamentally changed.

That lesson has had a profound impact on how I think about Product Management.

One of the more common narratives I hear right now is that AI is going to reduce the importance of Product Managers. The argument usually centers around automation. If AI can generate requirements, write user stories, create prototypes, produce documentation, and generate software, then surely Product Management becomes less important.

I think the opposite is happening.

One of the things AI has reinforced for me is that building software was never the most important part of the job. Determining what should be built has always been the hard part.

Claude can generate code. It cannot determine whether customers care about the problem you're solving. It cannot tell you whether the problem is important enough to prioritize. It cannot tell you whether the resulting experience will delight users or frustrate them. It cannot tell you whether a particular investment aligns with your strategy or whether it should take precedence over ten other competing opportunities.

Those responsibilities remain deeply human.

In many ways, I think they become even more important as execution becomes easier. When the cost of building approaches zero, the cost of building the wrong thing becomes painfully obvious. If every team suddenly has the ability to create software faster than ever before, then judgment, prioritization, and customer understanding become increasingly valuable.

At the same time, I think something else is happening that many people haven't fully recognized yet.

The role itself is evolving.

For years, a significant portion of Product Management involved coordinating. We gathered information. We facilitated conversations. We managed stakeholders. We maintained roadmaps. We documented requirements. We acted as translators between different groups inside the organization.

Those responsibilities don't disappear overnight, but they are becoming less central to the role.

Increasingly, Product leaders have the ability to participate directly in creating solutions. They can prototype ideas. They can build workflows. They can automate repetitive tasks. They can analyze data directly. They can create tools that help them do their jobs more effectively.

I've experienced this firsthand.

At one point recently, I found myself down two Product Managers. A few years ago, that would have created a serious scaling challenge. There are only so many hours in a day, and eventually every leader runs into the same constraint.

Instead of accepting that limitation, I started building.

I wasn't building customer-facing applications. I was building tools to help me do my job. I built automations to streamline portions of the product development lifecycle. I built capabilities that allowed me to better understand how customers were adopting and using our native AI products, giving me insights that previously would have required significant manual effort or Engineering support to uncover. I built workflows that automated activities which previously required manual effort.

The goal wasn't experimentation for experimentation's sake. The goal was finding a way to continue moving forward with fewer resources and the same expectations.

What surprised me wasn't just that these tools worked. What surprised me was how quickly they could be built and how much impact they could have.

That experience reinforced a belief I've been developing for some time. The future isn't about Product Managers becoming software engineers. That's not the point. The point is that Product leaders now have the ability to participate directly in the creation process in ways that weren't practical before.

At the same time, this experience has also given me a much deeper appreciation for modern Engineering teams.

One of the more amusing realizations I had while building these applications was how many of them would have terrified a security professional. Many of them worked beautifully. Some of them probably would have given an auditor a minor heart attack.

AI can help create software. It does not automatically create secure software, scalable software, maintainable software, or production-ready software.

That's an important distinction because we're entering a world where almost everyone can build.

• Product Managers are building.
• Marketing teams are building.
• Sales teams are building.
• Operations teams are building.
• The Executive team is building.

People who would never have considered themselves technical just a few years ago are creating applications, workflows, and automations that previously required Engineering support.

That's creating tremendous opportunities, but it's also creating some misconceptions. One of the biggest is the belief that because someone can create a working prototype over a weekend, Engineering teams should be able to deliver production-ready software at the same pace.

Those are very different activities.

A prototype needs to demonstrate an idea.

A production system needs to survive reality.

Security matters. Scalability matters. Reliability matters. Compliance matters. Maintainability matters. Those challenges don't disappear simply because AI can generate code faster. If anything, they become more important.

For me, though, the biggest lesson from all of this has very little to do with AI. It's about building.

Somewhere along the way, Product Management became heavily focused on process. We built roadmaps. We managed meetings. We coordinated handoffs. We created artifacts. Some of that work was necessary and valuable. Some of it probably wasn't.

What excites me today is that we're regaining something that many of us lost along the way. We have the ability to move from idea to learning incredibly quickly. We can test assumptions rather than debate them endlessly. We can explore multiple paths before making significant investments. We can build something over a weekend and learn more from that experience than we might have learned from weeks of meetings and presentations.

That not only changes how you think, it changes how you prioritize, and it changes how you lead. And I believe it's changing what it means to be a product professional.

For years, I've called myself a Product Manager. Increasingly, I find myself using a different term: Product Builder.

Not because it's trendy. Not because it sounds better on a business card. Because I genuinely believe that's where the profession is heading.

A Product Builder understands customers. They understand business strategy. They understand technology. They're naturally curious. They see a problem and immediately start wondering how it might be solved. They don't stop at documenting opportunities. They explore them. They prototype them. They test them. They learn from them.

Most importantly, they build.

I don't believe every Product Manager will make that transition. Some will. Some won't. There will continue to be traditional Product Management roles for years to come. But I suspect the market will increasingly reward people who combine customer empathy, business judgment, technical fluency, curiosity, and a builder mindset.

The future belongs to builders.

My advice is simple. Build something.

Not because your organization needs another engineer. Build something because the experience will change how you think. It will deepen your understanding of customers. It will improve your judgment. It will help you understand both the opportunities and limitations of these new tools. Most importantly, it may reconnect you with the reason many of us entered this profession in the first place.

The rise of AI didn't create builders. It simply unleashed them.

Wishing you all the best

Mike