AI Product Brief Generator

Product briefs are where the most expensive ambiguity in software lives. The brief that says "add team accounts" sounds clear to the person who wrote it. The four engineers reading it imagine four different features. The designer imagines a fifth. The result is a planning meeting where everyone realizes they are scoping different things, and a feature that ships in some compromise shape that satisfies nobody specifically. The cost is paid in the rework that follows when the customer who actually needed the feature points out the version that shipped is not what they meant.

A useful brief reverses this. The problem statement is concrete with evidence. The target user is defined by the specific context they are in, not just demographics. The proposed solution names what is in scope and what is not. The success criteria are measurable outcomes the team can verify after launch. The brief is short (one page) and reviewable. With the brief in writing, engineering can scope it; design can sketch flows against it; product can defend the cuts during the inevitable scope conversation. The discipline produces faster builds and less rework. The /helm-brief skill is built to encode the discipline so a brief lands in shape rather than as a Slack message.

Why generalist AI produces vague briefs

Ask Cursor or ChatGPT to draft a brief for a feature idea. You get prose that sounds like a brief, with sections labeled Problem, Solution, and Success Metrics. Read closer and the prose is generic: "users want to manage their accounts more easily," "the solution is to add team functionality," "success is measured by adoption." The brief is a template filled with platitudes. Engineering still cannot estimate it because there is no concrete problem, no specific user, no scoped solution, and no measurable outcome.

The other failure mode is the missing out-of-scope section. A brief that does not name what it is choosing not to do invites scope creep through every review meeting. The team adds suggestions, the brief absorbs them, and the feature that ships is twice the size of the original concept. Out-of-scope is the cheapest cut to make at the brief stage and the most expensive to make later. /helm-brief produces the section because the discipline of declaring it is what bounds the build.

What a useful brief contains

A useful product brief has six sections. Problem statement: a concrete description of the pain the feature addresses, with supporting evidence (customer quotes, support ticket counts, churn signal). Target user: not just demographic, but the specific context they are in (a customer success manager preparing for a quarterly business review, an engineer onboarding to an inherited codebase). Proposed solution: what the feature does in user-visible terms, with the alternatives that were considered and rejected. Success criteria: measurable outcomes (specific metric thresholds, time-bounded), not activities ("users use the feature"). Out-of-scope: explicit list of things this brief is not committing to, with reasoning. Open questions: the parts the team has not resolved yet, surfaced rather than hidden.

The brief is one page. The discipline is in the concreteness, not the length. A long brief with vague sections is worse than a short brief with concrete sections, because the length gives the false sense that the work has been thought through. The right amount of brief is the amount where engineering can read it, scope it with /apex-plan, and start building without a follow-up meeting.

How /helm-brief works

Step one: gather the input

When invoked, /helm-brief asks for the input in concrete terms: what is the pain, what evidence exists, who specifically experiences it, what would success look like a quarter from now. The questions are surfaced together so the team can answer them deliberately. If the team answers vaguely, the skill pushes back: "users would benefit" is not a problem statement; "customer success managers cannot prepare a QBR without exporting data manually, which takes 4 hours per QBR" is.

Step two: structure the brief

The output follows the six-section template. The problem statement leads with evidence. The target user names the specific context. The solution describes user-visible behavior. The success criteria are measurable and time-bounded. The out-of-scope list captures the cuts. The open questions surface what is unresolved so the engineering team can address them in scoping rather than discovering them mid-build.

Step three: pressure-test the brief

The skill runs a quick adversarial pass: would engineering be able to scope this without a follow-up meeting; would design be able to sketch a flow from this; would the success criteria be measurable in three months; would the out-of-scope hold up to scope-creep pressure. Sections that fail the test are flagged for the team to revise before the brief moves to scoping.

Step four: hand off to engineering

Once the brief is reviewed and approved by stakeholders, it becomes the input to engineering scoping. The brief feeds into /apex-plan for the technical scope decisions, into design for the flow work, and into product marketing for the launch positioning. The same brief drives all three; without it, each function reconstructs its own version and the inconsistencies compound.

Tonone's /helm-brief skill produces structured product briefs with problem, target user, solution, success criteria, and explicit out-of-scope sections that engineering can scope without a follow-up meeting.

When to use /helm-brief, and when not to

/helm-brief is the right call when a feature idea needs to become a spec before engineering can scope it accurately, when an existing brief is too vague for engineering to estimate, or when stakeholders have different assumptions and the differences need to be resolved in writing before development starts.

Skip the skill for trivial bug fixes (the brief is the bug report). For roadmap-level work that sequences multiple briefs, /helm-plan is the right call. For arbitrating scope disagreements between product and engineering, /helm-arbiter is calibrated to that work.

A worked example: brief for team accounts

Suppose the feature idea is: add team accounts. Run /helm-brief.

# Brief: Team Accounts (v1)

## Problem
38% of customer support tickets in Q1 mentioned 'sharing access'
or 'team' as a top-three pain. 12 churned customers in Q4 cited
'cannot share with my team' as the primary reason. Today, every
user is billed individually; teams of 5+ are paying 5x for one
workspace they share via password sharing.

## Target user
Team lead in a 3-15 person product or design team using our tool
for active project work. Currently passes a single login among
the team, has no audit trail, and cannot give read-only access
to stakeholders.

## Proposed solution (v1)
- A team can be created from any account.
- Inviting team members via email signs them up to the existing
  workspace and shares all assets.
- Roles: owner, admin, member. Read-only requires v2.
- Billing rolls up to the team owner; per-seat at the existing rate.
- Audit log entries scope per team.

## Success criteria (Q2 launch + 90 days)
- 25% of accounts with multi-seat password sharing migrate to team accounts.
- Net revenue retention from converted accounts +18 percentage points.
- Churn citing 'cannot share' drops by 60% in Q3 surveys.

## Out of scope (v1)
- Read-only role (deferred to v2; surveyed customers can wait).
- SSO at the team level (v2 once 50+ teams paid).
- External team-to-team sharing (separate brief).
- Per-asset permissions (separate brief, possibly v3).

## Open questions
- Migration of existing multi-seat workspaces: opt-in or auto?
- Pricing for the first 90 days: full price or migration discount?
- Trial team accounts: included or separate flow?

One page. Concrete problem with evidence. Specific user. Scoped solution with explicit out-of-scope. Measurable success criteria. Open questions surfaced. Engineering can scope this with /apex-plan without a follow-up meeting; design can sketch the flow; product marketing has the input for launch positioning.

Related skills

/helm-brief produces the brief. Once approved, /apex-plan produces the engineering scope. For roadmap-level prioritization across multiple briefs, /helm-plan is the right call. For arbitrating scope disagreements between product and engineering, /helm-arbiter is calibrated to that work.

Install

/helm-brief ships with the Helm agent in the Tonone for Claude Code package. Install Tonone, invoke /helm-brief from any Claude Code session, and the skill produces structured briefs that engineering can scope without follow-up.

Briefs that produce fast builds are the ones written before development starts. The skill is built so the writing is cheap enough to apply per feature.