Most AI-assisted product work fails. Not because the models are bad, but because the process is.
The capability is real. PMs can now document complex systems, synthesize scattered requirements, and generate development-ready specs in hours instead of weeks. But most teams aren't capturing that value. They're stuck in single-shot prompting: ask the model, take the output, ship it.
This guide covers techniques for LLM-assisted product discovery. Whether you're new to AI-assisted workflows or looking to refine your approach, we'll cover patterns that actually work.
A quick note on tooling: LLMs don't work in isolation. The patterns in this guide assume you're using AI tools that can access your files—whether that's an AI-IDE like Cursor or Windsurf, Claude with file uploads, or ChatGPT with document attachments. The LLM provides the reasoning; the tooling provides access to your codebase, documents, and context. Without that scaffolding, most of what follows isn't possible.
Core Principles
Before diving into the workflow, three principles govern everything that follows.
The Verification Problem
LLMs are remarkably good at this work. Point a frontier model at a codebase, a set of requirements, or a collection of mockups, and it will produce spec documents that are largely accurate. The core architecture, the main user flows, the primary data models—these get captured well. With the right prompting, you can get 80-90% of the way there in a single pass.
But that remaining percentage matters.
The blind spots are subtle: a file path that doesn't quite exist, an edge case the model glossed over, an assumption that seemed reasonable but doesn't match reality. These aren't failures of intelligence—they're the inevitable result of synthesizing complex systems under uncertainty. Every spec has them. The question is whether you find them before development starts or after.
The fix: start a fresh conversation for verification. In a new chat, the model approaches your document cold, spinning up subagents to verify claims against actual source material rather than defending what it previously generated.
Cross-LLM Validation
Fresh conversations catch blind spots within a single model. Cross-LLM validation catches blind spots across models.
Don't merge feedback blindly. Return to your original conversation and present the feedback as "colleague input." The original LLM, with full context of how the document was built, can evaluate what's valid and what isn't.
Two to three rounds typically produces stable output. You're done when feedback becomes stylistic rather than substantive.
The Human's Job
LLMs handle generation. You handle judgment.
Review, don't rubber-stamp. AI-generated specs can look polished while being subtly wrong. Read carefully. Trace the logic.
Inject domain knowledge. You know things about the business, the users, the constraints that aren't in any document. The LLM can't know the VP of Sales promised a customer this feature would work a specific way.
Make decisions. The LLM surfaces options. You choose direction. Quick solution now or robust approach upfront? That's a product decision, not a technical one.
Challenge assumptions. When the approach doesn't feel right, push back. Your intuition is pattern-matching on experience. It's often detecting something real.
These principles—fresh-conversation verification, cross-LLM validation, and human judgment—apply at every phase of the workflow.
The Workflow
With principles established, here's the workflow itself. Each phase builds on the previous, producing artifacts that feed the next.
Phase 1: Document Current State
Everyone wants to jump to the new feature, the redesign, the migration. But you can't plan where you're going without knowing where you are. And "where you are" in a mature codebase is usually messier than anyone remembers.
With the appropriate agent scaffolding, LLMs excel at codebase archaeology. They can read documentation, trace component hierarchies, map data flows, and surface technical debt nobody's discussed in years. Let them do this work.
Generate the document: Point your AI tool at the area you're changing. Be specific: architecture, file paths, data models, API endpoints, integration points, known limitations.
Then verify. Open a fresh conversation, provide access to the same files, and have it validate every claim in your freshly created spec doc. File paths should exist. Component descriptions should match implementations.
Then review yourself. This is your chance to learn the system you're about to change. Domain knowledge catches errors LLMs miss.
Output: A current-state document that accurately describes what exists today.
Phase 2: Document Proposed State
Product inputs come in many forms. Figma exports. PRDs written by committee. Technical RFCs. Slack threads where decisions were supposedly made.
LLMs can synthesize all of it—but you need to provide the inputs and match the analytical lens to the input type.
For mockups, prompt from a UI/UX perspective: component hierarchy, interactions, empty states, error states. For requirements docs, think like a product analyst: user flows, business rules, success criteria. For RFCs, adopt the architect lens: system boundaries, data flows, API contracts.
Don't just summarize. Extract structure. What components exist? What data do they need? What can go wrong?
Challenge and augment before finalizing. Push on vague areas. Then verify in a fresh conversation against the original materials.
Output: A proposed-state document that captures design intent and requirements.
Phase 3: Create Technical Specification
Now bridge the gap. Feed the LLM both documents—current state and proposed state—and have it synthesize a technical specification.
This is where the LLM earns its keep. It can identify what needs to change, what can stay, what new components are required, and how they integrate with existing systems. Architecture changes, data model updates, API modifications, migration strategies—all derived from the delta between where you are and where you're going.
This document needs the most scrutiny. Apply cross-LLM validation here. Run the spec through multiple models. Collect feedback separately. Integrate what's valid. Repeat until the feedback stabilizes.
Output: A technical specification describing how to get from current to proposed state.
Phase 4: Decompose into Work Items
Once you have a validated spec, have the LLM decompose the work into backlog items.
The structure that works: Epic → Features → PBIs (or in Jira: Initiative → Epic → Stories). One Epic for the initiative. Features for capability groupings. PBIs for individual units a developer can complete.
Keep effort sizing simple. S/M/L based on complexity. Let the LLM propose; adjust based on your team's velocity.
Validate the breakdown. Cross-LLM review catches circular dependencies, missing tasks, and unrealistic estimates. The work breakdown drives sprint planning—errors here create blocked sprints.
Output: A structured backlog ready for development.
Developing Your Workflow
Start simple. Don't build an elaborate process before you've validated any of it works.
Add verification steps when you notice recurring mistakes. Document what works. Standardize naming and folder structures—consistency enables automation.
The meta-pattern: use the same iterative, validation-heavy approach to improve your process that you use to improve your specs.
What's Next
LLM-assisted product work is still early. The patterns will evolve as models improve. But the core principles will remain: verification through fresh conversations, cross-model validation, human judgment where business context matters.
The productivity gains are real. Specs that took weeks now take days. Specs that would typically be shallow are now comprehensive. Edge cases caught in planning instead of QA.
Start experimenting. The cost of trying is low. The cost of waiting is higher.
Coming soon: The Artifacts That Power AI Agents—a deep dive into the documents this workflow produces and how they enable AI-assisted development. We'll cover how structured specs like current-state analyses, technical specifications, and detailed PBIs become the foundation for AI tools that can implement features with minimal hand-holding.
First Published on LinkedIn