The Methodology
Intent-Driven Product Design.
AI can build the wrong thing faster than you've ever built the wrong thing before. The problem isn't the tool — it's that AI fills every gap in your intent with a plausible assumption. The less you specify, the more it guesses. The more it guesses, the more you correct. That correction cycle is where the time, cost, and rework live.
Intent-Driven Product Design — IDPD — is the discipline layer that closes that gap, before a single prompt is written.
Why This Exists
AI amplifies whatever intent you give it — including the absence of intent.
The problem isn't the AI tool. The problem is that AI systems complete tasks with whatever context they're given — and when that context is incomplete, they fill the gaps with plausible assumptions. Plausible isn't the same as right. The gap between plausible and right is where the rework lives.
1
The fast-start, expensive-finish pattern
Generation is instant. Correction is brutal. Teams prompt, get output, spend three times longer fixing what the AI assumed wrong. The tool worked. The specification failed.
2
The plausible-but-wrong problem
AI fills every specification gap with a confident assumption. The less intent you encode, the more the model guesses. The more it guesses, the more polished the wrong answer looks.
3
The late-correction cost
Decisions resolved in the specification phase cost a fraction of decisions resolved after engineering begins. Skipping rigorous specification doesn't save time. It defers the most expensive work to the most expensive moment.
IDPD exists because none of these are AI problems. They are specification problems. And specification problems are solved before the prompt, not after.
The Methodology
IDPD is a product operating system. Not a framework. Not a skill.
Intent-Driven Product Design (IDPD) is an AI-native product operating system that ensures business intent is defined, prioritized, and enforced from strategy through engineering delivery. It combines decision governance, behavioral specification, and lifecycle control into a single discipline that AI tools operate within — rather than around.
Other Tools
IDPD
Documents requirements
Forces decisions
Generates outputs
Prioritizes what matters
Starts at engineering
Starts at business model validation
Specs once
Maintains intent through delivery
Helps when you ask it to
Governs how AI behaves throughout
M
Mentor
Forces the right product decisions at the right lifecycle stage — before they become expensive to reverse.
C
Curator
Eliminates elaboration, over-specification, and low-impact output. Only load-bearing decisions make it through.
G
Governor
Applies hard protocols — Lane Test, Decision Test, Impact Triage — that are not optional steps in a checklist.
CL
Control Layer
Detects intent drift across the lifecycle. Keeps what was decided intact through engineering delivery.
The Architecture
Seven phases. One unbroken chain of intent.
Decisions made early cost least. IDPD front-loads the work that most teams discover after engineering has already started.
The sequence matters. Decisions resolved in Phase 0 prevent failures that would surface in later phases.
The Protocols
The mechanisms that make IDPD executable — not aspirational.
Most methodologies describe what to do. IDPD has hard protocols that govern how AI behaves at every step. These are not optional guidelines.
Lane Test
Keeps product decisions out of engineering territory.
Before any specification item proceeds, it must pass one question: Would an AI coding agent figure this out anyway from the behavioral intent? If yes — omit it. If no — it's a product decision and it belongs. The Lane Test prevents the most common specification failure: writing engineering constraints disguised as product decisions.
Eliminates document bloat. Preserves engineering autonomy.
Decision Test
Every step must force a decision — not elaborate one.
Before adding any section or detail, one question governs: Is this forcing a new decision that hasn't been made yet — or is it elaborating a decision that's already made? If elaborating: one sentence and move on. The Decision Test is the discipline that keeps executives honest about whether they're thinking or just writing.
Eliminates elaboration. Keeps documents decision-dense.
Impact Triage
Only load-bearing decisions make it into the specification.
Every finding is scored: HIGH (load-bearing — the design breaks without this), MEDIUM (meaningful improvement), LOW (interesting but not differentiated — excluded entirely). Target composition: 70% HIGH, 30% MEDIUM, 0% LOW. This isn't a preference. It's a hard constraint applied before anything goes downstream.
Eliminates noise. Concentrates engineering attention.
Behavioral Contracts
Defines how the product must behave — not how it is built.
The output AI coding agents and engineering teams execute against. A behavioral contract defines what the system must do in every relevant condition, stated as testable requirements. Not a PRD. Not a wireframe. A contract that engineering signs off against — and that AI tools can execute from directly.
Eliminates interpretation. Creates executable specifications.
Who Benefits
Different roles. The same underlying problem.
The specification gap costs every team differently — but it costs every team.
For Engineers and Development Leads
You're building exactly what you were told to build. The problem is what you were told.
You're given a PRD, a brief, or a set of tickets. You build from it. Then you're told it's not what was wanted — not because you built it wrong, but because the spec never captured what was actually decided. You're doing your job correctly. The problem is upstream.
IDPD produces behavioral specifications your team can build from directly — without interpretation, without assumption-filling, without the rework cycle that comes from a spec that described screens but not decisions.
For Product Managers and Product Leads
You know more than anyone about what should be built. The challenge is making AI know it too.
You've adopted AI tools. You're prompting more, generating faster, producing more output. And somehow the gap between what you decided and what engineering receives has gotten wider — because now there's more output to review and more places for intent to drift.
IDPD gives you the protocols to translate your product judgment into specifications that AI tools can execute — precisely, repeatably, and without the correction cycle. It's not a faster way to generate. It's a way to generate right the first time.
For CPOs and Product Executives
Your team adopted AI. Speed went up. Fidelity didn't.
The promise was faster builds. What you're seeing is faster starts and the same expensive correction cycles — because AI speed without specification discipline just moves the rework earlier in the timeline, not out of it. You're not sure how to fix it because nobody has a clear answer for what rigorous AI product development actually looks like.
IDPD is the operating system your teams are missing. It gives product managers, engineers, and AI tools a shared discipline layer — so speed produces the right product, not a faster version of the wrong one.
The Command Center
IDPD runs inside Claude as a native skill.
The IDPD Claude skill installs the full methodology as a governance layer inside your Claude workspace. Every phase gate, every protocol, every decision checkpoint runs natively — no external tools, no switching contexts. Your Claude session becomes the environment where intent is defined, enforced, and delivered.
See it in a Discovery Consult
Why IDPD Is Different
Not a faster Claude workflow. A different category entirely.
Other Claude skills produce outputs faster. IDPD governs how AI behaves.
Most Claude skills automate a task — generate a PRD, summarize research, write user stories. IDPD is a different kind of artifact entirely. It doesn't complete a task for you. It installs a governance layer into your Claude session that controls how the model reasons, what it's allowed to decide, and when it must stop and ask. The output is a product specification your engineering team can build from directly — and that AI coding agents can execute without misinterpretation.
Other methodologies assume the business case is made. IDPD starts there.
Most product frameworks start with the product: personas, features, wireframes, sprints. IDPD starts with the business: Can this product reach people who need it? Can you acquire them at a cost the model supports? Can you deliver at scale? Does the revenue arithmetic work? Phase 0 — Business Model Foundation — answers these before a single feature is named. This is not due diligence. It is the prerequisite for specification work that will still make sense six months into a build.
Other tools help you spec. IDPD maintains intent through delivery.
Specification is necessary but not sufficient. Intent drift — the gradual divergence between what was decided and what gets built — happens across sessions, across tools, across team members. IDPD includes session continuity protocols, cross-tool handoff formats, and context health monitoring specifically to detect and interrupt drift before it compounds. The methodology doesn't end when the spec is written. It ends when the product ships correctly.
Ready to see where your product specs are losing intent?
A Discovery Consult starts with your product, your current process, and a direct assessment of where IDPD would change the outcome. Thirty minutes. No pitch.
Book a Discovery Consult
No commitment required. Response within 24 hours.
