Before choosing a framework or sketching screens, describe the situation the product should improve. Who is experiencing the problem? What are they trying to do? What slows them down or creates uncertainty? These questions give the team a clear point of reference.
Next, separate essential needs from ideas that may be useful later. A first release can focus on the smallest complete experience that lets people make progress. This does not mean ignoring quality; it means agreeing on what matters most before adding more scope.
Keep a short record of decisions, assumptions, and open questions. Review it as the work develops. When new requests arrive, compare them with the original goal and decide together whether they belong now or in a later step.
A clear problem statement does not remove every project risk. It gives the team a practical way to discuss trade-offs, review progress, and keep the product focused on its intended users.
Write a short problem brief
Put the user, task, current workaround, and main point of friction in a few sentences. Add what you know, what you still need to learn, and any constraints that could change the solution. This turns a broad request into something a team can investigate.
Agree on a small set of questions to answer before deciding scope. For example: Can the intended user complete the task today? Where does the process break down? What would make a first version useful? The answers help distinguish evidence from assumptions.
- Name the people and task the product should support.
- Record the current process and its most difficult step.
- Agree what evidence will guide the first scope decision.
Add your perspective