Skip to main content

Signal vs. Noise

The core skill in using Distil is learning to separate signal (patterns worth building for) from noise (one-off requests or distractions). This guide will help you develop that instinct.

What Is Signal?​

Signal is feedback that represents a real, recurring problem worth solving.

Characteristics of signal:

  • Repeated: You've heard it multiple times
  • Validated: Users demonstrate real pain, not hypothetical needs
  • Aligned: Fits your product strategy and vision
  • Actionable: Clear what success looks like
  • Impactful: Solving it creates meaningful value

What Is Noise?​

Noise is feedback that feels urgent but doesn't represent true patterns.

Characteristics of noise:

  • One-off: A single request without supporting evidence
  • Solution-focused: "Add this button" instead of "I can't do X"
  • Misaligned: Doesn't fit your product direction
  • Vague: "Make it better" without specific problems
  • Edge case: Applies to 1% of users in rare situations

The Gray Area​

Most feedback isn't obviously signal or noise. It's somewhere in between.

Your job: Add signal notes and watch for patterns. A piece of "noise" today might become "signal" in three months when you hear it again.

How to Detect Signal​

1. Look for Patterns Across Sources​

Signal example:

  • Mentioned in 3 customer calls this week
  • 2 support tickets about the same issue
  • Posted in your feedback Slack channel twice
  • → Pattern detected: This is signal

Noise example:

  • One customer emailed a feature request
  • No other mentions anywhere
  • Not a common problem in your experience
  • → Likely noise (but add a note and watch)

2. Dig into the "Why"​

When you get feedback, don't take it at face value. Ask:

  • What problem are you trying to solve?
  • What have you tried so far?
  • How often does this come up?

Signal reveals itself when you dig:

  • User: "Add a dark mode"
  • You: "What's the problem you're experiencing?"
  • User: "I work late and the bright UI gives me headaches"
  • → Real problem. Check if others have this issue.

Noise reveals itself too:

  • User: "Add a purple color scheme"
  • You: "What's the problem you're experiencing?"
  • User: "I just like purple"
  • → Personal preference, not a validated need.

3. Validate with Usage Data​

Look at your analytics:

  • Signal: "Users struggle with bulk import" + data shows 40% of users hit import errors
  • Noise: "Add export to PDF" + data shows only 2 users ever clicked export in the past month

Data doesn't tell you everything, but it helps validate or refute hunches.

4. Check Strategic Alignment​

Even validated patterns might be noise for your product.

Ask:

  • Does this fit our vision?
  • Will this matter in 12 months?
  • Does this open up new opportunities or distract from core value?

Example: You're building a B2B tool. A consumer user asks for Instagram integration. Even if 10 consumers ask, it's noise for your strategy.

Common Types of Noise​

The "Nice to Have"​

Mild improvement that sounds pleasant but solves no real problem.

Example: "Make the logo bigger"

How to handle: Thank them and archive. No signal notes needed.

The "That's Actually a Bug"​

Not feature feedback - just something broken.

Example: "Add a way to delete items" (when delete already exists but isn't working)

How to handle: Create a bug ticket in Jira/Linear. Don't put bugs in Distil.

The "I Want Your Product to Be Different"​

Request to fundamentally change your product's purpose.

Example: You build project management software. User asks you to add CRM features.

How to handle: Archive. Add a note: "Out of scope - we're focused on project management, not CRM."

The "Workaround Exists"​

Problem already solvable with existing features.

Example: "Add a way to see all cards at once" (when filtering shows this)

How to handle: Might indicate a UX issue. Note it and watch for pattern. If more users miss the feature, it's a discoverability problem.

The "Over-Optimization"​

Micro-improvement that affects almost no one.

Example: "The spacing between lines should be 2px larger"

How to handle: Archive unless you see a pattern of UX complaints about readability.

When Noise Becomes Signal​

Sometimes "noise" evolves into "signal" over time:

Month 1: One user asks for SSO

  • Action: Add to Distil, tag "enterprise," leave in Needs Signal

Month 2: Another user asks for SSO

  • Action: Add signal note: "2nd request, both from enterprise segment"

Month 3: SSO mentioned in 2 sales calls as a blocker

  • Action: Update signal note: "Now blocking deals per sales"

Month 4: 5 total requests, 3 from paying customers

  • Action: Accept with rationale: "Clear enterprise pattern, blocking expansion"

This evolution from noise to signal is why you keep feedback in Distil (don't immediately delete things).

Handling Ambiguity​

You won't always know if something is signal or noise right away. That's okay.

The Distil approach:

  1. Add it to Needs Signal (don't accept or archive yet)
  2. Add a signal note with what you know
  3. Watch for supporting evidence over the next few weeks
  4. Accept if a pattern emerges, archive if it stays quiet

Pro tip: Review your Needs Signal section weekly. If something has been sitting there for 3 months with no additional signal, it's probably noise. Archive it.

Cultural Signals vs. Product Signals​

Sometimes feedback is less about what users want and more about how they feel.

Example: You get 5 complaints that "the app feels slow"

  • This might not be about actual performance (metrics look fine)
  • It might be about perceived responsiveness (loading states, animations)
  • The signal is: Users feel frustrated. The solution isn't necessarily "make it faster."

Dig deeper to understand the real problem.

Balancing Signal Detection with Speed​

Don't let signal detection paralyze you.

Fast decisions:

  • Obvious signal (10+ requests) → Accept immediately
  • Obvious noise (single request, out of scope) → Archive immediately

Slow decisions:

  • Ambiguous feedback → Add signal notes, revisit in 2 weeks

The goal is to move things out of Needs Signal regularly. Don't let your inbox pile up with 200 "maybes."

Signal Metrics to Track​

Consider tracking:

  • Accept rate: % of Needs Signal cards that eventually get accepted (target: 20-40%)
  • Time to decision: How long cards sit in Needs Signal before accept/archive (target: <30 days)
  • Regret rate: % of accepted cards you later wish you hadn't accepted (target: <10%)

These metrics tell you if your signal detection is well-calibrated.

Next Steps​