Skip to main content

Size how widespread something is

Every team has had this meeting. Someone says a problem is huge. Someone else says it's a vocal minority. Both are working from impressions, the argument is unwinnable, and whoever is most senior or most insistent decides what gets built.

This playbook replaces the impression with a number. It's the single highest-value thing Kinn does, and it's the thing people most often don't realize they can ask for.

When to use it​

Reach for this when the answer changes a decision:

  • Before moving a deadline or reprioritizing a sprint
  • When two people disagree about severity
  • Before telling leadership something is or isn't a crisis
  • When a loud thread feels like a crisis and you need to check

Don't reach for this while you're still exploring. There's no mode to switch on — Kinn decides how much depth a question needs from the question itself — so a wandering ask just gets a quick answer. Figure out what you actually want to measure first, then measure it once, properly.

1. Turn the vague claim into a measurable one​

"People hate the new UI" can't be measured. You have to decide what would count:

  • What exactly counts as an instance? Complaints about the button placement, or any negative comment about the redesign at all?
  • Over what window? Since the release, or the last 30 days?
  • Out of what? All feedback, or just feedback about the UI?
  • Broken down by what? Platform, device, before/after the patch, new versus returning users?

That last one is where most of the value hides. "12% of feedback" is interesting. "12% overall, but 31% on Android and 3% on iOS" is a decision.

2. Ask the sizing question​

Put those choices into one request:

How widespread is the complaint about the new inventory UI? Look across Discord, Steam and Reddit for the last 30 days. Count anything that criticizes the inventory redesign — including people describing it as confusing or slow, not just people saying "UI." Break it down by platform, and separately by whether they mention it on console or PC. Tell me what share of each source's feedback it represents.

That's long, and it should be. Every clause removes an assumption Kinn would otherwise have to make for you.

A question shaped like this can't be answered off the top of Kinn's head, so it gets handed to the research agent: it measures what's in the window before retrieving, collects the complete matching set, classifies every record, and computes the counts with arithmetic rather than estimation. You don't switch that on — the specificity of the question is what summons it. See Deep research.

3. Read the denominators first​

The percentage is the least important number on the page. Look at what it's a percentage of before you quote it anywhere.

"18% of feedback" against 2,000 Steam reviews is a serious finding. The same 18% against 30 Discord messages is five or six people, and means almost nothing. This is exactly why Kinn keeps a separate denominator for each source instead of blending them — Steam reviews and Discord messages aren't the same kind of thing and averaging them produces a number that describes nothing real.

4. Read the coverage notes​

Kinn reports what it couldn't see as a first-class part of the answer: gaps in the window, content that isn't indexed, sources that couldn't be collected completely.

When you see those, the honest interpretation is "this is a floor, not a total." That's still useful — a floor of 12% is plenty to act on — but it's a different claim from "exactly 12%," and the difference matters if someone challenges it later.

5. Spot-check the evidence​

Before a number goes into a deck, read three of the underlying quotes. It takes thirty seconds and it's the fastest way to catch a mis-scoped question — usually that the classification swept in something you didn't mean, or missed a phrasing you didn't anticipate.

Show me five representative quotes behind that 18%, with links.

If they don't look like what you meant, adjust the definition and re-run. That's a normal part of the process, not a failure.

6. Follow up with the questions that explain it​

The size tells you whether to care. These tell you what to do:

Of the people reporting it, what do they have in common?

Did this start with a specific release, or has it been building?

What are the people who aren't complaining saying about the same feature?

That last one catches the case where a change is genuinely popular and a small group is very loud about hating it.

A note on discovery counts​

If you found the issue through a theme-discovery question — "what keeps coming up?" — the support number next to each theme is not prevalence. It's a grounded lower bound: at least this many records cited this theme. It tells you the theme is real. It does not tell you how common it is.

Always follow a discovery finding with an explicit sizing question before you treat it as a measurement.

Common mistakes​

Quoting a percentage without its denominator. The most common way to be confidently wrong in a meeting.

Sizing a loud thread instead of a problem. A 200-reply thread is one thread. Ask how many distinct people, out of how much total feedback.

Defining the question around the words you expect. Describe the problem, not the phrasing — otherwise you'll miss paraphrases and every non-English report.

Measuring before you know what you're measuring. If you find yourself re-running the same investigation with slightly different wording five times, stop and go back to step 1.

Treating a floor as a total. When coverage is incomplete, say "at least" when you quote it.

Next​