Skip to main content

What 'Accepting' Really Means

Accepting a card is the most important action in Distil. It's not just clicking a button - it's making a commitment backed by evidence. Here's what acceptance means and how to do it well.

Acceptance Is a Promise​

When you accept a card, you're saying:

"Based on the evidence, this is worth building."

Not:

  • "This is a cool idea"
  • "Someone important asked for this"
  • "This seems useful"

The difference matters. Acceptance should be defensible with data.

What Makes Feedback "Accept-Worthy"?​

Good reasons to accept:

  • Pattern: You've heard this from multiple sources
  • Strategic fit: Aligns with your product vision
  • Data: Usage analytics or research support this
  • Dependency: Blocks other important work
  • Customer value: Solves a real, validated problem

Bad reasons to accept:

  • Gut feeling without evidence
  • HiPPO (Highest Paid Person's Opinion) without validation
  • Squeaky wheel (loudest requester, not most common need)
  • Easy to build (build what matters, not what's convenient)

The Acceptance Process​

Step 1: Gather Signal​

Before accepting, make sure you have evidence. Look for:

  • How many people have asked for this?
  • How recently have we heard about this?
  • Who is asking (customers, prospects, internal teams)?
  • What problem are they trying to solve?
  • What alternatives have they tried?

Add this context to signal notes on the card.

Step 2: Evaluate Fit​

Ask strategic questions:

  • Does this align with our product vision?
  • Is this a core use case or an edge case?
  • Will this be valuable in 6 months, or just today?
  • Does this open up new opportunities or close doors?

Step 3: Document Rationale​

When you click "Accept," you'll be asked for rationale. This should be concise but clear:

Good examples:

  • "Requested by 8 enterprise customers in Q1. Blocking 3 deals per sales."
  • "Top-requested feature in feedback analysis. 23 mentions across Slack, support, and surveys."
  • "Strategic: Required for GDPR compliance. Legal review complete."

Bad examples:

  • "Good idea"
  • "CEO wants this"
  • "Should have this"

The goal is to make future-you (and your team) understand why this mattered.

Acceptance Patterns​

Pattern 1: Clear Winner​

Multiple requests, clear pattern, strategic fit. Accept immediately with confidence.

Example: "Export to CSV" requested by 15 users in 3 weeks, aligns with data portability strategy.

Pattern 2: Slow Burn​

One-off requests that add up over time. Add signal notes and accept when you hit a threshold (e.g., 5 requests).

Example: "Dark mode" mentioned occasionally. After 6 months, you have 12 requests. Now it's worth it.

Pattern 3: Strategic Bet​

Low volume but strategically important. Requires explaining why despite lower demand.

Example: "API rate limiting" requested by 2 users, but necessary for platform health and future scale.

Pattern 4: Dependency Chain​

Not heavily requested, but blocks other accepted work.

Example: "Bulk user import" unlocks "Team management features" which IS highly requested.

With Governance Pack: Enforced Rationale​

If you have the Governance Pack enabled, acceptance rationale is required (not optional).

Why this matters:

  • Creates accountability
  • Prevents rubber-stamping
  • Builds an audit trail for regulated environments
  • Forces critical thinking

Additional features:

  • Cards can be locked after acceptance
  • Acceptance is logged with timestamp and user
  • Changes to accepted cards are tracked

Learn more about Governance Pack

Common Mistakes​

Over-Accepting​

Mistake: Accepting everything that sounds good.

Result: Your "roadmap" becomes meaningless because it contains 200 items.

Fix: Be selective. Only accept what you'll realistically build in the next 6-12 months.

Under-Documenting​

Mistake: Accepting with vague rationale like "seems useful."

Result: Three months later, you have no idea why you accepted this.

Fix: Write rationale that will make sense to future-you without additional context.

Confusing Acceptance with Prioritization​

Mistake: Only accepting things you'll build this quarter.

Result: You lose sight of longer-term roadmap.

Fix: Accept anything validated as worth building eventually. Use separate prioritization methods (tags, projects) to decide sequencing.

HiPPO-Driven Acceptance​

Mistake: Accepting requests from executives or big customers without validation.

Result: Your roadmap is driven by politics, not data.

Fix: Document the source ("Requested by CEO") but also add validation data. If there isn't any, note that too.

Rejecting Feedback (The Alternative to Acceptance)​

Not everything should be accepted. Some feedback is noise.

How to handle noise:

  • Archive: Remove from your view but keep searchable
  • Add a note: Explain why you're not accepting (helps if it comes up again)
  • Link to alternatives: Point to existing features that solve the problem

It's okay to say no. In fact, saying no to noise is how you maintain a meaningful roadmap.

Acceptance Workflows​

Solo PM​

Review Needs Signal weekly. Accept clear winners, add notes to maybes, archive obvious noise.

Team Review​

Weekly 30-minute session. Review top Needs Signal cards as a group. Discuss, then accept or defer.

Async with Comments​

Team members add signal notes and comments on cards throughout the week. PM reviews and accepts Friday afternoon.

Measuring Acceptance Quality​

Good indicators your acceptance process is working:

  • Roadmap is believable: Your Accepted section feels manageable, not overwhelming
  • Rationale is clear: You can read old acceptance rationale and understand the decision
  • Stakeholders trust it: Your team/customers believe in the roadmap because it's data-driven
  • You rarely regret acceptances: Most accepted work still feels valuable months later

Next Steps​