Product feedback prioritization

e = (impact * this.config.impactWeight) + (alignment * this.config.alignmentWeight) + (effort * this.config.effortWeight) + (strategic * this.config.strategicWeight);

const normalizedScore = Math.min(100, Math.max(0, rawScore));

const priority =
  normalizedScore >= this.config.thresholds.autoRoute
    ? 'high'
    : normalizedScore >= this.config.thresholds.reviewRequired
    ? 'medium'
    : 'low';

return {
  ...signal,
  score: Math.round(normalizedScore * 100) / 100,
  breakdown: { impact, alignment, effort, strategic },
  priority,
};

}

private calculateImpact(signal: FeedbackSignal): number { const base = signal.channelWeight * 20; const segmentBoost = signal.segment === 'enterprise' ? 15 : signal.segment === 'power_user' ? 10 : 0; const tagMultiplier = signal.tags.includes('blocker') ? 1.5 : signal.tags.includes('ux_friction') ? 1.2 : 1.0; return Math.min(100, (base + segmentBoost) * tagMultiplier); }

private calculateAlignment(signal: FeedbackSignal): number { const roadmapTags = ['api', 'auth', 'billing', 'analytics']; const matchCount = signal.tags.filter(t => roadmapTags.includes(t)).length; return Math.min(100, matchCount * 25); }

private estimateEffort(signal: FeedbackSignal): number { const effortMap: Record<string, number> = { 'bug_fix': 30, 'feature': 10, 'ux_tweak': 20, 'infra': 5, }; const primaryTag = signal.tags[0] || 'feature'; return effortMap[primaryTag] ?? 15; }

private calculateStrategicFit(signal: FeedbackSignal): number { const strategicKeywords = ['retention', 'conversion', 'scale', 'security', 'compliance']; const hasStrategic = signal.tags.some(t => strategicKeywords.includes(t)); return hasStrategic ? 25 : 5; } }

#### Architecture Decisions & Rationale

- **Stateless Scoring Service**: The scoring engine is stateless by design. It receives a `FeedbackSignal`, applies configuration, and returns a `ScoredSignal`. This enables horizontal scaling, predictable latency, and easy A/B testing of weight adjustments.
- **Configuration-Driven Weights**: Weights are externalized to a version-controlled config file or feature flag service. This prevents code deployments for quarterly recalibration and maintains auditability.
- **Decoupled Integration Layer**: Scoring outputs are published to an event bus (Kafka/SQS) or directly via webhooks to Jira/Linear. This prevents tight coupling between the scoring service and project management tools.
- **Telemetry Feedback Loop**: Post-launch metrics (adoption rate, session duration, support volume) are ingested into a separate analytics pipeline. These metrics trigger automated weight adjustments or flag stale scoring rules for review.
- **Deduplication & Clustering**: Before scoring, signals pass through a clustering service (e.g., TF-IDF + cosine similarity or lightweight LLM embeddings) to group identical requests. This prevents vocal minorities from inflating scores through duplicate submissions.

## Pitfall Guide

1. **Vocal Minority Bias**: Prioritizing based on ticket volume or support queue length rewards users who complain loudest, not those who drive retention. Mitigation: Apply channel weighting, cluster duplicates, and cross-reference with usage telemetry before scoring.
2. **Static Weight Rigidity**: Hardcoding impact, effort, and strategic weights leads to model decay as market conditions shift. Mitigation: Externalize weights to configuration, schedule quarterly calibration sessions, and track model drift using post-launch validation metrics.
3. **Ignoring Implementation Effort**: High-impact requests that require 3+ sprints often displace quick wins that compound value. Mitigation: Integrate effort estimation early, apply non-linear effort penalties in scoring, and maintain a separate "quick win" queue for high-ROI/low-effort items.
4. **Missing Post-Launch Validation**: Scoring models that never measure actual adoption become self-fulfilling prophecies. Mitigation: Instrument feature flags, track adoption within 14/30/90-day windows, and feed results back into weight adjustments or model retraining.
5. **Channel Silos & Duplicate Noise**: Intercom, GitHub, and survey tools report the same request as separate signals. Mitigation: Implement a normalization layer with fuzzy matching or embedding-based clustering before scoring. Deduplication must run pre-scoring, not post-scoring.
6. **Over-Engineering the Scoring Model**: Adding machine learning or complex NLP pipelines before establishing baseline metrics introduces latency and debugging overhead. Mitigation: Start with deterministic weighted scoring. Introduce ML only after you have 6+ months of labeled feedback and clear failure modes in the baseline model.
7. **No Feedback Loop Closure**: Users submit requests and never see status updates, eroding trust and increasing duplicate submissions. Mitigation: Automate status sync back to source channels. Close the loop with public roadmap visibility or automated acknowledgment messages tied to scoring priority.

**Best Practices from Production:**
- Treat scoring as a versioned contract. Changes to weights or thresholds must be logged and reversible.
- Separate signal collection from decision-making. The scoring service should never block ingestion.
- Use feature flags to gate scoring model updates. Roll out weight changes to 10% of signals first, monitor queue distribution, then expand.
- Maintain a scoring audit trail. Every `ScoredSignal` should store the config version used, enabling retrospective analysis of why a feature was prioritized.
- Align scoring thresholds with sprint capacity. If the engineering team handles 15 story points per sprint, the `autoRoute` threshold should map to that throughput ceiling.

## Production Bundle

### Action Checklist
- [ ] Ingest feedback from all channels into a unified schema with source, segment, and tags
- [ ] Implement deduplication/clustering before scoring to neutralize vocal minority noise
- [ ] Externalize scoring weights to a version-controlled configuration file or feature flag service
- [ ] Deploy the scoring engine as a stateless service with deterministic output and audit logging
- [ ] Route scored signals to Jira/Linear via webhooks or SDK with priority breakdown attached
- [ ] Instrument post-launch telemetry to track adoption, retention, and support volume
- [ ] Schedule quarterly weight calibration sessions using actual impact data
- [ ] Close the feedback loop by syncing status back to source channels automatically

### Decision Matrix

| Scenario | Recommended Approach | Why | Cost Impact |
|----------|---------------------|-----|-------------|
| Early-stage startup (<50 employees) | Static Impact/Effort Matrix | Low overhead, fast iteration, limited feedback volume | Minimal engineering time, manual PM oversight |
| Scale-up SaaS (50–300 employees) | Weighted Scoring Engine | Handles channel fragmentation, requires auditability, scales with ticket volume | Moderate infra cost, 1–2 weeks engineering setup |
| Enterprise/Platform team | Customer-Journey Aligned Scoring | Aligns with complex user segments, requires mature telemetry and cross-functional calibration | Higher telemetry cost, dedicated data engineering |
| High-churn product recovery | Dynamic Weight Calibration + Quick Win Queue | Prioritizes retention signals, separates low-effort fixes from strategic builds | Short-term capacity reallocation, measurable churn reduction |

### Configuration Template

```json
{
  "scoringModel": "v2.1",
  "weights": {
    "impactWeight": 0.35,
    "alignmentWeight": 0.25,
    "effortWeight": 0.20,
    "strategicWeight": 0.20
  },
  "thresholds": {
    "autoRoute": 75,
    "reviewRequired": 50
  },
  "channelWeights": {
    "intercom": 1.0,
    "github": 0.8,
    "survey": 0.6,
    "support": 0.9
  },
  "deduplication": {
    "enabled": true,
    "similarityThreshold": 0.85,
    "windowHours": 72
  },
  "routing": {
    "target": "linear",
    "webhookUrl": "${LINEAR_WEBHOOK_URL}",
    "projectId": "${LINEAR_PROJECT_ID}",
    "priorityMapping": {
      "high": "urgent",
      "medium": "high",
      "low": "medium"
    }
  }
}

Quick Start Guide

1. Initialize the scoring service: Clone the repository, install dependencies, and load the configuration template into your environment. Set SCORING_CONFIG_PATH to point to the JSON file.
2. Connect ingestion webhooks: Configure Intercom, GitHub, and support tools to forward raw feedback payloads to the /ingest endpoint. Ensure payloads include source, userId, tags, and text.
3. Deploy the scoring engine: Run npm run build && npm start. The service exposes /score for synchronous evaluation and publishes scored signals to the configured routing target. Verify with a test payload using curl -X POST http://localhost:3000/score -H "Content-Type: application/json" -d @test-signal.json.
4. Validate post-launch metrics: Instrument feature flags for routed items. Track adoption at 14/30/90 days. Adjust weights in the configuration file and restart the service or use feature flag rollout to apply changes without downtime.
5. Calibrate quarterly: Review queue distribution, adoption rates, and engineering ROI. Update weights and thresholds in the config, commit the version bump, and document the rationale in the scoring audit log.