Vibe Coding for Product Managers Without Losing the Plan

Vibe coding lets a product manager turn an idea into something clickable in an afternoon, by describing it to an AI instead of writing the code. Used well, it answers product questions faster than a spec can: does this flow make sense, can a user find the button, is the idea worth an engineer’s week. Used badly, it produces a prototype that nobody asked the right question of, decisions nobody wrote down, and a demo that stakeholders mistake for a nearly finished feature. The fix is not to vibe code less. It is to start each prototype with a written question, capture the decisions as you make them, and move everything that matters onto the team’s board before you close the session.

This post is about the product manager’s side, whichever tool you use. For the term itself and a general method, see what vibe coding is and how to do it with a backlog. If your tool is Claude Code, Claude Code for product managers covers the specific workflow.

Where it genuinely helps

• Testing a flow with users. A realistic prototype gets more honest reactions than a sketch. The UK government’s guidance on making prototypes↗ (opens in a new tab) makes the same point: sketches are useful for discussing ideas with colleagues, and code prototypes are better for user research because they are more realistic.
• Settling an argument. When a meeting goes round in circles about how a screen should behave, two prototypes side by side end it faster than another round of comments on a document.
• Asking better questions of engineering. A prototype shows where the hard parts are: the screen that needs data you do not have, the step that depends on another team.
• Your own tools. A small script that sorts a feedback export or a page that charts last month’s sign-ups is work nobody else will build for you, and it never needs to ship.

Where it goes wrong

Most of the failures are not about code quality. They are about what happens to the knowledge the prototype produced.

• The prototype becomes the spec. Engineers are handed a working demo and asked to “build this”, and every accident in it, a default the AI picked, a field it invented, becomes a requirement nobody chose.
• The prototype ships. It looks finished, so someone suggests putting it live. The same government guidance is blunt: prototype code does not need to be secure or handle real traffic, and you should not just copy it into production.
• The decisions stay in the chat. Every time you told the AI “no, put the price before the plan name” you made a product decision. Close the session and it is gone, along with the reason.
• Customer data goes in the prompt. Pasting a real export into a chat to make the demo look realistic is how personal data ends up somewhere it should not be; the OWASP list of LLM risks names sensitive information disclosure↗ (opens in a new tab) as one of its top ten.
• You trust what it says it did. An AI will tell you the form validates email addresses when it does not. OWASP calls this overreliance↗ (opens in a new tab): accepting generated output without checking it.

Before you start: write the question down

A prototype is an experiment, and an experiment needs a question. Write it in one sentence before you open the AI tool: “Can a first-time user invite a colleague without help?” or “Does showing the price on the first screen change which plan people pick?” If you cannot write the question, you are not prototyping; you are exploring, which is fine, but say so and do not show the result to anyone as evidence.

Put the question on a card before the session, not after. It keeps the session honest, because you can tell when you have drifted into polishing the colours of a screen the question does not depend on. It also means that if the prototype is abandoned, the question is still on the board for someone to answer another way.

During the session: keep two short lists

Keep a plain text file open next to the AI tool, or ask the AI to maintain one in the project, with two headings.

## Decisions (what we chose, and why)
- Invite by email only, not by link: simpler to explain in onboarding.
- Plan names after prices: users compared prices first in every test.

## Follow-ups (for the board)
- Engineering: can invites reuse the existing email service?
- Bug in current app: the Back button loses the form (seen while comparing).
- Question for sales: do enterprise trials need the invite step at all?

The decisions list is the one that usually goes missing. Any time you correct the AI’s choice with a reason, it belongs there. The follow-ups list catches everything you notice but should not fix in a prototype: real bugs in the live product, questions for other teams, ideas for later.

Keep the prompts themselves small. Ask for one screen or one change at a time, look at the result, then ask for the next. Long prompts that describe the whole product produce a whole product’s worth of assumptions, and you will not find them all.

After the session: move it to the board

The last ten minutes of every vibe coding session belong to the board, not to one more tweak. On fenbs that is a short routine.

1. Comment on the question’s card with what the prototype showed, where the prototype lives, and whether the question is answered.
2. File each follow-up as its own task, with the right kind: a feature for something new, an enhancement for a change to something that exists, a bug for the Back button you noticed. They start in To Do.
3. Record the decisions that should outlast the prototype on the board’s Decisions page. A decision can be open, a question waiting for someone; proposed, a recommendation; or decided, with who decided and why. The deciders are always people, even when an assistant wrote the entry.
4. Leave the plan field of new tasks empty. How it will be built is engineering’s call; a PM’s guess in the plan reads as an instruction.

If your AI tool can connect to the board over MCP, it can do most of this for you from the session notes: search for existing tasks with fenbs_search, file new ones with fenbs_create_item, and record decisions with fenbs_add_decision. fenbs holds back a new task that looks like one already open and returns the likely matches instead, so a follow-up someone else already filed becomes a comment rather than a duplicate. Read what it proposes before it files anything.

Handing it to engineers

Engineers do not need your prototype’s code. They need what it taught you. A good handover is a card, not a demo:

• The problem, in the note: who has it, why it matters, how anyone will know it is solved.
• The prototype, linked in a comment, with a line saying what in it is real and what is faked: sample data, hard-coded prices, a screen that does nothing.
• The decisions it depends on, linked, so nobody reopens a choice without knowing it was made deliberately.
• The open questions, stated as questions. An unanswered question in a card is better than an answer the AI guessed.

Then let the task move through the lanes the normal way: Next Up when it is ready, In Progress when someone picks it up, Completed when it is done and its testing status says how it was checked. The prototype has done its job the moment the card is clear. Treat it as the Google Cloud guide treats pure vibe coding↗ (opens in a new tab): suited to rapid ideation, with the real product built by people who review, test and own the code.