Product Brief 101: Scope, Priority, and Handoff

Session 12 teaches the learner to turn product and design thinking into team direction. The output is a product/design brief and handoff note. It should explain what is being built or reviewed, why it matters, what is in scope, what is not, what must be true, what risks remain, and what conversation needs to happen next.

This is where the learner starts sounding like a Product Owner. She is no longer only noticing screens, generating options, or creating flows. She is organizing work so other people can act with less ambiguity.

The brief should be concise but not thin. A useful brief gives enough context for a designer, developer, stakeholder, or future self to understand the decision and ask better questions.

The learner should leave with vocabulary for brief writing: problem, user need, goal, outcome, success signal, scope, out of scope, non-goal, later candidate, priority, backlog item, dependency, risk, assumption, open question, readiness status, and handoff note.

The key distinction is between documenting everything and documenting what matters. A brief is not a warehouse. It is a direction-setting artifact.

The learner should practice saying: this is in scope because it supports the current outcome; this is out of scope because it expands beyond the reviewed flow; this is a later candidate because it may be useful after we validate the core task.

A brief exists to create shared understanding. It should answer what we are doing, for whom, why, what success means, what is in scope, and what is still uncertain.

Atlassian PRD guidance is useful here because it favors just enough context: goals, assumptions, user stories, design links, questions, and what is not being done.

For a beginner, the target is a one- to two-page product/design brief, not a giant requirements document.

The brief should not start from nothing. It should collect decisions made across the previous sessions.

This matters pedagogically because the learner sees that product work is cumulative. Each artifact feeds the next artifact.

The lecturer should ask the learner to explicitly cite which decision, criterion, or flow note supports each major part of the brief.

The first body section of the brief should explain the problem and desired outcome in plain language. The learner should avoid starting with solution language such as build a comparison page.

The outcome should be user-centered and checkable. A good outcome is not the same as a shipped output.

When evidence is weak, the brief should say so. For example: we believe this will improve trust, but we still need to test whether students can explain recommendation fit.

Scope is one of the most important Product Owner skills. It protects focus and makes tradeoffs explicit.

In scope means the work is part of the current delivery or prototype boundary. Out of scope means it is intentionally excluded for now. Non-goals are things the work is not trying to achieve. Later candidates are valid ideas that should not distract from the current goal.

The learner should avoid vague exclusions such as everything else. A useful out-of-scope note names the excluded areas directly.

Priority explains why this work should happen now. GOV.UK prioritisation guidance emphasizes performance analysis, user research, stakeholder input, clear methods, and team involvement.

The learner can use a lightweight version: user value, business value, risk reduction, effort, urgency, and learning value.

Priority is not permanent. It should change when the product stage, evidence, constraints, or risk changes.

A brief should be convertible into backlog-ready work. This does not mean the learner must create a perfect backlog. It means the work should be understandable enough to discuss and sequence.

The Scrum Guide describes the Product Owner as accountable for creating, ordering, and clearly communicating Product Backlog items, and ensuring the backlog is visible and understood.

A good beginner backlog item includes user value, acceptance criteria, dependencies, and a priority reason.

The brief should carry forward the acceptance criteria from Session 10 and revise them if the flow in Session 11 changed the behavior.

Given/When/Then scenarios make the main behavior concrete. They also help designers and developers spot missing states and assumptions.

Definition of Done belongs in the brief because it tells the team what quality checks apply before the work can be considered complete.

A strong brief does not pretend everything is solved. It names assumptions, risks, open questions, and decisions still needed.

This is especially important for AI-assisted work. AI can produce a polished brief that hides uncertainty. The learner should mark what is known, guessed, unresolved, or dependent on another person.

Risks should be specific enough to act on. Data availability risk, accessibility risk, and unclear ownership risk are more useful than this might be hard.

Handoff should not be treated as file transfer. It is a conversation supported by artifacts.

Figma Dev Mode is a useful concrete reference because it includes ready-for-dev statuses, annotations, version comparison, inspection, and links between designs, tickets, documentation, and code components.

Even if learners are not using Figma, the principle stands: mark readiness, annotate important decisions, link supporting artifacts, and ask clear questions.

AI can help synthesize the previous artifacts into a product brief, but it can also overproduce and invent certainty.

The prompt asks AI to preserve scope, evidence gaps, assumptions, risks, readiness status, and handoff questions. These constraints are important because product briefs should reduce ambiguity, not create polished ambiguity.

The learner should compare AI output against the actual work from Sessions 11 to 13. Any unsupported claim should be removed or marked as an assumption.

Use the course project as the worked example. The brief should gather the selected option, critique criteria, and flow behavior into one direction-setting artifact.

Keep the problem statement grounded in user need. Do not say build comparison because comparison is the solution. Say what user uncertainty the comparison is meant to reduce.

The readiness status should be honest. In the example, ready to prototype and developer review is more responsible than ready to build if data and accessibility questions remain.

The worked example should show how scope turns a big product idea into a manageable next step.

The priority note should explain why the shortlist comparison flow comes before checkout or account work. The reason is that the student must trust and understand recommendations before later conversion steps matter.

The tutor should ask the learner whether each item supports the current outcome. If not, it belongs in later, out of scope, or non-goals.

The handoff note should be short, concrete, and review-oriented. It should say what to review, where to look, what is known, and what decision is needed next.

A weak handoff says: here is the design. A strong handoff says: here is the brief, here is the review focus, here are the risks, and here is the decision I need help making.

This is one of the most practical Product Owner skills in the course because it reduces the back-and-forth caused by unclear intent.

The studio output is a product/design brief and handoff note. It should make the next team conversation easier, not simply prove that the learner can fill a template.

For home study, the learner should rewrite the brief in two versions: a one-paragraph stakeholder summary and a more detailed designer/developer handoff note. This teaches audience awareness.

Close by previewing Session 13. The final session turns the product/design work into a Product Owner case story that can be explained clearly and confidently.