Listen without promising everything

1722. Lesson identity

Module

4.9 — Community management

Lesson

L1 — Listen without promising everything

Academic type

Concept

Schema type

text

Order

1

Estimated time

30–40 minutes, including practice

1723. Learning objective

After this lesson, you can classify community feedback using six primary categories—bug report, usability issue, request, confusion, abuse, and irrelevant signal—identify the evidence and decision owner, protect private information, and select a bounded next action without making an unsupported promise.

1724. Why this matters

Community messages do not arrive as clean product requirements. One message may report broken behavior, reveal difficulty using an interface, ask for a new capability, show misunderstanding, violate conduct rules, or have no actionable connection to the product. Treating every comment as an instruction produces unstable priorities and commitments that the team may not have approved.

Structured listening preserves trust without turning agreement, attention, or investigation into a promise. It also prevents abusive or irrelevant messages from distorting product decisions while allowing independently actionable evidence to be preserved.

1725. Prior knowledge

You should have completed 4.8 L2 — Write an honest store-page strategy. You should already be able to distinguish a product claim from its supporting evidence and recognize when communication requires an explicit clarification.

1726. Core concept

The core concept is feedback triage: collect the signal, assign one primary category, identify available and missing evidence, route the decision to an authorized owner, and choose a bounded response.

Use these six primary categories consistently:

1. Bug report — a report that behavior does not work as intended or documented.
2. Usability issue — evidence that a person can understand the intended goal but has difficulty operating, navigating, reading, or completing the interaction.
3. Request — a proposal for a new or changed capability, rule, option, or piece of content.
4. Confusion — evidence that a person cannot understand an instruction, objective, interface message, product claim, or expected next step.
5. Abuse — harassment, threats, discriminatory language, targeted insults, or other conduct that requires moderation handling.
6. Irrelevant signal — spam or material with no actionable relationship to the product, support question, or community decision at hand.

A comment can contain more than one signal. Create separate records when distinct signals require different owners or actions. For example, moderate abusive language while separately recording a reproducible bug report contained in the same message.

Preference and expectation risk are optional diagnostic notes, not primary categories. A preference can explain why someone made a request without establishing a defect. Expectation risk can flag that published communication may have contributed to confusion, but the primary category must still come from the six-category set.

For each record, ask:

1. What is the primary category?
2. What evidence is already present, and what evidence is necessary?
3. Who has authority to verify, moderate, or decide?
4. What bounded action can happen next?
5. What information must remain private?

1727. Mental model

Use the Signal–Evidence–Boundary–Owner–Action model:

Write a triage record as:

Feedback → Primary category → Evidence → Optional tags → Owner → Next action → Response boundary → Privacy disposition

1728. Privacy rule

Request only the minimum diagnostic information needed. Do not solicit, retain unnecessarily, or repeat publicly:

• passwords, credentials, recovery codes, or authentication tokens;
• private account details or personal contact information;
• payment information;
• unredacted logs or screenshots containing personal data;
• recordings that expose unrelated private conversations, names, or notifications.

Ask the person to redact unrelated information. If necessary evidence may be sensitive, move it to an approved private support channel and do not summarize its private contents in a public response. Record where the evidence was routed and whether the public copy was removed or redacted.

1729. Reusable community triage matrix

1730. Response-boundary template

Use this structure for a short public response:

1. Acknowledge: State what you understood without overstating certainty.
2. Current action: Say what will be checked, documented, clarified, or moderated.
3. Boundary: State what has not been decided or approved.
4. Safe evidence request: Ask only for necessary, redacted information and direct sensitive material to an approved private channel.

Template:

Thanks for reporting [observed concern]. We are [bounded action]. This does not yet mean [unapproved outcome or timing]. If you share [minimum necessary evidence], please remove personal or account information and use [approved private support channel] if the evidence is sensitive.

1731. Concrete examples

A player writes: “The first contract is confusing. Add a tutorial, remove the timer, and make the objective clearer.”

A weak response is: “We agree. We’ll add a tutorial and remove the timer soon.” It converts proposed solutions into commitments before the underlying problem has been verified.

A stronger triage record is:

• Primary category: Confusion.
• Evidence: One report; identify the unclear objective text and the point where the next step became uncertain.
• Optional tags: Preference may apply to the proposed timer removal, but it is not the primary category.
• Owner: Design or production reviews the contract; community management gathers minimal evidence.
• Next action: Add the report to the initial-experience review queue and request the unclear text or decision point.
• Boundary: Do not promise a tutorial, timer change, redesign, or release date.
• Privacy disposition: Ask for a cropped, redacted image if one is needed; do not request account details or an unredacted recording.

A suitable public response is: “Thanks for pointing this out. We’re reviewing whether the first contract communicates the next objective clearly, but no specific redesign has been approved. If you can identify the objective text or moment that became unclear, please avoid including personal or account information.”

Consider a second message: “You are incompetent. Fix the reward bug—the screen says 200 credits, but I received 100.” This contains two distinct signals:

• Abuse: Route the conduct violation to the authorized moderator.
• Bug report: Record the stated expected and observed results for verification.

Do not let the abusive framing create a product commitment, but do not erase independently actionable bug evidence. Any screenshot should be redacted and moved to an approved private channel if it displays private account information.

A message containing only unrelated promotion or repeated spam is an irrelevant signal, not abuse unless it also violates a conduct rule. Set it aside or moderate it according to the applicable checklist without creating a product task.

1732. Moderation and escalation checklist

Before acting, verify:

• Is this a product signal, a conduct issue, an irrelevant signal, or more than one separate record?
• Does the assigned role have authority to moderate, verify, or decide?
• Does the applicable community policy require removal, warning, escalation, preservation, or no action?
• Can actionable product evidence be separated from abusive content safely?
• Does the record contain personal data, credentials, tokens, account details, or unredacted logs?
• Should sensitive evidence be removed from public view and routed to an approved private support channel?
• Does the response avoid unsupported promises about features, fixes, outcomes, or timing?

1733. Common mistakes

• Replacing the primary categories with preference or expectation risk. These may be optional notes, but they do not replace the six required categories.
• Combining abuse and irrelevant signal. Abuse requires conduct reasoning; irrelevant material may simply be redirected, removed, or set aside.
• Treating a requested solution as proof of the underlying problem.
• Discarding valid product evidence because it appeared beside abusive language.
• Asking publicly for unredacted screenshots, logs, account details, or recordings containing unrelated private information.
• Naming an undefined “team” instead of the role authorized to verify, moderate, or decide.

1734. Guided practice

For each item, complete these fields: primary category, evidence, optional tags, owner, next action, response boundary, and privacy disposition.

Choose exactly one primary category for each record: bug report, usability issue, request, confusion, abuse, or irrelevant signal. If a message contains separable signals, create separate records.

1. “The controls feel wrong on my setup. The character continues moving after I release the key.”
2. “Please add a photo mode. Every serious game has one.”
3. “Your store page says the objective is clear, but I could not tell what to do after the first checkpoint.”
4. “I understand how the route screen works, but the labels are too small for me to read comfortably.”
5. “The contract says it rewards 200 credits, but the result screen gave me 100.”
6. “You are incompetent. Stop posting your useless game here.”
7. A repeated advertisement for an unrelated product is posted across several support threads.

For evidence requests, apply data minimization. For example, item 1 may justify asking for the input device, platform context, and a short redacted recording, but it does not justify requesting credentials, authentication tokens, private account details, or unredacted system logs.

The mandatory decision is item 3. Classify it using one primary category, identify whether the published claim, in-product communication, or both require review, and write a public response of no more than three sentences. The response must acknowledge the concern, avoid promising a redesign, request only necessary evidence, and warn against sharing personal or account information publicly.

1735. Validation / evidence

Your work is valid when:

• Every record uses one of the six primary categories: bug report, usability issue, request, confusion, abuse, or irrelevant signal.
• Abuse and irrelevant signal are handled separately.
• Preference and expectation risk appear only as optional diagnostic notes when useful.
• Mixed messages are separated when their signals require different owners or actions.
• Evidence requests are necessary and proportionate.
• No response requests or repeats passwords, credentials, tokens, private account details, payment information, or unredacted personal data.
• Sensitive evidence is routed to an approved private support channel rather than exposed publicly.
• Each record names an authorized owner and a bounded next action.
• Public responses acknowledge the signal without promising an unapproved feature, fix, outcome, or date.

Review each response by asking: “What exactly has been promised, what authority supports it, and what private information could this exchange expose?” Revise any response that exceeds the available evidence, authority, or privacy boundary.

1736. Key takeaways

• The six primary categories are bug report, usability issue, request, confusion, abuse, and irrelevant signal.
• Preference and expectation risk are optional diagnostic notes, not replacement categories.
• Abuse and irrelevant signal require different reasoning and handling.
• Evidence requests must be minimal, redacted when appropriate, and moved to an approved private channel when sensitive.
• Ownership prevents community replies from becoming unauthorized design, engineering, moderation, or release decisions.
• A bounded acknowledgment can preserve trust without promising a feature, fix, outcome, or timeline.

1737. Next lesson

Continue to 4.9 L2 — Write a responsible response loop. Bring forward your categorized triage records, evidence needs, owners, response boundaries, and the privacy disposition of any collected evidence. L2 uses those records to group recurring signals and communicate decisions consistently without reopening unsupported promises.

1738. Knowledge check