---
name: multi-pov-decision-framework
description: Structured multi-perspective synthesis framework for complex buy-vs-build, vendor selection, architecture choice, and course/playbook evaluation decisions. Enforces epistemological discipline by requiring explicit perspective-taking across domain-expert roles, surfacing blind spots that single-perspective analysis misses.
category: research
tags:
  - decision-making
  - multi-perspective
  - synthesis
  - buy-vs-build
  - vendor-evaluation
  - risk-analysis
  - epistemology
related_skills:
  - research-agent
  - systematic-debugging
  - plan
  - spike
---

# Multi-POV Decision Framework

A structured method for evaluating complex decisions by adopting multiple senior-expert perspectives, synthesizing their distinct risk/reward lenses, and producing a decision artifact that closes blind spots.

## When to Use

- Buy-vs-build decisions for tools, courses, platforms, infrastructure
- Vendor/platform selection with long-term lock-in risk
- **Tech-stack and architecture evaluation** (e.g., "Cloudflare D1 vs Postgres for a relational app at 1M users/day") — the user's preferred method for infrastructure decisions
- **Open-source project maturity assessment** (evaluate a repo for production readiness, fork viability, bus factor)
- Course/playbook/certification ROI evaluation
- Any decision where "it depends on who you ask" is the honest answer

## Adaptations by Decision Type

### For Tech-Stack / Architecture Decisions

The standard roster adapts to infrastructure-specific roles. When the user says "give me senior programmer POV, risk manager POV" or asks for a multi-perspective review of a stack plan:

**Use these 6 perspectives (proven effective):**

| Perspective | Core Question for Stack Eval |
|-------------|------------------------------|
| Senior Backend Engineer | Database limits, write throughput, JOIN performance, transaction guarantees, migration path |
| Senior Frontend Engineer | Rendering strategy (SSR/islands), state management, animation feasibility, offline capability |
| DevOps/SRE | Deployment pipeline, CI/CD, backup strategy, monitoring, cost projection at target scale |
| Security Engineer | Auth on edge, rate limiting, abuse prevention (scraping), data encryption |
| Product Manager | MVP scope realism, timeline, feature prioritization, what to cut for v1 |
| Risk Manager | Vendor lock-in, tech immaturity, bus factor, blast radius of failures |

**Key additions to the standard framework:**
- **Verify limits empirically.** Don't quote docs from memory — fetch the official limits page (e.g., `developers.cloudflare.com/d1/platform/limits/`) and independent benchmarks. Cloudflare D1's write limit is ~50-200/sec, not "unlimited."
- **Cost-project at the target scale.** Calculate per-request/per-write costs at the user's stated scale (e.g., 1M visitors/day), not at the free tier.
- **Always identify a migration path.** If recommending a technology with known ceilings (D1 write limit, 10GB cap), name the specific alternative and the migration effort.
- **Deliver in plain language when asked.** If the user requests "10th grader explanation," use analogies (restaurant kitchen = server, pantry = database) before the technical version. Match complexity to the user's signal.

### For Open-Source Project Assessment

When evaluating a repo (e.g., "Is this production ready? What if we fork this?"):
- Fetch GitHub API data: stars, fork count, contributor count, commit velocity, last commit date, release cadence
- **Bus factor is the #1 signal.** If one contributor has >90% of commits, the project is one person's availability away from stalling
- Check issue tracker quality: are bugs being addressed? Are feature requests engaged with?
- Evaluate architecture docs quality — projects with `architecture.md` and enforced test gates are more maintainable
- Read the README's honesty about version status ("v0.0.x, APIs may change" = truthful, not ready)

## The Framework

### 1. Define the Decision Object
State precisely what is being evaluated (course, tool, vendor, architecture), the claimed value prop, the cost (money + time + risk), and the decision deadline.

### 2. Select Perspectives (Minimum 5, Ideal 7-9)
Choose perspectives that collectively cover:
- **Technical feasibility** (can we build/maintain it?)
- **Business viability** (does it move our metrics?)
- **Risk/compliance** (what kills us?)
- **User/customer impact** (does it serve the actual user?)
- **Brand/design integrity** (does it dilute or strengthen identity?)
- **Operations/scaling** (what breaks at 10x?)
- **Data/evidence** (what do we actually know vs. assume?)
- **Project management** (what's the real timeline to value?)

Standard perspective roster (adapt per decision):
| Perspective | Core Question |
|-------------|---------------|
| Senior [Domain] Engineer | Can we build/maintain this reliably? |
| Senior Product/Business Strategist | Does this move our north-star metric? |
| Senior Risk/Compliance/Legal | What are the existential failure modes? |
| Senior Data Analyst/Scientist | What evidence supports the claims? |
| Senior Project/Program Manager | What's the real critical path to value? |
| Senior Brand/Design Lead | Does this strengthen or dilute our identity? |
| Senior [Channel] Specialist | Does this work for OUR specific context? |
| Senior Platform/DevOps Engineer | What breaks at scale / in production? |

### 3. Execute Each Perspective Independently
For each perspective, produce:
- **Verdict** (Buy / Build / Hybrid / Pass)
- **Confidence** (High / Medium / Low)
- **Key evidence needed** (what would change your mind)
- **Blind spots this perspective *cannot* see** (explicit admission)
- **Non-negotiables** (conditions that would flip the verdict)

### 4. Synthesize: The Integration Layer
Do NOT just list perspectives. Produce a unified artifact with:

| Section | Purpose |
|---------|---------|
| **Consensus Zone** | Where ≥5 perspectives agree — these are your bedrock facts |
| **Constructive Tension** | Where perspectives conflict — these are your decision variables |
| **Hidden Risks** | Risks only visible from 1-2 perspectives — these are your blind spots |
| **Decision Matrix** | Scored dimensions (cost, time, risk, strategic value, reversibility) |
| **Hybrid Path** | The "buy the prompts, build the platform" or equivalent synthesis |
| **Go/No-Go Gates** | Measurable criteria to proceed or kill at each phase |

### 5. Decision Gates (Time-Boxed)
| Gate | Timeline | Criteria | Kill Signal |
|------|----------|----------|-------------|
| **Audit** | Hours-days | Can we verify claims? Access artifacts? | No access to prompts/repo/metrics |
| **Prototype** | Days-weeks | Can we build a thin slice that proves value? | Core promise fails in our context |
| **Validate** | Weeks | Do our metrics beat the claimed benchmarks? | Ban risk, cost overrun, quality gap |
| **Productionize** | Months | Is the infrastructure sustainable? | Technical debt > strategic value |

## Anti-Patterns to Avoid

| Anti-Pattern | Symptom | Fix |
|--------------|---------|-----|
| **Single-perspective rationalization** | "As an engineer I think..." × 7 | Enforce role separation; write each POV in isolation first |
| **Consensus theater** | Everyone agrees too fast | Assign a "red team" perspective explicitly |
| **Evidence laundering** | Treating marketing claims as data | Tag every claim: *verified / single-source / inferred / marketing* |
| **Context stripping** | Applying generic advice to specific case | Every POV must address: "Why *us*, *now*, *this niche*?" |
| **Reversibility blindness** | Treating all decisions as equal | Score reversibility; irreversible decisions get more POVs |

## Output Template

```markdown
# Decision: [What] — [Buy/Build/Hybrid/Pass]

## Decision Object
- **Evaluated**: [Course/tool/vendor name + link]
- **Claimed Value**: [1-sentence promise]
- **Total Cost**: [$ + hours + risk surface]
- **Deadline**: [Date or "next sprint"]

## Perspective Matrix
| Perspective | Verdict | Confidence | Key Condition to Flip |
|-------------|---------|------------|----------------------|
| Senior AI Automation Architect | Hybrid | High | Prompts are battle-tested |
| Senior Digital Marketing Strategist | Buy (prototype) | Medium | Format fits our niche |
| Senior Data Analyst | Pass (evidence gap) | Low | Need n=2 | Survivorship bias unaddressed |
| Senior Risk Manager | **Pass** (platform risk) | **High** | Meta API compliance unproven |
| Senior Project Manager | Buy (prototype budget) | High | $9 = 40h saved |
| Senior Brand Designer | Hybrid | Medium | Brand-DNA prompts actually work |
| Senior Social Media Strategist | Buy (niche fit) | High | Founder-led tech content = our lane |
| Senior Platform Engineer | Build (infra gap) | High | Playbook ≠ production infra |

## Consensus Zone (Bedrock)
- Prototype cost << build cost ($9 vs 40-60h)
- Niche fit is strong (founder-led AI/tech content)
- Prompts are the IP, not the glue code

## Constructive Tension (Decision Variables)
| Dimension | Buy Camp | Build Camp | Resolution |
|-----------|----------|------------|------------|
| Compliance | "Randomized schedule works" | "Meta bans at 1K-5K followers" | **Gate: Test on burner account first** |
| Brand DNA | "65 locked prompts" | "GPT Image 2 doesn't support tokens" | **Gate: Audit prompt repo in audit phase** |
| Time-to-value | "Week 1 working" | "Week 4-6 for same" | **Hybrid: Buy prompts, build infra** |

## Hidden Risks (Blind Spots)
- 🔴 **Platform risk**: Meta Graph API app review rejects new accounts (Risk POV only)
- 🔴 **Survivorship bias**: 2 accounts shown, 98 failed hidden (Data POV only)
- 🟡 **Brand dilution**: AI carousels look "AI" after 50 posts (Brand POV only)
- 🟡 **Cost creep**: $164-539/mo ops cost not in $9 price (PM + Platform POV)

## Hybrid Path (Recommended)
1. **Audit** (2h): Buy $9 playbook → extract prompts → verify repo → score claim evidence
2. **Prototype** (Week 1-2): Run playbook on test account → measure engagement quality, ban signals, real costs
3. **Validate** (Week 3-4): Compare playbook metrics vs. custom pipeline on same niche
4. **Decide**: Adopt prompts + build infra / Fork prompts + build infra / Abandon

## Go/No-Go Gates
| Gate | Metric | Threshold |
|------|--------|-----------|
| Audit | Prompt repo accessible + 3+ claims verifiable | ✅/❌ |
| Prototype | Test account: >3% engagement rate, 0 ban warnings, <$50/day ops | ✅/❌ |
| Validate | Custom pipeline matches/exceeds playbook metrics at ≤1.5x cost | ✅/❌ |

## References
- `references/promptbase-automation-playbook-case-study.md` — Full worked example: buy-vs-build evaluation of a social media automation playbook
- `references/cloudflare-stack-tarot-app-case-study.md` — Full worked example: tech-stack architecture evaluation (D1 vs Postgres/Hyperdrive) with 6 expert POVs
- `references/multi-pov-template.md` — Reusable template for future decisions
```

## Verification Checklist

- [ ] Decision object precisely defined
- [ ] ≥5 distinct perspectives executed independently
- [ ] Each perspective states blind spots explicitly
- [ ] Claims tagged with evidence quality (verified/single-source/inferred/marketing)
- [ ] Consensus zone separated from constructive tension
- [ ] Hidden risks surfaced (not just "risks")
- [ ] Hybrid path proposed (not binary)
- [ ] Go/no-go gates are measurable and time-boxed
- [ ] Reversibility scored per decision path