Claude Code for Product Managers in a Visual Workspace

Product managers are being pointed at Claude Code, Claude's app, Cowork, terminals, and IDEs. Here is how to get PRDs, mockups, prototypes, and reviews without low-bandwidth tool switching.

Karl Wirth ·
Claude Code for Product Managers in a Visual Workspace

Anthropic, Lenny Rachitsky, Teresa Torres, Sachin Rekhi, and nearly every product course now point product managers at Claude Code. The agent is genuinely good at product work: PRDs, competitive research, prototypes, feedback analysis. The problem is the interface PMs are usually handed: a terminal, an IDE, or a model-provider app that turns product work into low-bandwidth chat and file switching.

You do not have to work that way. A visual workspace like Nimbalyst runs Claude Code and Codex for you, so you get the PRDs, mockups, prototypes, diagrams, and reviews in one place. This guide walks through the PM loop the visual way, step by step.

Claude Code is for PMs now

The signal is hard to miss. Anthropic’s own research on how Claude Code is used in practice shows management among the fastest-growing groups of users, with success rates close to software engineers. Lenny published “everyone should be using Claude Code more.” Teresa Torres recorded a full episode on Claude Code for product managers. Sachin Rekhi ran a webinar that drew 1,500 PMs. Aakash Gupta ships a starter setup for it.

So the question for most PMs is no longer whether to use Claude Code. It is how to use it without adopting an engineer’s toolchain, a code-first IDE, or a chat-first provider app to get there.

The terminal, IDE, and provider app are not the workflow

This is not a knock on Claude Code. The agent underneath is excellent, the terminal is a fine home for engineers who live in one all day, and IDEs are excellent for people editing code all day. Claude’s own app and Cowork are useful for conversation and collaboration. For product work, though, those surfaces get in the way in specific, practical ways.

You write a PRD and the agent edits a file you then have to open somewhere else to read. You ask for a mockup and get HTML you cannot see rendered. You want to review what changed and you are paging through a git diff or an IDE code diff. You use a provider app and get a chat or task transcript, but no first-class visual editor for the project files. You try to run two things at once and you are juggling terminal tabs, IDE panels, and app tasks. All of it is friction for a PM who wants to plan, see, annotate, compare, and decide.

A workspace closes that gap. Here is the same PM loop with the terminal, IDE, provider app, browser preview, and design handoff pulled into one visual workspace.

The PM loop, done visually

Write the PRD and watch every edit

Draft the spec in a real markdown editor. Ask Claude Code to expand the problem statement, pull in technical constraints from the codebase, or draft acceptance criteria. Every change it makes shows up as an inline red and green diff. You accept, reject, or edit each one. Reviewing an agent’s edits feels like reviewing tracked changes in a document, not reading terminal scrollback or moving chat output into another tool.

Mockup the feature and annotate it

Describe a screen and the agent generates a mockup that renders right in the workspace. Draw on it. Circle the header, add a note next to the empty state, mark the button that should move. Ask the agent to apply your annotations and iterate. You are prototyping the interface without leaving the plan it belongs to.

Diagram the flow

Turn a paragraph into an Excalidraw diagram or a mind map, edited visually. Map the user journey, sketch the system boundaries, lay out the states a feature moves through. The diagram lives next to the spec, so the picture and the words stay in sync.

Run the coding session in your own repo

When you want a working prototype, start a coding session in a git worktree against your actual product repository. The prototype comes out matching your real design system and code, not a generic template on someone else’s servers. That difference matters at handoff: engineering gets a branch they can read and build on, instead of a screenshot they have to rebuild from scratch.

Review the change before it lands

See exactly what the agent changed, file by file, in red and green. Approve the parts that are right, reject the parts that are not, and nothing ships that you did not look at. You stay in control of the change without needing to write the code yourself.

Track the work

Keep tasks, bugs, and decisions on a tracker and a kanban board that the agent reads and updates too. The board reflects what is actually happening in your sessions, so status is something you glance at instead of something you assemble.

Analyze feedback and metrics

Point the agent at a feedback export, a set of interview notes, or your analytics through an MCP connection. It categorizes themes, ranks pain points, and drafts the follow-up tickets. The output lands as an editable doc, a spreadsheet, or a diagram in the workspace, ready to use.

Terminal, IDE, or provider app vs visual workspace

PM jobTerminal, IDE, or Claude appIn a visual workspace
Writing a PRDRaw markdown in developer tools, or chat output you move elsewhereWYSIWYG editor with red and green diff review
Mocking up a featureGenerated files you preview elsewhere, or no first-class mockup editorRendered mockups you annotate and iterate
Diagramming a flowDiagram text, IDE extensions, or explanation in chatVisual Excalidraw diagrams and mind maps
Reviewing changesTerminal git diff, IDE code diff, or app summaryFile-by-file visual diff, accept or reject each
Working in project filesDeveloper comfort assumed, or chat wrapped around filesOpen, edit, render, and review the actual project files visually
Tracking the workSplit across chat, tickets, IDE tasks, and notesTracker and kanban the agent keeps updated
Running several tasksTerminal tabs, IDE panels, or provider-app task listsSession board with status per agent
PrototypingPossible, but hard to review as a PMGit worktree, a real branch in your repo
Choice of agentUsually one provider or one tool surface at a timeClaude Code and OpenAI Codex, side by side

A concrete run: idea to reviewed branch

Here is what the loop looks like end to end. Clone your product repository, or a public demo repo if you are just learning, and point the workspace at it.

  1. Write a short PRD for a small feature in the markdown editor. Ask the agent to sharpen the goal and flag any technical constraints it sees in the code.
  2. Ask for a mockup of the main screen. Annotate it, ask for two changes, and settle on a version.
  3. Diagram the flow so the states are explicit before anyone writes code.
  4. Start a coding session in a worktree and ask the agent to build the prototype against the real codebase.
  5. Review the diff. Accept what is right, send back what is not, and repeat until it holds together.
  6. Hand engineering the branch, with the PRD, mockup, and diagram sitting next to it.

Every step happened in one workspace, instead of switching between a terminal, IDE, provider app, browser preview, and design tool.

What you still do not need to know

Codebase access does not turn a PM into an engineer, and it does not need to. You are not writing production code, debugging deep technical issues, or making architecture calls. You are reading enough to understand how the product works, asking better questions, prototyping ideas, and reviewing what an agent produced. Think of it like a PM learning to read a financial statement. You are not becoming the CFO. You just make better decisions with the numbers in front of you.

Claude Code and Codex, side by side

You are not locked to one agent. A workspace can run Claude Code and OpenAI Codex together, so you can start a session with either engine, run them in parallel on the same task, and use the same diff review and session board for both. Pick the agent that does the job best and keep your workflow the same.

Free, open source, and your existing subscription

The Nimbalyst desktop and iOS apps are free for individual use, MIT licensed, and the full source is on GitHub. It uses your existing Claude Pro, Max, or Anthropic API access to run Claude Code, so there is nothing new to buy. If you already pay for Claude, you already have what you need.

Product managers who try Claude Code rarely go back to waiting on an engineer for every technical answer. Doing it in a workspace built for planning, seeing, and deciding is what makes it stick.

Download Nimbalyst free and run your next PRD, mockup, and prototype in one place. For the broader picture, see Claude Code for product managers and the full guide to AI tools for product managers.