Offering solutions too early lets the discussion skip confirming the problem

What it is

If a readout throws feature ideas before the room has accepted the problem, talk turns at once to buildability, brand fit, and whether it makes the release. A premature solution in a research readout skips the step “is this a problem we will own.” Solutions can come later; what is lost first is a shared signature on the problem’s boundary.

Why it happens

People find it easier to speak to a concrete object than to an abstract gap. A wireframe wakes every ready objection from engineering, design, and marketing, and the room’s energy moves from “do we accept that these people fail on this outcome” to “the details of this object.” An unconfirmed problem then lives only as a parasite on that object: kill the object and the problem dies with it; revise the object and the problem is treated as handled. Researchers who use a solution to prove they “delivered” are trading social visibility for the harder-to-see output of problem confirmation.

Studying it

Code readout talk by turn: problem confirmation, solution detail, implementation constraint, evidence challenge. Measure how the density of confirmation turns changes after the first solution slide appears. After the meeting, ask attendees to restate the problem without any feature name; failure means confirmation was skipped. Contrast two sessions on the same material: one with solutions banned for fifteen minutes, one that opens with a solution. Compare later agreement on the problem statement and whether two-week todos still point at the problem rather than at that drawing.

Where it stops holding

Sometimes the audience asked for an option comparison; opening with solutions then answers the brief and is not premature. A problem already confirmed many times need not restage the ritual every readout. Never mentioning direction will convince action-oriented listeners that research is useless; the point is to separate confirmation from direction in time, and to leave a confirmation record. If researchers are asked to “throw in a few ideas,” mark them as uncompared direction drafts and keep them out of the main findings column.

Applying it

• Ban wireframes, feature names, and “we could build…” in the first half; project the problem sentence and ask the room to confirm or amend it out loud.
• Put the confirmation in the first paragraph of the notes; unconfirmed items do not enter solution talk.
• If directions come in the second half, label them “not a chosen solution” and point back at the sentence just confirmed.
• When someone drops a visual early, take it off the main screen and ask “which sentence of the problem is this solving”; if it does not map, fix the sentence first.

Related

• Same group: Q4.17.1 Organize the report around decisions, not around the method’s steps · Q4.17.2 Verbatim quotes and video clips move teams more than statistical summaries · Q4.17.3 Findings without actions and owners are shelved after the meeting
• Adjacent: Q4.15 Identifying opportunities · Q5.07 Misleading prototypes
• Search terms: premature solution · problem confirmation · research readout