technical-feasibility-assessment

name	technical-feasibility-assessment
effort	high
description	Use when a PM or product team needs a rapid feasibility signal on a feature idea before committing engineering time — assessing implementation risk, complexity, and make-vs-buy tradeoffs without full engineering involvement. Triggers on: "technical
license	MIT
metadata	{"author":"wondelai","version":"1.0.0"}
scenarios	["Product wants to build X — can you give me a quick technical feasibility read?","Help me assess whether this feature can be built in 2 sprints with our current stack","Run a feasibility check on this AI integration before we commit to the roadmap","이 기능이 우리 현재 스택으로 2스프린트 안에 가능한지 빠르게 평가해줘","로드맵 확정 전에 기술 타당성 검토를 도와줘"]
compatibility	{"recommended":["think-tool"],"optional":["sequential-thinking"],"remote_mcp_note":"think-tool이 있으면 5개 가능성 차원(데이터, 인프라, 통합, 팀 역량, 시간)에 대한 판단의 품질이 높아집니다. Claude 설정 → MCP Servers에서 remote SSE 엔드포인트를 추가하세요."}

Standing Mandates

• ALWAYS assess all five feasibility dimensions: data, infrastructure, integration, team capability, and timeline.
• ALWAYS surface the single highest-risk assumption explicitly.
• NEVER give a binary feasible/not-feasible answer without a confidence level.
• NEVER assess feasibility without knowing the team's current stack and capacity constraints.

Technical Feasibility Assessment Framework

When to Use / When Not to Use

Use when:

• Deciding whether to include a feature in the roadmap before engineering is consulted
• Running a reality check at a Shape Up betting table
• Writing the Constraints / Technical Dependencies section of a PRD
• Evaluating build vs. buy vs. partner for a new capability

Not for:

• Engineering sprint estimation or story pointing
• Detailed architecture design decisions
• Contract negotiation with vendors

Process

1. Describe the feature — what it does, who it's for, any known constraints or deadlines
2. Score 5 dimensions — Data, Infrastructure, Integrations, Team Skill, Time (each: Low / Medium / High risk)
3. Identify red flags — any dimension flagging "escalate to engineering immediately"
4. Make vs. buy recommendation — based on differentiation, time-to-value, and team capability
5. Document risks — produce the PRD technical constraints section format

Output Template

Feasibility Signal: [High / Medium / Low / Unknown]

Dimension scores:
- Data: [Low / Medium / High risk] — [one sentence rationale]
- Infrastructure: [Low / Medium / High risk] — [one sentence rationale]
- Integrations: [Low / Medium / High risk] — [one sentence rationale]
- Team Skill: [Low / Medium / High risk] — [one sentence rationale]
- Time: [Low / Medium / High risk] — [one sentence rationale]

Make vs. Buy recommendation: [Build / Buy / Partner] — [reasoning]

Red flags requiring engineering consultation before any commitment:
- [if any]

Recommended next step: [what to investigate before treating this as feasible]

What Claude Does / What You Do

Claude	You
Scores 5 feasibility dimensions with rationale	Validates signals with engineering before committing
Identifies red flags that require engineering consultation