Write a product problem statement that guides design

Name a person, obstacle, and consequence

A problem statement gives a team a shared account of the obstacle it is trying to address. Make the library easier to use is too broad to guide a design decision. Add a person, a situation, a specific obstacle, and its consequence. Keep the proposed solution out until the problem can stand on its own.

Distinguish the problem from an organizational ambition and from a symptom. Increasing engagement is an ambition; repeated searches may be a symptom; uncertainty about whether a resource can be borrowed may be the actual obstacle. Write what is known and flag any interpretation that still requires investigation rather than presenting it as established fact. Make the tradeoff visible on paper before choosing the most polished option. One version may expose more information while another saves space; neither advantage automatically resolves the task. Label the decision point, the evidence available there, and the cost of a mistaken choice. Prefer the arrangement that lets a person understand and correct that choice without reconstructing the entire journey from memory.

Frame uncertainty about borrowing a sample

Draft a statement for a student finding a paper sample before a workshop. Specify that the catalog identifies the sample but does not show borrowing conditions, leaving the student unsure whether to travel to collect it. Then list at least two solution directions, such as clearer catalog content and an availability process. Give the artifact to a colleague with the task description but without the design rationale. Ask them to describe what they expect before making a choice. Compare that expectation with the result the prototype supplies. If they differ, locate the cue that created the expectation. Changing a label, grouping, or sequence may resolve the mismatch more effectively than adding a longer explanation after the action.

Remove prescribed solutions

If the statement includes build a mobile app, remove the solution and ask what the app would help someone accomplish. If it describes everyone, narrow the situation without inventing a demographic profile. If no consequence follows the obstacle, investigate why the problem matters before turning it into a project. Reproduce the problem from its actual starting state instead of inspecting only the final screen. Trace which information disappeared, which expectation was set, and which action became unavailable. Fix the earliest misleading cue that you can identify. A patch at the end of the sequence may quiet one symptom while leaving the same confusion in every other route through the task.

Keep the statement specific and open

Review the statement by asking whether several different solutions could address it and whether the team could recognize improvement. Link it to evidence when evidence exists, and keep assumptions visibly labeled. A strong statement is specific enough to guide tradeoffs while remaining open enough that a better solution can emerge from research.