Describe the problem with examples
Explain who encounters the problem, when it happens and what the consequences are. A short description of a real workflow is more useful than a request to build a platform with a long list of features. Include the current workaround and what it costs in time, effort or uncertainty. Make clear which parts are known from observation and which are assumptions that the project needs to test.
Name the constraints
Document important timing, budget, data access and integration constraints early. Include the teams whose participation will be needed and any decisions already made. Distinguish fixed requirements from preferences. A deadline tied to an external dependency needs different treatment from an aspirational date. Honest constraints help an engineering team propose an achievable scope instead of discovering halfway through delivery that a critical assumption was never agreed.
Define an observable outcome
Explain how the organization will judge whether the work helped. This could be a shorter workflow, fewer reconciliation errors or a service that meets an agreed operating target. Specify who accepts the result and what evidence they will review. Leave room to choose the implementation after discovery. A brief should make the desired outcome clear without pretending every technical decision can be made before the team investigates the problem.
List the open questions
Uncertainty belongs in the brief. Identify the questions most likely to change the scope or approach, and decide how they will be answered. A focused discovery phase can examine those questions through interviews, system inspection or a small technical experiment. End with a decision point: proceed, narrow the scope, gather more evidence or stop. The best brief gives everyone a shared starting point and a practical way to learn.
Working through a similar question?
Tell us about your context and the decisions in front of you.
Talk to LUNAR LABS