Why I'm Killing Product Release Notes (And What Comes Next)

Why I'm burning the ships and moving from observer to architect. Plus: the immediate shift you can make in your own work this week.

For the last couple of months, I’ve been building in public. The AI Advent Challenge landed hard. SheBuilds, Lovable.ai’s global buildathon, validated the framework. A new tool, CollabStack, is coming.

But I realized something: I’m spending all my energy building, then trying to explain what I built in essays that still sound like I’m theorizing about it.

Meanwhile, I’m publishing articles about how the PM role is evolving. How we need to move from Jira-ticket management to architectural thinking. How the fastest-moving teams are the ones where PMs prototype their own ideas.

The gap became unbearable.

Here’s the truth: I can’t write about the future while this newsletter stays anchored in the past. Product Release Notes was built to document what happened, to analyze company strategies, to help you understand successful products that were already made.

That’s no longer what I do.

The industry moved. I moved. The publication didn’t.

The Gap Between Writer and Builder

There’s a specific moment when you realize you’ve outgrown your own framework. For me, it came while building the AI Advent Challenge.

I had just published “Product Management Already Evolved: You’re Just Now Realizing It.” In that article, I described two games: the shrinking world of traditional PM (writing specs, managing backlogs, translating between teams) and the expanding world of the Technical Architect (building prototypes, architecting systems, making decisions through code).

Then I went and actually played both games simultaneously.

I was writing articles about why the “Idea Guy” PM is becoming obsolete. And every Thursday evening, I was that Idea Guy, except I wasn’t asking engineering for permission. I was opening Lovable, describing what I wanted, and having it built before my coffee got cold.

The contradiction was screaming.

My audience picked up on it too. The articles that landed hardest weren’t the strategic frameworks. They were the ones where I showed the actual friction: “When you can ship an app for the price of a dinner in a weekend, you aren’t just a PM. You’re a high-agency unit of impact.”

That single observation generated more conversation than entire 3,000 word analyses about agentic systems. People don’t want to read about the future. They want to see someone living it.

Why Release Notes Don’t Capture What’s Happening

Here’s what a “release note” implies: something is finished, documented, and you’re reading the summary.

But the real work isn’t in the release. It’s in the decision that precedes it. It’s in the prototype that proves the concept. It’s in the moment when you realize your spec was wrong because you built it and discovered what you actually needed.

Release notes are retrospective. They’re what happened yesterday. They’re artifacts of a process where someone else did the building and you’re explaining it.

That’s not what I do anymore. That’s not what the best PMs are doing anymore.

A colleague on Substack, The Ed, just published something that crystallized this for me. He wrote about how “building becomes cheap” but “discovery stays hard.” As the cost of implementation collapses, the real PM work shifts from “how do we build this?” to “what are we actually trying to solve?” The PMs getting left behind are the ones still writing specs. The PMs pulling away are the ones figuring out what matters in the first place.

But here’s something I’m realizing: discovery doesn’t happen in a conference room. It happens while building. When you prototype, you immediately discover what you misunderstood. When you architect systems, you uncover coordination problems you couldn’t have theorized. The best discovery happens in the tension between what you imagined and what the system actually does.

That’s where I want to work. And that’s where this newsletter needs to follow.

The Car Race Metaphor Isn’t Metaphor Anymore

Twelve months ago, I wrote about the PM role like we were still in the pit crew phase. Careful. Measured. Optimizing for precision and stakeholder alignment.

We’re not in the pit anymore.

The tech industry in early 2026 is a car race. We used to be mechanics, carefully tuning the engine in a controlled environment, arguing about estimation points and velocity. Now we’re behind the wheel at 200 miles per hour, making split-second architectural decisions in real time.

The scary part? You don’t get to see the track before you start racing. You’re building the car while you’re driving it. You’re learning the system through feedback. You’re failing in public and iterating so fast that by the time anyone notices the failure, you’ve already shipped the fix.

This isn’t metaphor anymore. I’ve lived it.

I sat in a meeting where a stakeholder asked for a feature. In the old world, I would have written a spec, scheduled refinement sessions, estimated complexity, debated technical debt. Instead, I listened for 20 minutes, went to lunch, came back, showed them a working prototype, got feedback, and shipped a refined version by end of day.

The traditional PM process, the one “Product Release Notes” was built to support, isn’t just slower. It’s a different sport. You can’t play chess while someone else is playing real-time strategy. The game changed and the handbook didn’t.

What This Shift Actually Means for Your Work Right Now

Here’s what I’ve learned: the fastest PMs aren’t the ones with the best strategies. They’re the ones who can show, not tell.

Before this shift, my week looked like this:

• Monday: Stakeholder asks for feature

• Tuesday-Thursday: Write spec, schedule refinements, debate scope

• Friday: Engineer says “I need clarification on three things”

• Following week: More meetings

Now it looks like this:

• Monday: Stakeholder asks for feature

• Tuesday afternoon: I prototype it (90 minutes in Lovable)

• Tuesday evening: Stakeholder sees working prototype, gives real feedback (not theoretical feedback)

• Wednesday: Engineer has something concrete to build from, scope is clear

• Thursday: Feature ships or decision is made based on evidence, not argument

---

Here’s what actually changes:

👩🏼‍💻 Role: The Observer (Analyzing) → The Builder (Leading)

📱 Output: Documents & Analysis → Prototypes & Evidence

🎬 Audience: Process-Oriented PMs → Outcome-Oriented Leaders

🎶 Tone: Helpful & Structured → Literary & High-Agency

🤖 Your Weapon: Specs & Slide Decks → Clarity & Working Prototypes

🗣️ How You Win Arguments: Through authority and position → Through evidence and demonstration

---

The difference isn’t that I work faster. It’s that I work smarter because I can show the constraint instead of theorizing about it.

When a stakeholder sees a prototype, they stop asking “can we build this?” and start asking “should we build this?” That’s the moment clarity takes over from committee.

Your turn: Pick one feature request that’s been stuck for more than two weeks. The one where you keep having the same conversation. Instead of scheduling another meeting to discuss it, spend 90 minutes building a prototype. Don’t make it perfect. Make it real enough that someone can interact with it.

Then show it to the stakeholder.

Watch what happens to the conversation. That’s what Prompt-Led Product is built on.

What I’m Actually Afraid Of

Honestly, I’m not afraid of rebranding. I’m afraid of being irrelevant.

Not personally irrelevant to you. Professionally irrelevant to the future I’m describing.

If I keep writing analysis about how the PM role should evolve while sitting safely in the analyst chair, I become the very thing I’m critiquing. The observer. The person who understands the game but doesn’t play it.

The best voices in AI and product right now aren’t the ones explaining what’s happening. They’re the ones making what’s happening. They’re building. They’re shipping. They’re showing, not telling. Just look at the incredible PMs who have created their own future. Tal Raviv Paweł Huryn Aakash Gupta Elena Verna Claire Vo Karo (Product with Attitude)

I can feel the difference when I write. Articles where I’ve actually built something, where I can say “here’s what I discovered when I prototyped this,” they land differently. They create conversation. They give people permission to try.

Articles where I’m theorizing about architecture without having architected anything recently? They fall flat. They read like commentary. Like I’m watching from the stands instead of driving the car.

The honest truth: I don’t want to be a commentator on the future of product management. I want to be someone who’s actively shaping it. And that requires showing my work, not just analyzing other people’s work.

Burning the Ships

So I’m officially rebranding this publication.

“Product Release Notes” is ending. The URLs will change. The header will change. The entire framing will shift from “Here’s what happened in product” to “Here’s what’s happening right now, and here’s how to build it.”

I’m moving to Prompt-Led Product.

This isn’t just a name change. It’s a promise to move at the speed of possibility, not the speed of committee. To being the person in the car, not the commentator in the booth.

Product management has changed. The way we write better PRDs, how we manage stakeholder expectations, and the best practices for roadmapping within constraints are still the same, but we’ll see it from a different angle.

Clarity is now your winning tool. Instead of managing expectations through slide decks, I’m teaching you to lead through architectural clarity and working prototypes. A system schema kills a 3-hour debate in 30 seconds. A working prototype answers questions that PRDs can’t. Evidence wins arguments that slides never could.

More importantly, it will show proof. Real examples. Real prototypes. Real decisions made under real constraints.

The Discomfort Is the Signal

Here’s what I’ve learned from building instead of writing: the best insights come from friction.

When you’re actually building something, you discover what you don’t know in real time. You hit walls. Your mental models break. You have to invent solutions because the playbook doesn’t exist yet.

That friction is where the real learning lives.

I’ve been writing about the future of product management from a place of relative comfort. I’ve analyzed trends. I’ve synthesized frameworks. I’ve been thoughtful and measured and careful.

But I haven’t been uncomfortable enough until now.

The PMs and product architects pulling away from the pack right now aren’t comfortable. They’re scared. They’re building things that might not work. They’re making decisions with incomplete information. They’re shipping code that might break in production. They’re learning by doing, not by reading.

That’s the game I want to play. And I can’t play it while managing a publication built for a different era.

What This Means for You

If you’ve been waiting for someone to show you how to actually do this, how to move from traditional PM frameworks to building with AI, how to architect systems instead of managing backlogs, how to become the kind of high-agency builder that companies will pay anything to keep, then the real content starts next week.

I’m done with release notes. I’m ready to show you the clarity.

This is scary to publish. Because it’s a commitment. It’s saying: “I’m moving all in on this future, and I’m inviting you to move with me.”

But staying comfortable would be even scarier.

The industry is racing. I’m done watching from the pit crew. I’m getting in the car.

---

One more thing: If you’re reading this and thinking about making a similar shift in your own role, from manager to builder, from planner to architect, drop a comment. I want to know what’s holding you back. Because that friction point? That’s where the real work begins.

See you on the other side. 🚀