Plan product work

When you'd do this

• A customer request or roadmap item lands and you need to know how the feature behaves today before you write anything down.
• You're preparing for a sizing conversation and want to walk in knowing which services, repositories and teams a change would involve.
• Someone asks "did that fix go out?" and you'd rather not interrupt an engineer to find out.
• You're weighing two roadmap items and want to know which one sits on a fragile or noisy part of the system.
• You're writing a spec or PRD and want it to describe the system as it is, not as someone remembers it.
• A feature shipped last week and you want to know whether errors or latency moved since.

Before you start

• Vörr is connected to Claude, ChatGPT or another MCP assistant, and you've given consent for your own account. Your admin has connected the code repositories, and ideally the cloud accounts and the observability and CI/CD tools the team uses. ChatGPT needs a paid plan with Developer mode turned on.
• Repositories are mapped to workspaces, so Vörr knows which team owns which part of the system. As a member you see the workspaces you belong to, nothing else.
• You don't need any credentials in chat. Vörr holds the connections for the organisation and never shows stored credentials to the assistant. Everything you do from chat is read-only.
• For the engineering side, the engineers you work with have CodeZero installed in VS Code with the organisation's repositories indexed. You don't need CodeZero yourself to follow this page, but the handover and progress steps happen there.
• Ask your admin whether the service map is up to date. Vörr uses it to match the name you say ("checkout") to the right repositories, services and dashboards.

If any of this isn't set up yet, start here:

• Connect Vörr to your assistant
• Roles and permissions
• Install and connect CodeZero

Why an assistant needs the system

Without access to your code, an assistant describes how a feature like yours usually works, not how yours does. The answer reads well and is often wrong in exactly the details that matter for scoping: a second service that also writes the data, a queue between two steps, a flag that only exists in one environment.

Impact questions need code across several repositories, because the parts of a feature that call each other over HTTP or a queue don't reference each other in source. And "has it shipped?" or "is it erroring?" live in CI and monitoring tools that product people often have no login for. Vörr brings those sources into the assistant, and every answer says where each fact came from.

Operations

Product planning breaks into these operations, roughly in the order a piece of work moves through them. Each one says whether Vörr, CodeZero or the assistant itself does each step.

1. Understand how a feature works today

1. Vörr: from Claude or ChatGPT, ask how the feature works. Vörr searches the connected repositories, reads the relevant files and returns them with their repository and path.
2. Assistant: ask for the explanation in plain language, as a numbered flow, with a file reference on every step. Ask it to mark which steps it read in code and which it inferred.
3. CodeZero (engineer in the loop): for anything you'll rely on, ask an engineer to open the feature in Functions. Functions shows the feature's Entry, the files it Goes Through, the data it Reads / Writes and any other repository it crosses into.

A good answer is a short ordered flow where every step points at a file. Look out for steps with no reference, or an answer that never names a repository: that's the assistant filling gaps from general knowledge. Send two or three references to an engineer for a quick check before you build on them.

2. Find what a proposed change would touch

1. Vörr: describe the change and ask which repositories and services hold the code it would affect. Vörr searches code, symbols, references and declared routes across connected repositories.
2. Vörr: for a running service, ask what depends on it. Vörr can use the service graph from connected tracing tools and, where cloud is connected, the precomputed upstream and downstream blast radius.
3. CodeZero (engineer in the loop): ask an engineer to run the same impact question in CodeZero Chat. Its Graph infers links between repositories from HTTP calls matched to routes, Kubernetes, Helm or Compose config, and queue producers and consumers. Each link shows the file and line it came from, and HTTP and config links also show a confidence.
4. You: treat the list as input to a sizing conversation, not as an estimate. Neither product computes effort.

A good result lists each touched area with a file reference and a reason, and separates what was found in code from what was inferred. If an obvious area is missing, ask about it by name: a search that found nothing in one repository is not proof the repository is unaffected.

3. Find the teams and people involved

1. Vörr: ask which workspace each touched repository belongs to. Workspaces are how your organisation records team ownership in Vörr.
2. Vörr: ask who has committed most to the relevant paths. Owners come from commit history.
3. You: use both to decide who should be in the sizing conversation.

Commit history tells you who has been active, not who is accountable. Workspaces reflect how your admin has mapped repositories, so a repository with no workspace, or in the wrong one, is worth flagging to them.

4. Check the health and usage signals of an area

1. Vörr: ask for error rate, p95 latency (plus p50 and p99 where the source reports them) and throughput for the services involved. Each connected source is reported separately and never averaged together.
2. Vörr: ask whether the services have SLOs and what their current status is, with remaining budget where the source reports it.
3. Vörr: ask for the top error issues with counts, and for any alerts that are firing.
4. Assistant: summarise it in a sentence you can use in a planning doc, with the source for each number.

Throughput is request volume as measured by your monitoring tools, not product analytics. Vörr doesn't know how many customers use a feature, or about funnels or conversion; that data lives in your analytics tool. If Vörr says a service has no monitoring, or no connector can answer, that's a finding for the roadmap in itself.

5. Find out whether something has shipped

1. Vörr: ask for recent deploys of the service. The deploy feed covers the connected CI/CD sources across the organisation, per service and environment.
2. Vörr: ask which branch deploys to which environment, so "merged" and "live in production" don't get confused.
3. Vörr: if you have a specific fix in mind, compare the time it merged with the deploys to the environment you care about. If the deploy source doesn't make the contents clear, ask the owning engineer to confirm.

A good answer names the CI/CD source, the environment and the time of each deploy. If the team deploys with a tool that isn't connected, the feed won't show it. Ask Vörr which sources it checked before you tell anyone "it hasn't shipped".

6. Map dependencies and risks for the roadmap

1. Vörr: ask what the area depends on, including external services such as payment or email providers, and what depends on it.
2. Vörr: ask what data the feature reads and writes, by searching the code for the tables and models it uses. An engineer can confirm this in CodeZero, whose Graph shows the tables and collections each repository reads and writes.
3. Vörr: ask for recent deploys alongside any regression windows Vörr detects (with Grafana connected), and for recurring errors in the area. A part of the system that broke after its last three releases is a schedule risk.
4. Assistant: turn the findings into a short risk list for the roadmap item, with a reference for each risk.

Keep the risks you can point at apart from the ones the assistant reasoned its way to. Both are useful, but only the first kind belongs in a roadmap review without an engineer's check.

7. Draft a spec grounded in the system

1. Assistant: ask for a draft spec or PRD that uses what you've learned. Ask it to separate the current behaviour (with references) from the proposed behaviour, and to list open questions.
2. Vörr: let the assistant look up anything it needs while drafting, such as a validation rule, an existing route or an error message, so the spec quotes the real thing.
3. Engineers: review the current-behaviour section against the references. It's quick, because every claim points at a file.

The assistant writes the draft; it doesn't decide anything. Anything in proposed behaviour is your decision, and anything in current behaviour is a claim for an engineer to verify.

8. Hand the scoped request to engineering

1. Engineer, in CodeZero: paste or summarise the spec as a request in Planned mode, so CodeZero makes no code changes until a plan is approved.
2. CodeZero: investigates the existing implementation across the indexed repositories. If the code can't answer a product decision, such as which payment is charged first, it asks a clarification question rather than assuming.
3. You: answer the product questions. The engineer can relay them, or you can sit with them while the plan is made. Answers should be decisions, in your words.
4. CodeZero: produces a plan naming the repositories, phases and verification commands. The agent can't approve its own plan. The engineer who started the work reviews it with the team and approves it in Tasks.

A good plan names repositories that match what you found in operation 2. If it names more, that's worth discussing; if it names fewer, ask why. Questions the plan raised and you answered are part of the record, which helps when someone later asks why it was built that way.

• Chat and plans
• Execution modes

9. Follow progress

1. CodeZero Tasks: after approval the plan becomes phases and tasks, marked pending, in progress, completed or blocked, with dependencies between them. Work spanning repositories shows which repository each part belongs to.
2. CodeZero Tasks: Tasks also lists work teammates have started (filter by All, Mine or Team), so a tech lead can see the whole change in one place.
3. Vörr: once code merges, follow it through the deploy feed per environment, from chat.

Tasks lives in VS Code with CodeZero. If you don't use it, ask the tech lead for a short status from it, or follow the deploy feed from chat.

10. Check after release

1. Vörr: once the deploy reaches production, compare error rate and latency for the affected services before and after it. Comparison windows flag where sources disagree.
2. Vörr: ask whether any new error issues appeared after the deploy, and, with Grafana connected, whether Vörr detects a regression window around it.
3. Vörr: for AWS services, CloudWatch metrics are checked against a 14-day baseline and classed as normal, elevated or unprecedented, or unknown where there is no baseline yet.
4. You: share the result with the source of each number. If something moved, send it to the owning team with the references.

A quiet error tracker doesn't prove a feature works; it proves nothing is throwing errors. Wrong-but-valid output, like an incorrect amount, needs a product check as well.

• Monitor service health

Without CodeZero or Vörr

ChatGPT or Claude with a GitHub connector can search and read code in the repositories your account can access, and reason well over it. Claude Code in a checkout can do more: grep, git log and gh for pull requests and Actions runs. Pasted dashboards, logs and screenshots get a careful reading. The gaps for product planning are about what's connected, not reasoning.

Done alone, the work is possible but slow: someone needs access to every tool, has to know which repositories exist, and has to reconcile service names that differ between GitHub, the CI system and the dashboards.

With CodeZero and Vörr

Vörr: the system from chat

Code search and reading, owners and workspaces, deploys, metrics, errors, SLOs and dependencies, from Claude or ChatGPT, without credentials and without leaving the conversation.

Vörr: one name across tools

Vörr resolves "checkout" through the service map, confirmed aliases and catalogue names, and every result carries its source, match quality and environment.

Vörr: honest gaps

A question no connected tool can answer gets "no connector" rather than a guess, and coverage shows which sources answered.

CodeZero: impact across repositories

Engineers see the links between repositories that grep can't find, each with file-and-line evidence (and a confidence on HTTP and config links), and the data each repository reads and writes.

CodeZero: a reviewed handover

Clarification questions surface product decisions before code is written. Engineering approves the plan, and Tasks shows progress per repository and across teammates.

The products sit side by side rather than inside each other. Product scopes and follows the work from chat with Vörr; engineering plans and builds it in CodeZero; both look at the same code index, so the repositories in the spec and the repositories in the plan should match.

Worked example: scoping split payments

A product manager is asked to scope "let customers pay with a gift card and a card on the same order" for next quarter. They work in Claude with Vörr connected.

1. Operation 1: Vörr explains the current gift card redemption flow with references.
2. Operations 2 and 3: Vörr lists the touched repositories and their workspaces.
3. Operations 4 to 6: Vörr reports health, the last deploy and the risks.
4. Operation 7: Claude drafts the spec. An engineer checks the current-behaviour section.
5. Operation 8: the tech lead opens the request in CodeZero Planned mode; the PM answers two clarification questions.

Current flow: gift card redemption
  1. web/src/checkout/PaymentStep.tsx           customer enters code
  2. payments-api/src/payments/payments.controller.ts  POST /payments
  3. payments-api/src/payments/method-selector.ts      exactly one method per order (read)
  4. giftcards-service/src/redeem/redeem.handler.ts    balance decremented (read)
  5. giftcards-service writes giftcard_ledger          (inferred from model name)

Touched by the change
  web                 workspace: Storefront   top committers: A. Rao, J. Kim
  payments-api        workspace: Payments     top committers: M. Osei
  giftcards-service   workspace: Payments     top committers: M. Osei, L. Chen
  notifications-worker  receipt template assumes one method (read)  workspace: Platform

Health, production, last 7 days vs previous 7
  payments-api       error rate 0.21% (Datadog) vs 0.19%   p95 410 ms vs 395 ms
                     SLO 99.9% availability, status OK
  giftcards-service  error rate 1.8% (Sentry issues) vs 0.6%
                     top issue: LedgerConflictError, 412 events
                     SLO: none defined

Deploys
  giftcards-service  production  3 deploys (GitHub Actions), last 2 days ago
  branch to environment  main -> production, develop -> staging

Coverage
  Datadog: answered   Sentry: answered   GitHub Actions: answered
  giftcards-service has no Datadog monitors

External dependency
  payments-api -> card processor (external), match: name

What the PM concludes

The change touches three teams, not two: the receipt template in notifications-worker assumes one payment method, which nobody had mentioned. giftcards-service is the riskiest part. Its error rate has tripled since a recent deploy, it has no SLO and no Datadog monitors, so the PM adds "stabilise ledger conflicts" as a prerequisite in the roadmap item rather than hiding it inside the estimate.

Verification: an engineer opens the method-selector and redeem handler references and confirms them; in CodeZero they run Verify on the inferred link to notifications-worker and it's confirmed. The ledger write was inferred, and the engineer corrects it to two tables.

Follow-ups: the spec goes to sizing with the three teams named. CodeZero asks which payment is charged first and what happens if the card fails after the gift card is debited; the PM answers both, the engineer approves the plan after the tech lead reviews it, and the PM follows the deploys from chat. After release they compare payments-api error rate and latency before and after the deploy.

Verify and follow up

• Check sources before you share. Every fact about code should name a repository and file; every number should name the tool it came from.
• Read the match quality. Explicit means the service map links the name; identity means a confirmed alias; exact means the name exists in that tool's catalogue; name means Vörr tried the name as typed; unmapped means no match. A name match on a service that matters deserves a quick check.
• Treat answers as partial when a source isn't connected, when Vörr says "no connector", or when coverage shows a scan was incomplete or denied. Say so in the doc rather than rounding it up to a conclusion.
• Remember the code index covers committed code on the default branch. Work in progress on a branch won't be in the answer.
• Ask engineers to run Verify in CodeZero on any inferred link between repositories that the scope depends on.
• Next operations: once the plan is approved, see Ship a cross-repository change for how engineering carries it through, and Monitor service health for ongoing checks.

Limits

• Neither product estimates effort or delivery dates. They give you the facts that a sizing conversation needs.
• Vörr has no product analytics. Throughput is request volume from monitoring tools, not users, adoption or conversion.
• Vörr only knows what has been connected and scanned, and only what your workspaces include. A deploy tool or monitoring source that isn't connected is invisible.
• Links between repositories are inferred from evidence such as URL literals, config and queue names. They aren't compiler-accurate, and dynamic URLs or unusual client wrappers can be missed.
• Owners come from commit history and workspace mapping, not from an accountability policy.
• Clarification questions, plans and Tasks live in CodeZero in VS Code. A PM who doesn't use it takes part through the engineer.
• Vörr is read-only from the assistant. It can't change code, infrastructure or tickets from chat.

Related

• Answer system questions without the IDE
• Make engineering decisions
• Ship a cross-repository change
• Build a feature
• Monitor service health
• Understand system architecture
• Keep context across the team
• Ask Vörr
• Connect Vörr to your assistant
• Connect observability tools
• Roles and permissions
• Trace a product feature
• Chat
• Execution modes