Product Leaders Who Build: What AI Is Changing About the Work

I have spent more than two decades working in product roles inside large, regulated organizations. I have produced the roadmaps, written the Jira tickets, worked through complex delivery programs, and partnered with engineering to bring products to life.

In February 2026, a peer introduced me to VS Code and GitHub Copilot at work. I cannot thank them enough.

They showed me how easy it was to begin with an idea and use natural language to turn it into working code. The moment I saw how capable it was, I immediately began thinking about what I could build, what my team could build, and how I could lead them into this new way of working. I knew this would change the game. The possibilities for both my own work and the team I lead excited me tremendously. That single moment lit a fire inside me that had not been lit in quite a while.

Leading and building

A product leader who builds can take an idea to a working prototype and bring that idea to life. In some cases, those prototypes can provide real, tangible value and drive business outcomes.

Building does not replace product leadership or reduce it to hands-on execution. It expands how a product leader can lead. The leader can make an idea tangible, help the team see what is possible, and develop the team's ability to work in a new way.

This elevates the work beyond producing roadmaps and written Jira tickets while keeping leadership at the center. Instead of sitting in the back seat with engineering, a product leader who builds can sit in the passenger seat.

I cannot write a single line of code on my own. That has not stopped me from building working software. AI has changed what I can contribute and how quickly I can test whether an idea has value.

A prototype is more than a better handoff

Working prototypes enable faster feedback from users and a faster iterative development process. Because AI makes it possible to generate more prototypes, product teams can test more versions and more capability flavors before committing to a direction.

But this is about more than prototyping. It is the ability to create independently, or as a product and UX team, without requiring engineering to build every early version.

That changes the questions we can answer.

Product can explore how to solution a problem and test whether it can technically be done. The question can then move from “Can this technically be done?” to “Can the team build and productionize it?”

In some cases, product can prove the underlying logic through working software before engineering takes it forward. Most importantly, it gives product a playground to test and improve its own ideas.

It also preserves context. The product owner can express the idea directly through the working software instead of relying entirely on an engineer to translate their own version of that idea from a written Jira ticket.

Learning the models is part of the work

Learning the AI models, their behavior, and the different tools and harnesses is fundamental. Models behave differently and have different use cases, so knowing where to start is helpful.

In my experience, all of them are highly capable. They all benefit from additional tuning, but in different ways.

OpenAI's GPT models are excellent at coding, but they tend to need more direction. They benefit significantly from well-defined instruction Markdown files that provide baseline rules aligned with your preferences. All models benefit from thinking about skills and agents before starting anything large, but GPT tends to need more help.

Claude and the Opus-class models tend to hold context better and are more likely to clarify before executing. They still benefit from a strong CLAUDE.md file and a deliberate approach.

The model is only part of the equation. Learning to use these models in their native applications, through native command-line tools, and inside an integrated development environment such as VS Code or GitHub Copilot is also important.

That is particularly useful at home because it resembles how many people are likely to access these models inside a corporate environment, where there may be more restrictions and more need for manual intervention or creativity.

The AI operator matters more than the model

At work, the model may approach a problem as if every tool and integration it knows about is available. The real environment may have no shared repository, no simple application-sharing path, limited tools, and controls that the model does not understand.

You have to understand your environment, define a custom approach, give the model the missing context, and then build within those constraints. This type of thinking is what separates a product builder from an AI user.

At home, I can experiment more freely with providers, agents, skills, and tools. That freedom has helped me build projects such as Exile Forge and FlowIt, and it keeps my skills current. At work, the challenge is translating those techniques into a more constrained environment and finding an approach that can operate within it.

Both forms of experience matter.

The largest constraint is the operating model

One of the biggest constraints to making AI genuinely useful is the operating model.

The tools and techniques are evolving rapidly. Learning the skills and creating an operating model that uses them effectively is a significant challenge. Corporate data landscapes make it harder. Many organizations do not have a semantic layer or the other foundations needed to help AI interpret their data consistently.

Governance must also keep up with tool and capability changes. Internal adoption has to move beyond isolated experimentation. In a corporate setting, properly defined skills may become even more important because they can encode how work should be performed inside the organization's actual boundaries.

It is critical to understand both worlds: keep up with the latest technology through hands-on experimentation, but also learn how to navigate corporate tools, governance, data, and constraints efficiently.

Product, engineering, and UX will move closer together

I can only see the most effective teams ending in a world where product and engineering become more closely joined together. It is not only product and engineering. UX must be part of the model as well.

Product should be positioned to play a larger role in functional proofs of concept and in delivering near-production-grade usability and functionality. Engineering can spend less time asking whether something reflects the user's requirement and more time asking whether it is scalable, secure, resilient, maintainable, and ready to operate in production.

The result will depend on the skills across all three functions. The ideal team will use the strengths of product, engineering, and UX instead of defining the work through rigid boundaries.

The biggest struggle today is that the operating model is not defined. There are many possibilities, and teams are moving in different directions. That creates friction even when product has proved that a difficult capability can work.

Leaders need to become hands-on

In my experience, many people still do not fully grasp AI because they are not actively hands-on with it.

Many leaders are responsible for leading the AI charge but lack the direct experience required to understand what their teams need. That contributes to slower adoption and to the friction between existing processes and new capabilities.

Adoption within engineering is also uneven. The engineering operating model needs to evolve alongside the product operating model. We need to redefine what it means to operate across both product and technology while balancing the change with appropriate risk management and governance.

Leaders do not need to become expert engineers. They do need enough direct experience to understand what the technology can do, where it fails, and what their teams need in order to use it responsibly.

Why I am sharing this

I want people to be encouraged to try.

You do not have to be an engineer to be successful with these tools—not even close. I cannot write a single line of code without AI, but I can take an idea, work through the hardest parts, and turn it into functioning software.

I want to share how to get started, what I learn about the models and the operating model around them, and how people can apply these practices in their current roles.

This is not a finished answer. The technology is moving too quickly, and the operating model is still being formed. I plan to keep building, testing, and sharing what I learn along the way.