If Retroactive PM names the model, this is the operating loop: build with AI, capture what the work teaches you, and reuse that truth in the next session.
The old product workflow was easy to draw.
Plan → ticket → build.
It was not always fun. It was not always fast. But it was legible.
A product manager wrote the requirement. The team broke it into tickets. Engineers built against the tickets. The board showed progress. The plan lived upstream from the work.
Vibe coding breaks that diagram.
A builder opens Cursor with a rough idea, asks for a first pass, changes direction three times, cuts half the feature, accepts an unexpected suggestion, ships the smaller version, and only afterwards understands what the product should have been all along.
That is not a broken workflow.
That is the workflow now.
But it needs a new loop.
Not plan → ticket → build.
Build → capture → reuse.
This is the practical version of Retroactive PM. It is how AI-first builders keep moving fast without letting every decision disappear into a chat thread.
The problem with stopping at “build”
Most vibe coding workflows have one step:
Build.
That is the magic and the trap.
You can go from thought to working software faster than ever. You can test ideas before you fully understand them. You can ask Cursor for the version you could not quite explain, then react to what it gives you.
For builders, this feels like freedom.
But a build-only workflow has a hidden failure mode: the product gets smarter, but the product memory does not.
The app changes. The code changes. Your understanding changes.
But the durable product layer stays blank.
So the next time you open an AI tool, you are back to narrating the product from memory:
- “We decided not to support teams yet.”
- “Actually, onboarding changed last week.”
- “The billing flow is weird because we cut subscriptions from v1.”
- “There was a better approach Claude suggested, but I cannot find it.”
- “Cursor gave me a v1.0.1 plan after the last feature discussion. Somewhere.”
The build moved forward. The context did not.
That is why build → capture → reuse matters.
The goal is not to slow down the build. The goal is to make sure the build leaves memory behind.
Step 1: Build
Start where the energy is.
Open Cursor. Open Claude. Open Lovable. Open v0. Start with the product truth you have, even if it is incomplete.
This is important: build → capture → reuse does not mean “start with nothing.”
You still want a baseline:
- Who the product is for
- What problem it solves
- What is in scope now
- What is explicitly not in scope
- What decisions already exist
- What constraints matter
That baseline is your starting product truth.
In HeyQ, that baseline is available to your AI tools through MCP, Cursor rules, and skills. Cursor or Claude can be instructed to check the summarized product truth before they help you scope or build. You should not have to paste your whole product backstory into every new chat.
But the baseline does not need to be perfect before the build begins. In AI-first development, product truth often starts as a rough sketch and becomes sharper because you build.
During the build, your job is not to preserve the original plan at all costs. Your job is to notice when the work teaches you something worth saving.
Useful signals include:
- Cursor suggests a simpler version than the one you planned
- Claude explains a product tradeoff you had not considered
- You cut a feature because it is not needed for launch
- You add an unplanned behavior because it obviously improves the flow
- A bug fix reveals a deeper product rule
- A PR changes what the product actually does
- You find yourself explaining the same context to AI for the third time
Those are not distractions from the work.
Those are the work producing product knowledge.
Step 2: Capture
Capture is the step most builders skip.
Not because they are careless. Because the existing tools make capture feel like paperwork.
If capturing means stopping the build, opening Jira, writing a ticket, choosing an assignee, setting a status, adding acceptance criteria, and pretending this was planned all along — of course builders will not do it.
That is old-world capture.
AI-first capture is different.
You are not trying to document every keystroke. You are extracting the small number of things future-you, your teammate, or your next AI session will need to know.
Capture the things that change the product truth.
Capture decisions
A decision is any choice that explains why the product is the way it is.
Examples:
- “Teams are out of scope for v1 because solo builders are the first target.”
- “We chose Clerk because speed matters more than owning auth infrastructure.”
- “We are keeping onboarding lightweight because the first session should reach value fast.”
If the decision would help you avoid re-litigating the same question later, capture it.
Capture scope changes
Vibe coding constantly changes scope.
Sometimes you cut. Sometimes you expand. Sometimes you move something to later.
Examples:
- “No team billing in v1.”
- “GitHub PR summaries are now in launch scope.”
- “Slack notifications move to later.”
Scope changes matter because they are the rules your next AI session should obey. If they stay in your head, your AI will keep suggesting the wrong thing.
Capture future work
AI sessions are full of future plans.
The problem is that they appear at the worst possible moment: while you are trying to finish something else.
Examples:
- “After this ships, add a better empty state.”
- “v1.0.1 should improve import quality.”
- “v2 should support shared workspaces.”
These should not interrupt the current build. But they should survive it.
If you and Claude decide on a v1 and v2, and you only ship v1, the v2 plan should not die in that chat. Ask the AI to write the follow-up as a mission in Q, or add the idea to the right “later” bucket.
Capture what shipped
When a PR merges, the product has changed.
That change should not live only in git history.
Capture:
- What shipped
- Why users care
- Which user-facing behavior changed
- Which product decisions were made
- Which scope boundaries changed
- Whether it creates a follow-up
- Whether it is changelog-worthy
This is not about dumping technical implementation details into Q. The code already lives in the repo. What Q needs is the product knowledge: what the user gains, what changed in the product, and what decisions the work created.
This is where Retroactive PM becomes very literal: the work happened, then the product layer caught up.
Capture open questions
Not everything needs to become a decision immediately.
Sometimes the useful capture is simply:
- “We are not sure whether agencies are a primary segment.”
- “Need to decide whether project templates are onboarding or growth.”
- “Unclear whether this belongs in product truth or missions.”
Open questions are better than invisible uncertainty.
A product truth with known unknowns is healthier than a product truth pretending everything is settled.
Step 3: Reuse
Capture is only valuable if it changes the next build.
Otherwise it is just nicer documentation.
The point of living product truth is that it becomes reusable context for every tool and every session.
Reuse means the next AI interaction starts smarter.
Cursor checks the summarized product truth before suggesting an implementation.
Claude knows teams are out of scope because that decision is in Q.
A mission carries the user-facing reason for a feature, not just a technical task list.
The GitHub Q Bot can connect a PR back to the mission it implements.
A teammate can see the decision without asking you to retell the whole story.
Your landing page reflects the product you actually shipped, not the product you vaguely remember planning.
This is the compounding part of the loop.
A single captured decision is useful.
A hundred captured decisions, scope boundaries, missions, and shipped changes become an operating system for the product.
Every future build gets the benefit of past builds.
That is the entire point.
The loop in practice
Here is what build → capture → reuse looks like in a normal AI-first session.
Before the session
You start with a lightweight product truth:
- The target user
- The current goal
- The relevant scope boundaries
- The decisions that should constrain the work
You AI tool gets that context through Q: MCP, Cursor rules, or skills tell the AI to check the product truth first.
The goal is not to write a perfect spec. The goal is to give the build a memory before it starts.
During the session
You build.
Cursor proposes a simpler implementation. You accept it.
Claude points out that a feature you planned creates onboarding complexity. You cut it from v1.
You and the AI decide that v1 should ship now, v1.0.1 should add a refinement, and v2 should handle the larger version.
This is the moment where most product knowledge gets lost.
Not because Q is secretly watching everything you do in Cursor or Claude. It is not.
Because the AI tool you are already using is connected to Q, you can tell it what to do with the product knowledge:
- “Scope this as v1 / v1.0.1 / v2.”
- “Add this idea to Q.”
- “Create a mission for the v2 follow-up.”
- “Update the current mission with what we actually decided.”
- “Summarize the user-facing product knowledge from this feature.”
You do not stop to write a giant document.
You turn the useful parts of the session into product truth while they are still fresh.
After the session
The product truth catches up:
- The scope page gets a proposed update
- A new mission is created for the follow-up
- The current mission is updated with what actually shipped
- A decision gets logged with rationale
- The shipped PR is connected to a mission - or a mission is created if none exist yet
- The changelog draft has the right language
You review the changes as diffs. Accept what is true. Reject what is noise.
Nothing changes silently.
The product now remembers what the build taught you.
Next session
You do not start from zero.
The captured truth is available to Q, Cursor, Claude, your teammates, and your future self.
The loop closes.
Build produced knowledge. Capture preserved it. Reuse makes it valuable.
Capture can start from more than code
Not every useful idea appears while you are actively coding.
Sometimes you are thinking through pricing. Sometimes you are planning onboarding. Sometimes you are exploring a marketing idea. Sometimes you are trying to decide whether a feature belongs in v1 or v2.
In those cases, the workflow is still build → capture → reuse, but “build” may mean building the product model rather than writing code.
Open a separate Cursor or Claude chat and ask:
- “Scope this idea against the current product truth.”
- “Is this v1, later, or out of scope?”
- “Turn this into a mission in Q.”
- “Add this as a future idea, but do not change current scope.”
- “Compare this idea to our existing positioning and decisions.”
The point is the same: do the thinking where you naturally do the thinking, then capture the result in Q so it can be reused later.
What to capture vs. what to ignore
A common fear is that this becomes yet another documentation tax.
It should not.
The goal is not to capture everything. It is to capture the things with future value.
A good filter:
Will this help the next build, the next explanation, or the next decision?
If yes, capture it.
If no, let it go.
Capture:
- Decisions with rationale
- Scope boundaries
- Meaningful product behavior changes
- Future plans you actually want to revisit
- Repeated explanations you are tired of giving
- PRs that change user-facing behavior
- Tradeoffs that would be expensive to rediscover
- User-facing product knowledge discovered while building
Ignore:
- Temporary implementation details
- Random prompt fragments
- Dead-end explorations with no future relevance
- Every tiny bug fix
- Notes that only made sense in the moment
- Documentation for the sake of looking organized
The point is memory, not neatness.
If a captured artifact will not make future work better, it is probably not product truth.
Why “living” matters
A lot of tools can store a plan.
That is not enough anymore.
The plan is only useful if it can evolve when the product evolves.
In vibe coding, product truth is not a stone tablet. It is closer to a live model of what the product currently is, what it is becoming, and why.
That means it has to accept updates from multiple directions:
- From the founder’s idea
- From AI chats where scope gets decided
- From missions
- From PRs
- From user feedback
- From the live website
- From the actual product as shipped
If the product truth only reflects what you believed before building, it will become stale almost immediately.
If it updates with every meaningful build, it becomes more valuable over time.
This is the difference between a static source of truth and a living product truth.
Static truth says:
“Here is what we planned.”
Living truth says:
“Here is what is true now.”
AI-first development needs the second one.
The role of Q
This is what Q is for.
Q is not just there to help you write better tickets.
That would miss the point.
Q’s job is to keep product truth reusable across the tools where AI-first builders already work.
In the build → capture → reuse loop, Q helps in a few specific ways.
Q gives AI tools the product truth
Any AI toll can connect to Q through MCP, Cursor rules, and skills.
That means they can check the product truth before helping you scope, plan, or build. They do not need you to re-explain the whole product every time.
The product truth becomes the context layer your AI tools call first.
Q gives the AI somewhere to put product knowledge
When a useful idea appears in a chat, you can ask the AI to add it to Q.
Not as raw transcript.
As structured product knowledge:
- A mission
- A scope update
- A decision
- A future idea
- A changelog-ready note
- An update to an existing mission
This is the capture step. Q does not need to watch everything. It needs to be the place where the AI can put the important parts when you ask it to.
Q connects shipped work back to missions
The GitHub Q Bot connects PRs with missions.
That matters because a PR is where planned work becomes shipped product behavior. If the implementation changes the product, the mission and product truth should be able to catch up.
Again, the goal is not to store code details in Q. The goal is to preserve the product knowledge created by the code: what shipped, why it matters, and what decisions were made.
Q suggests the next product hygiene step
There is also General-Q: the Q that understands what is happening inside your account and can suggest useful follow-ups.
For example:
“Hey, you moved this mission to Done. Should we draft a changelog entry?”
Or:
“You created three missions around onboarding. Should we group them into an operation?”
This is not Q spying on your coding session. It is Q responding to actions inside your HeyQ workspace and helping you close the loop.
The important part is control.
Q should propose truth changes, not silently rewrite the product behind your back. Builders need speed, but they also need trust.
Reviewable diffs are what make living truth safe.
The workflow is the product moat
At first, build → capture → reuse sounds simple.
It is.
That is why it matters.
The hard part is not drawing the loop. The hard part is making it natural enough that builders actually do it.
Traditional PM tools are built around the old loop. Their data model assumes the work is defined before it happens. A ticket is born in the backlog, travels through statuses, and ends at done.
But AI-first work does not always start as a ticket.
Sometimes it starts as a question.
Sometimes it starts as a prompt.
Sometimes it starts as a PR.
Sometimes it starts as a half-built feature that needs to be understood after the fact.
A product tool for this era has to accept all of those as valid entry points, then turn the useful parts into product truth.
That is the shift.
Not better backlog management.
Better product memory.
The bottom line
AI-first builders do not need more process for its own sake.
They need a loop that matches how they actually work.
Build when building is the fastest way to think.
Capture the decisions, scope changes, shipped behavior, and future plans that should survive the session.
Reuse that product truth so the next build starts smarter than the last one.
That is build → capture → reuse.
Not a ceremony.
A memory system for the vibe coding era.
Want to build this way?
Start with whatever product truth you have — an idea, a doc, a repo, or a rough plan. Connect your AI tools to Q, build the way you already build, and use Q to capture the product knowledge worth remembering.
