Traditional product management starts before the build. Vibe coding doesn’t. So the product layer has to move.
For most of software history, product management had a simple assumption baked into it:
First, you decide what to build.
Then you write it down.
Then somebody builds it.
That assumption shaped almost every PM tool we use today. Requirements came first. Tickets came next. Work moved across a board. Shipping was the end of the process.
That made sense when building was expensive.
When code took weeks, meetings were cheaper than mistakes. You wanted to plan before touching the system because touching the system cost real time. A feature spec was not just documentation. It was insurance.
But vibe coding changes the order.
When Cursor can scaffold the first version in twenty minutes, planning no longer has to happen entirely before building. In many cases, it can’t. The product is discovered while the builder is already inside the code.
The question is no longer:
“How do we fully define the work before anyone starts?”
The question is:
“How do we keep the knowledge generated while building from disappearing?”
That is the job of Retroactive PM.
Traditional PM is front-loaded
Traditional PM is built around a front-loaded workflow:
- Define the requirements
- Break them into tickets
- Prioritize the backlog
- Assign the work
- Build against the plan
- Ship
The plan sits upstream from the build. The work is supposed to conform to what was decided earlier.
That workflow works best when you have multiple teams, expensive coordination, long delivery cycles, and high cost of change. If ten people need to stay aligned for six weeks, the planning layer matters because it prevents everyone from walking in different directions.
But that is not how a lot of AI-first builders work.
A solo founder does not always know the feature before opening Cursor. A two-person team does not always have a sprint plan. An indie hacker might discover the actual product by prompting, deleting, rewriting, and shipping three rough versions in a weekend.
The old workflow says:
Plan → ticket → build.
Vibe coding often looks more like:
Build → realize → decide → adjust → ship.
The product thinking is still happening. It just moved.
It moved into AI chats. Into half-finished Claude threads. Into Cursor suggestions. Into PR descriptions. Into the moment where you say, “Actually, v1 should not include teams,” and then forget you said it.
Traditional PM assumes the important decisions happen before the work starts.
Vibe coding proves that many of the important decisions happen because the work started.
The build process generates product knowledge
This is the part that is easy to miss.
When you build with AI, you are not just producing code. You are producing knowledge about the product.
Cursor suggests a smaller v1 than the one in your head. That is product knowledge.
Claude explains two possible architectures and you choose the simpler one because speed matters more than control. That is product knowledge.
You cut a settings page because it is not needed for launch. That is product knowledge.
A PR ships an unplanned improvement that changes the onboarding flow. That is product knowledge.
You decide that teams belong in v2, not v1. That is product knowledge.
None of this looks like a traditional ticket. Most of it is not even a task. But it is the stuff that makes the product coherent.
The problem is that the places where this knowledge appears are terrible places for it to live.
AI chat is not a product memory. Git history is not a product memory. A closed Cursor tab is definitely not a product memory.
They are places where knowledge is generated.
They are not places where knowledge survives.
That gap is what Retroactive PM is designed to close.
What Retroactive PM means
Retroactive PM is the practice of capturing what the build process reveals, turning it into durable product truth, and reusing it across future work.
More simply:
Build first. Capture what matters. Reuse it next time.
It is not “write tickets after the fact.”
That would be pointless. Nobody needs a beautiful backlog of work that already happened.
Retroactive PM is about capturing the product truth that the work exposed:
- What shipped
- Why it shipped that way
- What changed from the original idea
- What got cut
- What moved to later
- What decision the builder made mid-flow
- What future plan appeared during the build
- What the next AI session needs to know
The artifact is not bureaucracy. The artifact is memory.
A traditional ticket says:
“Do this work.”
Retroactive product truth says:
“This is now true about the product.”
That distinction matters.
Because vibe coders are right to reject heavy planning rituals. They do not need to turn every idea into a ticket before they are allowed to explore. They do not need to stop the build so they can perform product management theater.
But they do need the product to remember what the build taught them.
The new loop: build → capture → reuse
Retroactive PM has a different loop from traditional PM.
Not:
Plan → ticket → build → close.
But:
Build → capture → reuse.
1. Build
You start where vibe coders naturally start: in the work.
You open Cursor. You ask Claude. You try the idea. You generate the first version. You let the product become clearer by touching it.
This is not a failure of discipline. This is the point.
AI makes exploration cheap enough that building can become a form of thinking.
2. Capture
As the build creates knowledge, the important parts get pulled out of the places where they would otherwise disappear.
A v2 idea becomes a future mission.
A scope decision becomes a product boundary.
A shipped PR becomes a changelog-ready summary.
A tradeoff becomes a decision log entry.
A changed feature becomes updated product truth.
The capture does not have to interrupt the builder. Ideally, it happens alongside the build — proposed, reviewed, and accepted when useful.
3. Reuse
The captured truth becomes useful the next time you build.
Cursor gets better context.
Claude does not need the whole product re-explained.
A teammate can understand why the feature exists.
Your launch copy reflects what actually shipped.
Your roadmap includes the v2 idea that would have died in a chat thread.
This is where the value compounds.
The first capture saves a note.
The tenth capture creates memory.
The hundredth capture becomes a living product model that every tool can work from.
Retroactive does not mean careless
There is an obvious objection here:
“Isn’t this just an excuse to avoid planning?”
No.
Retroactive PM is not anti-planning. It is anti-fake-planning.
Sometimes you know what needs to happen before you build. Great. Write the mission. Define the scope. Give your AI tool the context and let it execute.
But sometimes you do not know yet. Sometimes the fastest way to understand the product is to build a rough version and see what breaks. Sometimes the best product decision appears halfway through a debugging session.
A good product layer should support both modes.
Plan ahead when the plan is real.
Capture retroactively when the truth emerges from the work.
The mistake is pretending all product thinking must happen before code exists. That was never completely true, and AI makes it obviously false.
Why this matters more with AI
Retroactive PM is not just a nicer workflow. It becomes necessary because AI accelerates both creation and forgetting.
A human team might take two weeks to generate ten important product decisions.
An AI-first builder can generate ten in an afternoon.
The velocity is intoxicating. But the memory loss scales with it.
Every new AI session starts colder than it should. Every tool switch drops context. Every unrecorded decision becomes something you have to rediscover later. Every shipped feature without rationale makes the product harder to explain, market, refactor, or hand off.
AI makes the build faster.
It does not automatically make the product more coherent.
In fact, without a product memory, it can make the product less coherent faster.
That is the hidden cost of vibe coding: not bad code, but lost truth.
Retroactive PM is how you keep the speed without letting the product dissolve into chat history.
What HeyQ is building
This is the pattern HeyQ is built around.
HeyQ gives your product a living truth: the vision, scope, decisions, boundaries, missions, and history that describe what the product is and why it is that way.
Q keeps that truth current as you build.
Not by forcing you to write perfect specs before touching code.
Not by turning vibe coding into Jira with better branding.
By capturing the knowledge your build already generates and making it reusable:
- AI chats can become structured updates
- PRs can become missions, decisions, and changelog-ready summaries
- Scope changes can become reviewable diffs
- Future plans can survive the session where they appeared
- Cursor and other AI tools can read from the same product truth instead of starting from scratch
The point is not to slow builders down.
The point is to stop the build process from throwing away its own intelligence.
The bottom line
Traditional PM was designed for a world where planning came before building.
Vibe coding creates a world where building often comes before planning is complete.
That does not eliminate product management. It moves it.
The new product layer has to sit beside the build, not in front of it. It has to capture what changed, what shipped, what was decided, and what should be remembered next time.
That is Retroactive PM.
Build first when that is how you work.
But do not build without a memory.
Want to try Retroactive PM?
Start a HeyQ project from an idea, a doc, or your existing repo. Build however you build. Q will help turn what you discover into product truth that survives the next session.
