Dialectical Reasoning
Synthesize opposing views into higher-order resolution. The logic of productive disagreement.
Type Signature
Dialectical : Thesis → Antithesis → Synthesis
Where:
Thesis : Position × Evidence × Stakeholder → ArgumentA
Antithesis : ArgumentA → CounterPosition × Evidence × Stakeholder → ArgumentB
Synthesis : (ArgumentA, ArgumentB) → IntegratedPosition × Tradeoffs
When to Use
Use dialectical when:
- Stakeholders hold opposing valid positions
- Trade-offs need explicit analysis
- Strategic tension requires resolution
- Multiple perspectives each have merit
- "On one hand... on the other" situations
Don't use when:
- Cause-effect chain needed → Use Causal
- Explaining observation → Use Abductive
- Evaluating past decisions → Use Counterfactual
Core Principles
Charitable Interpretation
Each position must be represented at its strongest:
- Steel-man, don't straw-man
- Assume good faith and valid reasoning
- Identify the kernel of truth in each view
Genuine Synthesis
Synthesis is NOT:
- Compromise (splitting the difference)
- Victory (one side wins)
- Avoidance (postpone decision)
Synthesis IS:
- Integration at higher level of abstraction
- Resolution that addresses underlying concerns
- New position that transcends original framing
Three-Stage Process
Stage 1: Thesis
Purpose: Articulate first position at maximum strength.
Components:
thesis:
position:
statement: "Core claim being made"
underlying_concern: "What this position is really about"
stakeholder:
who: "Person/team holding this view"
role: "Their organizational function"
incentives: "What they optimize for"
evidence:
supporting:
- claim: "Evidence point"
source: "Where this comes from"
strength: 0.0-1.0
empirical: [DataPoint]
logical: [Argument]
implications:
if_adopted: "What happens if we go this way"
risks: [Risk]
benefits: [Benefit]
Example:
thesis:
position:
statement: "We should prioritize enterprise features over SMB growth"
underlying_concern: "Revenue concentration and deal size efficiency"
stakeholder:
who: "Sales leadership"
role: "Revenue generation"
incentives: "ARR, deal size, quota attainment"
evidence:
supporting:
- claim: "Enterprise deals average $400K vs SMB $5K"
source: "Q3 sales data"
strength: 0.95
- claim: "Sales cost per $ revenue 5x lower for enterprise"
source: "CAC analysis"
strength: 0.85
empirical:
- "3 enterprise deals = entire SMB revenue"
- "Enterprise churn 3% vs SMB 8%"
implications:
if_adopted: "Focus engineering on enterprise features, reduce SMB investment"
risks:
- "Lose SMB market to competitors"
- "Revenue concentration risk"
benefits:
- "Higher margins"
- "Larger average deal"
Stage 2: Antithesis
Purpose: Articulate counter-position at maximum strength.
Process:
- Identify what thesis misses or undervalues
- Find stakeholder with opposing view
- Build strongest case for alternative
- Identify where thesis assumptions break
Components:
antithesis:
position:
statement: "Counter claim"
underlying_concern: "What this position is really about"
stakeholder:
who: "Person/team holding this view"
role: "Their organizational function"
incentives: "What they optimize for"
critique_of_thesis:
- assumption_challenged: "Thesis assumes X"
counter_evidence: "But actually Y"
- risk_identified: "Thesis ignores Z"
evidence:
supporting: [EvidencePoint]
empirical: [DataPoint]
logical: [Argument]
implications:
if_adopted: "What happens if we go this way"
risks: [Risk]
benefits: [Benefit]
Example:
antithesis:
position:
statement: "SMB volume creates the foundation for sustainable growth"
underlying_concern: "Market presence, product iteration, and risk distribution"
stakeholder:
who: "Product leadership"
role: "Product-market fit and growth"
incentives: "Usage, retention, feature validation"
critique_of_thesis:
- assumption_challenged: "Enterprise features drive growth"
counter_evidence: "SMB usage generates product insights 10x faster"
- assumption_challenged: "Revenue concentration is acceptable"
counter_evidence: "Losing 1 enterprise deal = losing 80 SMB accounts"
- risk_identified: "Enterprise sales cycle is 9 months"
evidence:
supporting:
- claim: "SMB accounts generate 80% of feature requests"
source: "Product feedback analysis"
strength: 0.90
- claim: "SMB provides faster iteration cycles"
source: "Release metrics"
strength: 0.85
empirical:
- "SMB churn prediction accuracy 95% vs enterprise 60%"
- "Product improvements from SMB feedback shipped in 2 weeks"
implications:
if_adopted: "Maintain SMB investment, use as product lab"
risks:
- "Slower revenue growth short-term"
- "Lower margin overall"
benefits:
- "Diversified revenue base"
- "Faster product iteration"
- "Lower concentration risk"
Stage 3: Synthesis
Purpose: Integrate positions at higher level, resolving underlying tensions.
Synthesis Approaches:
| Approach | When to Use | Example | |----------|-------------|---------| | Integration | Both positions address valid concerns | "Enterprise revenue + SMB as product lab" | | Sequencing | Temporal resolution possible | "SMB first for PMF, then enterprise scale" | | Segmentation | Different contexts warrant different approaches | "SMB for product X, Enterprise for product Y" | | Reframing | Original dichotomy was false | "The real question isn't SMB vs Enterprise, it's time-to-value" | | Transcendence | Higher goal subsumes both | "Optimize for sustainable unit economics regardless of segment" |
Synthesis Components:
synthesis:
integrated_position:
statement: "What we will actually do"
framing: "How this resolves the tension"
how_thesis_is_addressed:
concern_validated: "What's true about thesis"
how_incorporated: "How we address that concern"
how_antithesis_is_addressed:
concern_validated: "What's true about antithesis"
how_incorporated: "How we address that concern"
trade_offs_acknowledged:
- trade_off: "What we're giving up"
mitigation: "How we reduce impact"
accepted_by: "Stakeholder who accepts this"
resolution_type: integration | sequencing | segmentation | reframing | transcendence
implementation:
actions: [Action]
metrics: [Metric] # How we know it's working
review_date: date # When we reassess
Example:
synthesis:
integrated_position:
statement: "SMB as rapid learning engine, enterprise as revenue engine,
with explicit feature graduation path"
framing: "Not SMB vs Enterprise, but learning velocity vs revenue efficiency
with a bridge between them"
how_thesis_is_addressed:
concern_validated: "Enterprise deals are more efficient per dollar"
how_incorporated: "Maintain enterprise sales motion, prioritize enterprise
features that have been validated through SMB"
how_antithesis_is_addressed:
concern_validated: "SMB generates faster product learning"
how_incorporated: "Protect SMB investment as product lab, use SMB metrics
to prioritize enterprise features"
trade_offs_acknowledged:
- trade_off: "Some enterprise-only features will ship slower"
mitigation: "Identify 'must have' enterprise features, fast-track those"
accepted_by: "Sales leadership (with fast-track list)"
- trade_off: "Some SMB features won't graduate to enterprise"
mitigation: "Clear graduation criteria defined upfront"
accepted_by: "Product leadership (with criteria agreement)"
resolution_type: integration
implementation:
actions:
- "Define feature graduation criteria (Product + Sales)"
- "Create SMB → Enterprise feature pipeline"
- "Allocate 60% engineering to graduated features, 40% to SMB lab"
metrics:
- "SMB feature graduation rate (target: 3/month)"
- "Enterprise close rate on graduated features (target: +20%)"
- "Combined revenue growth (target: 30% QoQ)"
review_date: "End of Q2"
Quality Gates
| Gate | Requirement | Failure Action | |------|-------------|----------------| | Thesis strength | Steel-manned, evidence-backed | Strengthen before proceeding | | Antithesis genuine | Not straw-man, different stakeholder | Find genuine opposition | | Synthesis integrative | Not compromise or victory | Reframe until true synthesis | | Trade-offs explicit | All parties acknowledge costs | Surface hidden disagreements | | Actionable | Concrete next steps | Add implementation detail |
Stakeholder Agreement Protocol
Synthesis isn't complete until affected stakeholders acknowledge:
- Their concern was understood (thesis/antithesis accurately represented)
- The synthesis addresses their core interest (not just their stated position)
- They accept the trade-offs (explicitly, not assumed)
stakeholder_acknowledgment:
thesis_stakeholder:
name: "Sales leadership"
concern_understood: true
synthesis_addresses_concern: true
accepts_trade_offs: true
conditions: "Fast-track list for critical enterprise features"
antithesis_stakeholder:
name: "Product leadership"
concern_understood: true
synthesis_addresses_concern: true
accepts_trade_offs: true
conditions: "Clear graduation criteria before implementation"
Common Failure Modes
| Failure | Symptom | Fix | |---------|---------|-----| | False dichotomy | Positions aren't truly opposed | Reframe the actual tension | | Straw-man | Weak representation of one side | Involve actual stakeholder | | Mushy middle | Synthesis is just "do both" | Force resource allocation | | Unacknowledged loss | Trade-offs hidden | Surface what's being given up | | No implementation | Synthesis is abstract | Add concrete actions |
Output Contract
dialectical_output:
thesis:
position: string
stakeholder: string
evidence: [EvidencePoint]
strength: float # 0.0-1.0
antithesis:
position: string
stakeholder: string
evidence: [EvidencePoint]
strength: float
synthesis:
position: string
resolution_type: string
confidence: float
integration:
thesis_addressed: string
antithesis_addressed: string
trade_offs:
- trade_off: string
mitigation: string
accepted_by: string
stakeholder_agreement:
- stakeholder: string
agrees: bool
conditions: optional<string>
implementation:
actions: [string]
metrics: [string]
review_date: date
next:
suggested_mode: ReasoningMode # Usually causal
canvas_updates: [string]
trace:
duration_ms: int
rounds_of_refinement: int
Example Execution
Context: "Engineering wants to rebuild core platform (6 months). Sales wants new features for Q2 deals."
Stage 1 - Thesis (Engineering):
Position: "Technical debt is blocking velocity. Rebuild now or pay 10x later."
Evidence:
- Deploy time increased 300% YoY
- 40% of sprint spent on workarounds
- 3 critical bugs from architecture issues
Underlying concern: Sustainable development velocity
Stage 2 - Antithesis (Sales):
Position: "We have $2M in pipeline dependent on Q2 features. Delay = lose deals."
Evidence:
- 5 enterprise deals waiting on specific features
- Competitor launching similar features in March
- Q2 quota at risk without new capabilities
Underlying concern: Revenue target attainment
Stage 3 - Synthesis:
Integrated position: "Strangler fig pattern - rebuild incrementally while
delivering high-priority features"
How thesis addressed: Platform rebuild happens, but in modules alongside features
How antithesis addressed: Q2 features delivered, no delay
Trade-offs:
- Rebuild takes 9 months instead of 6 (Engineering accepts)
- Only top 3 features in Q2, not all 5 (Sales accepts with prioritization input)
Resolution type: Integration via sequencing
Implementation:
- Week 1: Joint prioritization session (top 3 features + first rebuild module)
- Q2: Deliver features on new modules where possible
- Q3-Q4: Complete rebuild with feature delivery continuing