How to brief a product studio before anyone designs a screen

A useful product brief should explain the change the product must create, the decision the work must unlock and the realities it must respect. It should not attempt to design the product in prose.

That distinction matters. A long feature list can make a project look defined while leaving the important questions unanswered: who needs the product, what they are trying to do, why the current way fails and what evidence would justify further investment.

The strongest starting brief gives a product studio enough context to make good decisions without pretending that every solution is already known.

Begin with the situation, not the software

Describe what is happening before the product exists.

Name the person or organisation experiencing the problem, the job they are trying to complete and the current alternative. Include the consequence of leaving the situation unchanged. A useful description might explain that a small operations team reconciles requests across email and spreadsheets, causing missed handovers and making it difficult to see who owns the next action.

That is more useful than asking for “a dashboard with notifications”. The first version exposes the operating problem. The second prescribes an interface before the team understands what the workflow needs.

A clear situation statement should answer:

• Who is affected?
• What are they trying to accomplish?
• How do they handle it today?
• Where does the current approach break?
• Why is solving it important now?

Define the user change

Write one sentence describing what should become easier, safer, faster or newly possible for the primary user.

For example: “An operations manager should be able to see every open request, its owner and its next action without assembling a report.”

This is the product promise at its most useful. It is specific enough to guide design, but open enough for the team to find the right interaction. It also creates a standard against which features can be challenged. If a proposed feature does not help produce the change, it probably does not belong in the first scope.

Ambitious visions often serve several audiences. Choose one primary user and record the others as secondary. A brief that treats customers, administrators, partners and executives as equally important usually produces an unfocused first product.

Name the commercial decision

Every early product engagement should lead to a decision, not simply a collection of screens.

The decision might be whether to fund a production build, invite a buyer into a pilot, replace a manual process or test a venture with a reachable customer group. State that decision in the brief.

Then ask what the product must make visible for the decision to be credible. A prototype may need to show that target users understand and can complete the core journey. A pilot-ready product may also need an owner, support process, data agreement and agreed measures.

This prevents technical activity from becoming the goal. The work has a stage, and the stage has a question it must answer.

Separate evidence from assumptions

A brief should distinguish what the team knows from what it currently believes.

Evidence may include observed workflows, customer interviews, support records, existing spending, signed requirements or repeated requests from a defined buyer group. Assumptions are the claims that still need to be tested: that users will change behaviour, that an organisation can provide the required data or that a buyer has authority and budget.

Keep both lists short. The purpose is not to make the idea look certain. It is to show where uncertainty lives so strategy, design and engineering can address it deliberately.

Avoid presenting a polished prototype, a live URL or positive informal feedback as proof of demand. Those can be useful milestones, but they answer different questions.

Describe the operating reality

Digital products sit inside real organisations. The brief should show enough of that environment to prevent the customer-facing experience from being designed in isolation.

Record:

• Who owns the workflow after launch.
• Who reviews exceptions or incorrect information.
• What data the product needs and who controls it.
• Which permissions, approvals or integrations may be required.
• What happens when the system, a partner or a human operator is unavailable.
• Which part of the process must remain human.

These details are especially important when the product touches money, personal information, safety or institutional decisions. A smooth interface cannot compensate for an undefined owner or a dependency the product cannot reliably control.

State constraints and non-goals

Constraints help the team make sound trade-offs. Non-goals protect the first engagement from absorbing every future ambition.

Useful constraints include a fixed decision date, an existing technology environment, a required approval process, a limited operating team or a defined test group. A constraint should be real. “It must use AI” is usually a solution preference unless the product problem genuinely depends on it.

Non-goals should be equally direct. The first version may not replace every spreadsheet, serve every customer segment, automate exception handling or support a national rollout. Saying this early does not make the vision smaller. It creates a credible first move.

Define success as evidence

End the brief by naming what the team expects to learn and what would count as sufficient evidence for the next decision.

Useful measures are tied to the product promise: whether the intended user can complete the core task, whether the workflow reduces a specific handover, whether a buyer agrees to a scoped next step or whether the operating team can support the experience reliably.

Avoid measures that only report activity, such as the number of screens designed or features shipped. Delivery matters, but it does not show whether the product created the intended change.

The brief should also allow for an honest negative result. If the test contradicts the core assumption, the team should be able to narrow, redirect or stop the work without pretending that more features are the answer.

A one-page product brief

Before speaking to a product studio, write one page with these headings:

• Situation: the current workflow, problem and consequence.
• Primary user: the specific person or organisation whose behaviour matters first.
• Intended change: what should become easier, safer, faster or newly possible.
• Commercial decision: what this stage of work must help you decide.
• Evidence and assumptions: what is known and what remains unproven.
• Operating reality: owners, dependencies, permissions and failure states.
• Constraints and non-goals: the boundaries of the first engagement.
• Success evidence: what would justify the next investment or decision.

Bring supporting material if it exists, but do not hide the core argument inside a large document. The brief should be understandable without a presentation.

Leave room for product judgment

A good brief creates shared clarity while leaving the solution open to discovery. It gives strategy a commercial question, design a meaningful user change and engineering an operating reality to build for.

That is the right starting point for Dial8. We build things that widen possibility by turning ambitious visions into working digital products through strategy, design, engineering and commercial validation. The brief is where the vision first becomes precise enough to move.