Before the Roadmap: Write a One-Page Product Problem Brief

A feature idea can arrive with a name, a sketch, and an enthusiastic explanation before anyone has described the problem clearly. That is a useful moment to pause. Before deciding where the idea belongs on the roadmap, write down what someone is trying to accomplish and what is making it difficult.

A one-page problem brief gives the team a shared starting point. It also makes assumptions easier to challenge. The goal is a clear enough description that another person can ask a better question about it.

Start with a person in a situation

“Users need better organization” leaves a lot open. Which users? What are they organizing? When does the difficulty appear?

Try a more specific statement. In this fictional example, a team coordinator is preparing the weekly project update. They need to identify overdue work and confirm who owns the next action. Today, that information is spread across messages and several documents.

Now the team has a person, a task, and a situation to investigate. The example still contains assumptions, but they are visible enough to check.

Describe the obstacle before choosing the interface

A dashboard might help the coordinator. So might a clearer ownership field, a shared task view, or a change to the update process. Choosing the interface too early can narrow the conversation before you understand the obstacle.

Ask the coordinator to walk through the last update they prepared. Where did they look first? What information was missing? What did they do when two sources disagreed? What happened if an owner could not be found?

Write down the sequence in plain language. Separate what you observed from what you inferred. “The coordinator opened three documents” is an observation. “A dashboard would solve this” is a proposal that still needs examination.

Make the consequence concrete

An obstacle matters because of what it prevents or makes harder. In the scheduling example, the consequence could be time spent checking information, delayed decisions, or an update that still lacks a clear owner.

Do not invent a number to make the problem sound important. If you do not know how often it happens or how much time it takes, record that as an open question. The next research step can be designed to answer it.

This distinction helps a team avoid treating confidence of presentation as strength of evidence.

State the change you want to create

A useful outcome for the coordinator might be: identify overdue work and its next owner from a consistent source before preparing the update.

That statement gives the team something to assess. It also leaves room for more than one solution. During a test, you can observe whether the coordinator completes the task, where they hesitate, and whether the information is sufficient to act.

The metric should follow from the task. Define who is included, what counts as completion, and the period you will observe. Those details turn a broad aspiration into a usable learning question.

End with what could change your mind

The brief should make uncertainty visible. Perhaps the information is already available and people do not know where to find it. Perhaps ownership changes too often for the current process. Perhaps only one team experiences the problem.

Each possibility could lead to a different next step. Write the most important assumption beside the evidence you would need to support or challenge it.

Copy this structure

• Person and situation: Who is trying to do what, and when?
• Obstacle: Where does progress become difficult?
• Evidence: What have you observed or heard directly?
• Consequence: What happens because of the obstacle?
• Desired change: What should become easier or possible?
• Open assumption: What could make the current explanation wrong?
• Next learning step: What will you observe before expanding the solution?

Keep the brief short enough to discuss in one sitting. If the team cannot agree on the problem, that is useful information. You have found the next decision to work through before adding more scope.

Which part of a product problem is hardest for your team to describe clearly? Bring that question to the conversation on Instagram at @calixleighreign. You can explore my product work through calix.co and my portfolio.