Context Architecture: The PM Skill Nobody's Talking About

Why I Use an Engineering Tool to Do Product Work

I recently opened an AI chat and spent the first ten minutes re-explaining the company, the product, the constraints. I pasted screenshots. I attached documents. I had no clue what it could actually remember from the last time we discussed the idea I was working on.

AI is capable, but working with it often feels repetitive, and the output inconsistent. Each new task feels like starting over.

The problem isn’t intelligence. It’s context.

Most chat-based AI tools operate with context that is largely invisible. You can’t easily inspect it, correct it, or deliberately build on it over time. For work that spans weeks or months, developing features, maintaining alignment across documents, or building on prior decisions, this becomes a real productivity bottleneck.

Build your workflow around AI, don’t plug AI into your workflow

The tools that make this mindset shift possible weren’t designed for PMs. Tools like Claude Code and Codex were built as coding agents, AI systems intended to help developers reason over real codebases. Their strength lies in reading large numbers of files, understanding relationships, and connecting implementation with documentation.

For product managers, those strengths should feel very familiar.

“You’re no longer asking questions in isolation; you’re collaborating with an agent that can work alongside you.”

Chris Long, Senior Product Manager @ Poq

When an AI can see your strategy, roadmap, PRDs, technical specs, and the actual code, the interaction changes. You’re no longer asking questions in isolation; you’re collaborating with an agent that can work alongside you. AI becomes a colleague who can validate your ideas against your vision, who can deliver precise and accurate documentation, and who can even fact check you against the actual implementation in the codebase.

When your documentation is patchy, out of date or missing, the most reliable source of truth is often the code itself.

This Isn’t About Vibe Coding

It’s tempting as a PM to think: “This sounds useful, but I’m not an engineer.”

Here’s the reality: you don’t need to write or understand code to benefit from code-aware agents.

The “technical” step is creating a read-only reference of the codebase. You’re not changing anything; you’re giving the AI a source of truth so it can reason over what the product actually does.

For example, when drafting a PRD, I’ve asked the agent:

• What constraints exist for this feature today?
• Where are edge cases enforced in practice?
• Does this behaviour already exist elsewhere in the product?

The agent answered based on reality, not just documentation. Your questions stay the same; the difference is that you now have a tool to validate answers against what exists.

Building Your Context Library

You likely don't need to start from scratch. The setup is incremental, and most of the materials already exist somewhere in your organisation.

1. Build a product operating context. One document that covers everything the AI needs to know about your company, domain, product and ways of working.
2. Create a template library. PRD templates, ticket formats, release note structures. Include examples of good output and, just as useful, examples of what to avoid.
3. Set up a current project folder. For each initiative, gather everything in one place: problem statements, early wireframes, customer quotes, research notes, draft specs.
4. Add the codebase as a reference. This is the step that produces great results. You're not editing code, you're giving the agent read-only access so it can validate assumptions against what actually exists. When you ask "does this behaviour already exist elsewhere?" or "what constraints apply here?", the agent answers based on reality.
5. Prompt the agent to work across all of it. Point it at your context, your templates, your project folder, and your codebase. Ask it to draft a PRD, generate release notes, or identify gaps in your specs. The agent reasons over everything at once. No re-explaining, no pasting screenshots, no context window management.

My working folder is structured to make context explicit and reusable:

/product-work/

├── templates/        (PRDs, tickets, release notes)

├── context/          (company, product, personas, glossary, constraints)

├── active-projects/  (current initiatives and drafts)

└── reference/        (past PRDs, research, competitor analysis)

The leverage is in the context folder. One key file—my product-context document—is around 2,000 words. It covers:

• What our platform actually is
• Target customers and strategic priorities
• Technical constraints and team structure
• Delivery process and documentation standards
• Guidance on how AI should assist (assumptions, trade-offs, focus areas)

This structure took a couple of weeks to assemble initially, and it will never be “finished.” But value arrived quickly, even with partial context, improving output quality and clarifying assumptions for the whole team.

• Invest time in templates and examples. Structure guides expectations better than instructions alone.
• Build incrementally. Add summaries after each release. Over time, AI becomes smarter about your domain.
• Be explicit about audience and purpose. Context handles background; prompts handle the specifics of the task.

The Real Shift for PMs: From Deliverables to Context Architecture

What surprised me most was how this is changing my role.

Previously, much of my time went into producing artefacts: PRDs, release notes, feature guides. With chat-based AI, that work got faster, but still required constant clarification.

Now, I spend more time building and maintaining the context library that AI can reference. The AI produces most of the artefacts; my job is ensuring it has what it needs to produce accurate, coherent outputs.

The impact is tangible. Our major mobile releases happen every six months. Writing release notes used to take one to two days. With chat-based AI, that dropped to half a day. With a maintained context library and an agent capable of reasoning over code, a solid draft can be ready in under an hour.

Time saving comes from not re-explaining; accuracy comes from context you can see, control, and update.

Who This Is For

This approach works best for sustained product work: features that evolve over weeks, documentation that must stay aligned with technical reality, and projects where consistency matters. It’s overkill for short, reactive tasks.

The biggest shift is mental, not technical. PMs who adopt context architecture can dramatically improve both speed and quality, without ever writing a line of code.

Don’t just build AI skills, build systems.