For more than two decades, I’ve led digital products by setting direction, organizing teams, making tradeoffs, and staying accountable for the outcome.
Building my own website with AI agents brought me closer to the work in a way I hadn’t experienced in years.
What began as a portfolio became a small digital platform. I built custom tools for publishing photography from Lightroom, managing content from Threads, generating context-aware response drafts, and keeping human review in place before anything becomes public.
I expected AI to make delivery faster. It did.
What I didn’t fully expect was how much the experience would change the way I think about product leadership.
The distance between an idea and evidence got shorter
Traditional product development often puts several steps between an idea and something people can actually use. A requirement moves through discussion, documentation, design, estimation, implementation, and review before the team learns whether the original thinking holds up.
AI agents can shorten that distance considerably.
An idea can become a working version within the same product conversation. That version is rarely finished, but it makes the decisions tangible. I can see where the experience is confusing, where the requirement was incomplete, or where an apparently simple change creates consequences elsewhere in the system.
The loop becomes tighter: define the intended outcome, make something real, inspect it, and refine it.
That reduced the amount of time I spent debating hypothetical solutions. It also reminded me that working software is not simply the output of product thinking. It is one of the best tools for product thinking.
Clear direction matters more when output arrives quickly
AI can produce a polished version of the wrong thing remarkably fast.
Vague direction does not disappear because the implementation is accelerated. It simply turns into the wrong experience sooner.
I found myself becoming more precise about the problem, the user, the constraints, and what I would accept as complete. Not because every task needed a longer requirements document, but because the important decisions needed to be clearer.
What are we trying to improve? What must remain true? Where is human judgment required? What would make this useful rather than merely impressive?
These are familiar product questions. Agentic development makes their value much more visible.
The quality of the result depends heavily on the quality of the direction. When implementation moves quickly, ambiguity reaches the customer quickly too.
Speed makes restraint more important
When the cost of trying an idea falls, it becomes easy to build things simply because they are possible.
I could add another integration, automate another task, or create another management tool. But every new capability also creates something to operate. It introduces maintenance, permissions, failure points, privacy considerations, and another claim on attention.
That made prioritization more important, not less.
I began asking whether a capability meaningfully improved the experience or merely demonstrated that it could be built. Would I continue using it? Could I support it? Was AI appropriate for the task? What should remain intentionally manual?
Faster delivery rewards curiosity. Without discipline, it can also produce a very busy product.
The ability to build more does not remove the responsibility to choose carefully.
Inspection is part of creation
Building the site required more than producing code that worked once.
I had to test real content, responsive behavior, data synchronization, permissions, error states, publishing controls, and the experience of operating the tools over time. I needed to see what happened when information was missing, an external service responded differently than expected, or a workflow reached a decision that should remain human.
Nothing is complete simply because it compiled or looked convincing in one viewport.
That changed how I thought about review. It was not a final gate after the creative work. Inspection was part of the creative work.
AI agents could help implement features, diagnose problems, and test behavior. They could not own the standard. They could not decide whether a tradeoff was acceptable, whether the experience felt right, or whether something was ready to represent me publicly.
For writing, social responses, and publishing decisions, I deliberately kept human approval inside the workflow. The technology could accelerate preparation. Accountability stayed with me.
Technical fluency feels different
Product leaders do not need to be the deepest technical expert in the room. But working this closely across interfaces, data, APIs, automation, security, and deployment gave me a more complete understanding of how product decisions travel through a system.
That understanding changes the questions I ask.
Where does this information originate? What else depends on it? What happens when the connection fails? Is the decision reversible? Are we creating a useful capability or a permanent operational commitment?
Technical fluency, in this context, is not about writing every line of code. It is about understanding the shape of the system well enough to make better product decisions.
What changed about how I lead
I still believe strongly in multidisciplinary teams. Building with AI did not convince me that product leaders should replace designers, engineers, analysts, writers, or subject-matter experts.
It did convince me that leaders can participate more directly in turning ambiguity into something testable.
I now want working evidence earlier. I prefer shorter feedback loops. I pay more attention to acceptance criteria, operating implications, and the difference between a reversible experiment and a capability the organization will have to sustain.
The model I used was human-led and agent-accelerated. I owned the vision, priorities, experience, voice, security, quality, and release decisions. AI expanded the speed and range of what I could deliver.
That distinction matters.
AI-native product leadership is not about standing closer to the code for its own sake. It is about standing closer to the consequences of the decisions being made.
When an idea can become real this quickly, leadership matters more, not less. Someone still has to decide what deserves to exist.