Product brief workflow

A product brief is often written before the product thinking is finished. It contains goals, assumptions, constraints, customer problems, and proposed solutions, but those pieces are usually mixed together.

BaseHalf helps by turning the brief into a Map where each piece has a job.

Import the brief

Attach the brief or paste the rough draft into the first request.

Turn this product brief into decisions, open questions,
risks, and follow-up spaces with context.

This asks BaseHalf to preserve the brief as material, not simply summarize it.

Keep the original brief as a source Point. Do not immediately overwrite it with a cleaner version. The rough draft is useful because it shows where the thinking was unclear, where evidence was thin, and which assumptions were already embedded in the language.

Create the first structure

Split the brief into Points by function:

• Goal: what the work is trying to make true.
• User problem: the pain, job, or behavior the product addresses.
• Audience: who the feature is for and who it is not for.
• Decision: choices already made.
• Open question: choices still unresolved.
• Risk: assumptions that could make the plan fail.
• Evidence: research, customer notes, data, or examples.
• Next work: tasks that need an owner or follow-up.

This first structure makes the brief easier to discuss because disagreement can happen at the right level. You can challenge the evidence without rewriting the goal. You can change a decision without losing the user problem.

Polished writing can hide uncertainty. The Map should make uncertainty visible again. If a paragraph contains both a customer claim and a proposed solution, split it. If a roadmap task depends on an assumption, connect it to the assumption instead of letting the dependency stay implicit.

Open decisions as pages

Important decisions need more than a label. Open each Decision Point and add:

• The decision in one sentence.
• The alternatives considered.
• The reason this option wins for now.
• The evidence or context it depends on.
• The condition that would make you revisit it.

This turns a product brief into a memory system. A future teammate can see not only what was decided, but why.

Good Decision Points are short enough to scan and detailed enough to challenge. The goal is not to create a legal record. The goal is to preserve the reasoning that should shape the next draft, design review, or implementation plan.

Keep risks visible

Risk Points should not be hidden at the bottom of a document. Put them where they can affect the work.

For each risk, add a mitigation or a test. If the risk depends on a missing source, reference the open question or source Point. If the risk is accepted, say why.

Risks are useful when they guide behavior. They are not useful when they become a ritual paragraph nobody revisits.

Delete generic risks that do not change the plan. "Users may not adopt this" is usually too broad. "Teams may keep decisions in chat because the first Map takes too much setup" is specific enough to test.

Use the Map during review

When you review the brief, do not read it from top to bottom. Move through the Map:

• Start with the goal.
• Check whether the user problem still supports the goal.
• Review decisions against evidence.
• Promote resolved questions into decisions.
• Convert risks into tests or follow-up tasks.
• Delete or merge Points that no longer carry meaning.

The brief becomes a living workspace. It can keep changing without losing the trail of context that made it valuable.

What to preserve after review

At the end of the review, preserve only the pieces that should affect future work:

• a stable goal
• a decision with its reason
• a risk with a test
• a source that supports a claim
• an open question with an owner or next step
• a task that depends on the current context

Everything else can remain draft material. A useful product brief Map is not a bigger brief. It is a clearer working surface for the parts that still need judgment.