Here’s a question nobody in product leadership wants to answer honestly: when was the last time you shipped something yourself?
Not managed a team that shipped it. Not wrote the PRD that led to someone else shipping it. Not sat in the retro and discussed what shipping it taught the team.
You. Shipped. Something.
For most senior product leaders, the silence that follows is its own answer. We’ve built careers on the abstraction layer — the translation work between business and engineering, the roadmap ceremonies, the stakeholder alignment. We became fluent in the language of building without ever doing much of the building. And for a long time, that was a perfectly viable career strategy.
That time is ending.
What I Built — and How
I want to be precise here, because the framing matters.
I didn’t “learn to code.” That’s not what’s happening, and that framing undersells what’s actually possible — and what’s actually required — right now.
What I learned to do is direct. I set up Claude Code as my primary development environment and started treating it the way a good senior director treats a strong IC: clear intent, specific requirements, tight feedback loops, and enough domain fluency to catch when the output is drifting from the goal.
All of this happens outside my day job entirely. These are personal side projects — nights, weekends, hobby builds. My team isn’t the test environment. I am. I’m the one running experiments, hitting walls, and learning what these tools actually do when you push them past the polished demo.
That’s intentional. The learning has to be real, which means the stakes have to be real, even if they’re small. You can’t develop genuine judgment through observation.
The output so far: I built and deployed dashview, an open-source real-time intelligence dashboard on Vercel with serverless functions. I set up home-base, a private portfolio repo that orchestrates how these projects connect and scale. These are live, version-controlled, deployed systems — not Notion docs with wireframes attached.
Here’s what surprised me most: the bottleneck was never the code. It was specification. Knowing exactly what you want to build, why it should work a particular way, which edge cases matter, and what tradeoffs you’re willing to accept. That is, in every meaningful sense, a product thinking problem. Years of writing PRDs and running discovery sessions turn out to be excellent training for directing an AI pair programmer. The skills transfer more than most people expect.
What Building Actually Changed
Something shifts when you’re accountable for your own ideas in production.
The gap between “we should build something that does X” and “I am building something that does X” is wider than it looks from the outside. Suddenly you’re making decisions you’ve spent a career handing off: What does this data model actually need to look like? What happens when the API call fails at 2am? Is this the right abstraction, or am I building technical debt into a side project nobody uses?
The credibility shift in my professional conversations has been real. Not because I can write a React component from scratch — I can’t, and that’s beside the point — but because I now have felt knowledge of what deployment actually involves. When someone on my team says “that’s harder than it looks,” I have a reference point. I’ve been the person who thought something would take two hours and watched it consume a weekend.
But the more consequential shift has been in how I coach.
When I’m working through a hard technical or architectural decision with someone on my team, I now bring genuine reference points — not borrowed credibility from conference talks or case studies, but actual experience of having made those decisions myself, at small scale, and lived with what followed. I ask sharper questions. I can distinguish between someone who’s pattern-matching to a familiar solution and someone who’s actually reasoning through the problem. I can teach the thinking behind good decisions, not just assess whether the output looks right.
That’s the loop: build on the side, translate it into how I lead. The side projects are the laboratory. The day job is where the learning compounds into something that actually matters.
The Part Nobody Wants to Say Out Loud
AI is not coming for engineers first. It’s coming for the abstraction layer — the coordination, synthesis, and translation work that defined the modern product management role and justified the career ladder we all climbed.
If your primary professional value is converting stakeholder input into a roadmap and managing the handoff to engineering, you should be paying close attention. That workflow is becoming increasingly automatable, and the tools doing it are improving on a quarterly cadence.
What isn’t automatable is judgment forged by consequence — the ability to look at an architecture decision and know it will create a crisis in eighteen months. The instinct that tells you which stakeholder objection is a genuine blocker and which is theater. The taste that only comes from having shipped something, watched real users ignore it, understood why, and built something better.
These things require skin in the game. AI can accelerate execution. It cannot manufacture the scar tissue that makes judgment trustworthy.
The leaders who will struggle are those treating AI as a faster way to do their existing job. The leaders who will thrive are those using AI to fundamentally expand what their job is — pushing their ceiling from strategy into execution, from vision into production. Not replacing engineers. Becoming the kind of leader who can meet them in the work.
The Roles Are Converging. This Is Not a Trend Piece.
Let me state this plainly: the boundaries between Product, Engineering, and Data are structurally collapsing — not because any one discipline is winning, but because AI is dissolving the interfaces between them.
Specialization was the right bet for decades because the complexity at each layer was high enough to justify it. The PM owned the what and why. The engineer owned the how. The data scientist owned the signal. Handoffs were the tax you paid for depth.
AI is redistributing that complexity. A product leader with Claude Code can now produce a working prototype that would have required a two-week sprint. An engineer with strong prompting instincts can do discovery work that previously needed a dedicated researcher. A data analyst can build and deploy pipelines that formerly required a data scientist. The tax is dropping, and with it, the justification for rigid role separation.
This is not “AI makes everyone marginally better.” This is a structural collapse of the interfaces we built entire career frameworks around. What emerges on the other side is a new kind of operator — someone who moves fluidly across the full product development stack. Not an expert at every layer, but fluent enough at each to direct AI through it and discerning enough to recognize when the output is wrong.
I’ve started calling this Full Stack Product. Not full stack in the engineering sense. Full stack in the sense that you can carry an idea from insight to infrastructure — from “this is the problem worth solving” to “here is the live system solving it.”
That’s a new job description. Most organizations haven’t written it yet. Most career ladders don’t accommodate it. And right now, almost nobody actually holds it.
Lean In Now, or Concede the Ground
The window for comfortable, gradual adoption is closing faster than most leadership teams want to acknowledge.
The people who are actively building — getting real reps with AI-directed development, developing firsthand intuitions about where these tools excel and where they break down — are accumulating an advantage that compounds. Every project sharpens their ability to specify. Every deployment teaches them something about the gap between what AI produces and what good actually looks like. Every shipped thing builds the judgment that makes them harder to replace.
The people who are waiting — observing from a comfortable distance, letting their teams accumulate the hands-on experience while they synthesize the learnings secondhand — are falling behind in ways that won’t be legible until they suddenly and obviously are.
This is not a call to become a software engineer. The new floor isn’t syntax — it’s the ability to direct AI through the full product development cycle with enough judgment to catch bad outputs, enough vocabulary to communicate credibly with technical peers, and enough firsthand building experience to lead teams through a world where the old role definitions no longer hold.
That’s the gap I’m working on. With Claude Code. With personal projects. With the specific, irreplaceable discomfort of making real decisions that have real consequences, even at small scale.
Not because I want to become a developer.
Because in a world where the abstraction layer is being automated, altitude is no longer the asset it once was. And I’d rather figure that out now, on my own terms, than be forced to reckon with it later.
Thanks for reading The Data Product Agent! Subscribe for free to receive new posts and support my work.
The version of product leadership that sits comfortably above the work — managing up, coordinating handoffs, translating without touching — is going to face real pressure in the next few years. The tension between climbing and staying grounded doesn’t resolve on its own. The leaders who find their footing will be the ones who chose, deliberately, to close that distance before they were forced to.
That’s what I’m building toward. One side project at a time — some of which may not stay side projects for long.
Ethan writes about data, AI, and product leadership at the intersection of strategy and execution. He leads a product and data team in the entertainment industry and is quietly building a portfolio of AI-native products for the teams he writes about. Follow along at “The Data Product Agent” on Substack.