How to run product-design discovery without turning interviews into a pitch

Tess is a fictional 31-year-old product designer on a four-week discovery in San Francisco, California. Tess has eight interviews, has already invited three more interviewees, a stakeholder who wants a dashboard, and an engineer asking what to build next sprint. Notes are in a doc. Clips are in a drive. The problem is still a pile of pain.

Interview notes, a slide of quotes, and a sprint board all want to be the brief.

Two interviews contradict the dashboard. Those notes are in a different doc than the one being prettied for Friday.

In You.one's Superboard view, Tess can give “Leave discovery with either one chosen problem and a next-sprint ask, or an explicit decision to pause build for three more interviews, while contradictory evidence stays visible” a Board of its own. That Board connects source evidence, unresolved questions, decisions, and accountable judgment; opening “Choose next sprint’s problem” creates a Room for its evidence, discussion, state, and decision.

The mission is specific: Leave discovery with either one chosen problem and a next-sprint ask, or an explicit decision to pause build for three more interviews, while contradictory evidence stays visible.

The consequential choice is not something a board or an AI should quietly make: Whether the next sprint tests a scheduling pain, a handoff pain, or pauses build to run three more interviews.

You.one can keep the work, evidence, live dependency, and “Choose next sprint’s problem” decision visible through its Superboard view. The Owner boundary stays explicit: Tess chooses the problem, talks to stakeholders and engineers, and owns what gets designed.

The Discovery month Board gives this mission one durable operating picture. Tess can use familiar language instead of translating the situation into project-management jargon. Its five Lists separate the kinds of attention this situation actually requires.

Its Cards deliberately distinguish actions, evidence, a live dependency, and decisions. A Waiting List is useful here only because a named request or outside condition is already in motion. That separation makes the current choice, evidence, and next move easier to scan.

These Card titles come directly from Tess's situation: “Choose next sprint’s problem” is the live choice, “Interview 6 contradicts the dashboard” holds evidence, and “Awaiting replies from three invited interviewees” names something genuinely in motion outside Tess's control. The point is recognition, not a perfect taxonomy.

Opening the Card gives the visible item durable depth. Stage can hold Problem-choice brief: Place contradictory interviews, the dashboard request, and the three problem paths on one page. Chat keeps the request and response beside that artifact instead of in a detached thread. Pulse can show “Open decision: Tess will choose scheduling pain, handoff pain, or no build while she runs three more interviews.” Activity can preserve this attributed receipt: “Ava compared the options in Card Chat using the Problem-choice brief and this Card Room's visible notes and left “Choose next sprint’s problem” with Tess.”

A useful Card Chat request would be: “Using only the context visible in this Card Room, compare scheduling pain, handoff pain, and pausing to interview more. Do not write a spec, contact interviewees, chase the three invited replies, or choose for me.” When live AI is configured, current Ava can respond to an explicit Card mention using supported Room context and can make limited reversible changes inside this Card Room after an explicit request. She uses only supported Room context; she cannot summarize the Board, watch other Lists, or act outside this Card Room. She does not gain authority over the decision merely because the context is organized.

Tess's call remains explicit: Tess chooses the problem, talks to stakeholders and engineers, and owns what gets designed.

These requests use the visible supported context inside the “Choose next sprint’s problem” Card Room. They do not imply that current Ava automatically surveys the whole Board or follows up on her own; Tess must provide the relevant facts and check the result.

Current Ava can reply in this Room to an explicit Card mention using supported Room context. She cannot summarize the Board, make the choice, represent Tess, watch other Lists, or act outside this Card Room.

Tess owns synthesis, stakeholder conversations, and design judgment. Ava does not interview users, write specs, or pick the problem.

A defensible next-sprint posture: test scheduling pain, test handoff pain, or pause build for three more interviews. The dashboard remains a request and the contradicting interview stays visible.

• Request idea: using only the context visible in this Card Room, compare scheduling pain, handoff pain, and pausing to interview more. Do not write a spec, contact interviewees, chase the three invited replies, or choose for me.
• Request idea: use only the Problem-choice brief and notes the Owner has placed in this Card Room to separate facts, assumptions, and unanswered questions
• Request idea: name which visible Room note could most change the comparison; do not watch other Lists or follow up autonomously

A quotes slide plus a sprint board is enough when the problem is already agreed.

It starts to break when contradictory interviews and a requested dashboard both want to be the brief.

The Discovery month Board earns its place only when the familiar tool—a quotes slide plus a sprint board—can no longer keep the reason, Problem-choice brief, conversation, current state, decision, and history connected.

Tess should rename every List or Card that feels artificial. This recipe succeeds when “Choose next sprint’s problem” becomes easier to decide and fewer open loops depend on memory—not when the Board looks tidy.

Later, Ava may help this Board notice when a sprint ask has no chosen problem Card, still leaving every product call with Tess.

A future unified You.one experience could carry relevant context from “Choose next sprint’s problem” across guidance and the Superboard view. Broad proactive coordination, cross-surface personalized memory, realtime shared editing, and general external execution are not available today. Any future action would still require the applicable capability, connection, grant, and human authority.

• Tess is fictional and is not a customer, testimonial, research participant, or disguised real person.
• This is not a user-research finding or a product-market claim.
• It does not show Ava interviewing users or writing a specification.
• It is not a measured product result.