Defining the Problem for an AI-Powered Productivity Experience

Good to see you again. Last lesson, you chose assist as the primary AI role in Maya’s meeting-follow-up workflow: AI may help prepare an update, but Maya decides what the notes support and what gets sent. Now you’ll turn that design boundary into a focused problem statement—one that identifies the user’s difficulty without prematurely prescribing a feature.

This matters for your AI product-design work because a convincing prototype starts with a problem you can explain and investigate. Plan on about 35–40 minutes, including the short video and reading.

Define the problem before describing the product

A workflow map shows many opportunities for improvement. It does not tell you which one the product should address. In Maya’s case, “make meetings more productive” spans too many people and moments. “Add a chatbot that sends follow-ups” jumps straight to a solution—and gives the system authority that your previous role decision did not justify.

A useful problem statement sits between those extremes. It says who encounters a difficulty, what they need to accomplish, and why the outcome matters. Watch NNgroup’s User Need Statements in Design Thinking for that structure, particularly its distinction between a user need and a proposed interface.

The structure is compact enough to keep beside your workflow map:

The need is usually best expressed as something the person must do, not something the product must contain. Maya does not inherently need a chat panel, a “Generate” button, or even an AI-generated email. She needs to prepare a follow-up that accurately separates settled outcomes from unresolved ones. Several designs might help her do that.

Choose one user and one consequential moment

To make the statement actionable, narrow its scope to a moment where the difficulty becomes visible. Maya’s mapped workflow includes gathering notes, interpreting them, writing, checking, and sending. The most consequential friction is not merely that writing takes time. It is that a loosely worded note can become an apparently firm commitment when incorporated into a polished update.

Recall the illustrative source sentence: “Mina might send a draft Friday if legal approves it.” Maya can include that as a pending possibility, omit it until she confirms the status, or seek clarification. She cannot safely present it as “Mina will send a draft Friday.” Your problem statement should capture the need to make that distinction while preparing the follow-up, and the reason it matters to people receiving it.

NNgroup’s article goes beyond the formula to show how to set scope and critique a draft.

That evidence distinction is important. We have a plausible scenario and a mapped workflow; we do not have interviews showing how often this happens, how Maya currently checks commitments, or whether her team already has an authoritative approval record. A problem statement can be a working hypothesis. It should not disguise that hypothesis as a research finding.

For this course project, choose a child-sized problem: preparing one post-meeting update from loosely written notes. It is narrow enough to guide a prototype and usability test, yet broad enough to leave room for different ways of helping.

Write the statement, then inspect what each phrase does

Here is a working statement for Maya’s experience:

Maya, a coordinator preparing a post-meeting update from scattered notes, needs to distinguish confirmed decisions and commitments from conditional items while assembling her follow-up, so recipients can act on clear next steps without mistaking a possibility for a promise.

The opening identifies a user in a specific situation, rather than “everyone who attends meetings.” The middle names the job and its difficult judgment: distinguishing confirmed from conditional information during assembly. The final clause supplies the insight: other people may rely on this update, so preserving uncertainty matters beyond saving Maya a few minutes.

Compare the choices behind that sentence:

Notice what the stronger statement does not promise. It does not claim that Maya can always know the true status from her notes. If legal approval is recorded elsewhere, she may need to check elsewhere. The statement asks the experience to help her preserve that distinction, not to turn uncertain source material into certainty.

Nor does the statement need the word AI in its central sentence. “AI-powered” describes a possible approach to the user problem; it is not itself a user need. Keeping the problem sentence solution-neutral lets you evaluate the AI approach rather than assume it is warranted.

Pair the problem with a bounded AI opportunity

For an AI product brief, add a short rationale and boundary beside—not inside—the problem statement:

AI opportunity: Loosely written notes may require interpretation and rewriting, so AI could help surface passages that appear conditional and assist Maya in drafting an editable update. Maya verifies claims against the available sources and decides what to send.

This makes the proposed role legible. AI is potentially useful where natural-language variation makes a fixed rule inadequate. It is not being asked to establish that legal approved Mina’s plan or to send an update on Maya’s behalf. If the team already records approval in a dependable structured field, retrieving that field may be a better solution to that part of the problem.

Before treating the statement as settled, inspect it for three kinds of drift:

• Scope drift: Does it quietly expand from preparing a follow-up to solving all meeting coordination?
• Solution drift: Does it require a chatbot, automatic sending, or another feature before alternatives have been considered?
• Evidence drift: Does it state a guessed frequency, cost, or user preference as if it had been observed?

Maya’s statement passes as a working problem definition, not a validated finding. Its specificity makes the next research questions clearer: Where do coordinators find authoritative commitments? Which qualifications do they most often lose when summarizing? What do recipients actually misunderstand? Answers could strengthen, narrow, or overturn the proposed opportunity.

Key takeaways

A focused problem statement names a specific user, a need expressed as a task or decision, and the consequence of meeting that need. For an AI-powered productivity experience, keep that core statement anchored in the human problem; then state separately where AI may add value and where the user retains responsibility. Treat scenario-based claims as hypotheses until research supports them.

For Maya, the focus is not “generate better emails.” It is preparing a follow-up that preserves the difference between confirmed and conditional information. Next lesson, you’ll use that intended outcome to define measurable user-experience success criteria—and check whether the experience helps without creating more confident-sounding mistakes.