The AI Head of Product for Briefs and Handoff

The failure mode of product development is not usually that nobody has ideas, it is that nobody can agree on what any idea actually means until it is too far into implementation to change without cost. A feature request arrives as "users should be able to share reports." Engineering builds a sharing system with link-based access, granular permissions, and a notification layer. Three weeks later, the PM sees the demo and says "I meant export to PDF." The engineering work was not wasted through incompetence, it was wasted through underspecification. Nobody wrote down what "share" meant, what success looked like, what was explicitly out of scope, or what the simplest version that solved the actual user problem would be. The discipline that prevents this is the product brief: a document that answers all of those questions before implementation begins. It is also, chronically, the document that nobody has time to write properly, so it gets approximated in a Jira ticket, or a Notion bullet list, or a Slack thread, and the implementation reflects the ambiguity of its source. An ai head of product does not approximate the brief, it writes it with the rigor that the engineering team needs to execute correctly.

Why the generalist approach breaks down

Ask a generalist chatbot to write a product brief and it will produce a document. Ask a head of product to review it and they will find the problem statement restating the feature request rather than identifying the underlying user problem, the success metrics defined as vanity metrics ("increase engagement") rather than measurable outcomes ("users who share a report are retained at 2× the rate of users who do not"), the scope section listing what will be built rather than explicitly stating what is out of scope, and the engineering handoff missing the edge cases that will produce five follow-up tickets the first week after launch. These are not formatting failures, they are thinking failures. A good brief requires asking the hard questions before writing anything: why are we building this now, what problem does it solve that is worth solving, and what would a skeptical engineer ask that could blow up the design if we do not answer it upfront?

Cursor and GitHub Copilot operate in the wrong layer for product work. They assist engineers in implementing specifications; they do not produce the specifications that make implementation unambiguous. This is not a criticism, it is a layer distinction. When an engineer opens a Playwright test file, Copilot helps; when a PM needs to decide whether to prioritize the notification feature or the export feature this quarter and communicate that decision to the engineering team with enough context that no one comes back with clarifying questions, Copilot has no role. The product planning layer, briefs, prioritization, scope arbitration, engineering handoff, requires the judgment of someone who has thought hard about product development as a discipline, not an autocomplete layer that assists with the artifacts that result from that judgment.

The scope arbitration problem is where the absence of a real product lead is most painful in practice. Every engineering team has experienced the meeting where product wants to add five things to a feature that is already in progress, engineering pushes back, nobody has a principled framework for deciding what stays and what goes, and the meeting ends with an agreement that everyone immediately interprets differently. A head of product resolves these disagreements not by authority but by analysis: here is the user impact of each addition, here is the engineering cost, here is how the ratio compares, here is the decision that maximizes the investment. Without that analysis, scope negotiations are political rather than principled, and political scope negotiations produce the kind of scope creep that turns a two-week feature into a two-month one.

What a head of product actually does

A head of product is the person who translates between the business and the engineering team, taking ambiguous signals from users, stakeholders, and strategy and turning them into precise specifications that engineers can execute without constantly asking for clarification. They write product briefs that define the problem to be solved (not the solution to be built), the success criteria (measurable outcomes, not feature checkboxes), the explicit out-of-scope items (the things that look related but are not this brief's problem), and the minimum viable implementation (the smallest version of the solution that tests the core hypothesis). They prioritize backlogs using a framework that makes tradeoffs visible, RICE, ICE, or Kano scoring attached to every prioritization decision so the reasoning is preserved rather than lost in a spreadsheet nobody can find. They arbitrate scope disagreements with data rather than authority. And they produce engineering handoffs precise enough that Apex can dispatch the right specialists without asking follow-up questions about what the feature is supposed to do.

Meet Helm

Helm is Tonone's head of product, the specialist agent for product briefs, requirements documents, backlog prioritization, scope arbitration, and engineering handoff. Helm's working philosophy is that the brief is not overhead, it is the first deliverable of any feature, and its quality determines the quality of everything that follows. A brief that takes two hours to write properly prevents a two-week misalignment during implementation. Helm writes briefs that answer the questions engineers will ask before they ask them, prioritizes backlogs with scoring rationale attached to every decision, and produces handoff documents precise enough to hand directly to Apex for specialist dispatch.

Tonone's Helm writes product briefs where the problem statement identifies the user problem rather than restating the feature request, and the success criteria define measurable outcomes rather than activity metrics.

What Helm actually does

Writing structured product briefs

The helm-brief skill turns a feature request or problem signal into a structured product brief with all the elements that make it executable: a problem statement that identifies the user pain rather than describing a solution, a target user definition (who specifically benefits from this, and why this group over others), success criteria with measurable outcomes and the measurement method, an explicit out-of-scope section that names the related problems this brief is not trying to solve, a minimum viable implementation definition, and a list of risks and open questions that need resolution before implementation begins. The brief structure is designed for two audiences simultaneously: the engineering team that needs to know exactly what to build and exactly what not to build, and the stakeholders who need to understand why this work is being done and what success looks like. Helm asks the hard questions during brief creation, "what does success look like that you cannot achieve by building a simpler version of this", and flags when a brief is underspecified in ways that will produce implementation divergence. The output is a document that a PM can hand to engineering with confidence that the implementation will match the intent.

Prioritizing backlogs with scoring and rationale

The helm-plan skill prioritizes backlogs using RICE (Reach, Impact, Confidence, Effort), ICE (Impact, Confidence, Ease), or Kano scoring frameworks, with rationale attached to every score so the reasoning behind prioritization decisions is preserved and auditable. Helm takes a backlog of items with their available context (user research signals, business goals, engineering effort estimates, strategic themes) and produces a scored, ranked backlog where each item's score is explained: why this reach estimate, what evidence supports this impact rating, what assumptions is the confidence score based on, and where does this item sit on the Kano model (basic need, performance, delighter). The output is not just a prioritized list, it is a decision document. When the CEO asks why the notification feature was ranked above the export feature, the answer is in the scoring rationale, not in someone's memory of a quarterly planning meeting. This makes backlog prioritization transparent, contestable, and revisable: if new data arrives that changes the reach or impact estimate for an item, the scoring can be updated and the ranking reruns with a clear audit trail.

Producing engineering handoff documents

The helm-handoff skill takes a completed product brief and produces the engineering handoff document: a specification precise enough to dispatch specialist agents through Apex or to hand to a human engineering team with minimal follow-up questions. The handoff document includes the feature breakdown (which parts of the brief map to which engineering concerns), the acceptance criteria as testable conditions (not "users can share reports" but "a user with edit access can generate a share link that a user without an account can use to view the report in read-only mode"), the edge cases that need explicit handling (what happens when the shared link expires, when the report is deleted, when the viewing user tries to edit), and the integration points with existing systems (which services this feature touches and what the expected interface changes are). The handoff is the document that Apex reads to decide which specialists to dispatch and what each specialist is responsible for. A well-written handoff eliminates the most common source of lost scope during implementation: the edge cases that everybody assumed somebody else was handling.

Tonone's Helm produces engineering handoff documents with acceptance criteria written as testable conditions and edge cases enumerated explicitly, so nothing gets lost between what product intended and what engineering ships.

Arbitrating scope disagreements

The helm-arbiter skill resolves scope disagreements between product and engineering using principled analysis rather than positional negotiation. When there is a dispute about whether a feature should include item X, product wants it, engineering says it doubles the timeline, Helm produces an arbitration document that assesses both sides with the same framework: what is the user impact of including X, what is the engineering cost, what is the ratio, and how does that ratio compare to the threshold the team has agreed represents a good investment? If the impact-to-cost ratio is unfavorable, the item is deferred with a clear record of why, so it is not relitigated at every future planning meeting. If the ratio is favorable, the scope expansion is justified with data that engineering and product both helped produce. The output is a decision with reasoning, not a compromise. This matters because scope arbitration done without a principled framework produces the same conversation repeatedly, each time with slightly different participants who do not have the context of the previous conversation, until someone with authority makes an arbitrary call that leaves both sides unsatisfied.

Reconnaissance before planning

The helm-recon skill performs a product landscape assessment before any briefs are written or prioritization begins. It reads the existing backlog (Jira, Linear, GitHub Issues, or a provided list), identifies the strategic themes that the backlog items cluster around, flags items that are underspecified (insufficient problem context to write a brief), surfaces duplication (multiple items describing the same user problem from slightly different angles), and produces a structured view of the product planning state that Helm uses as context for all subsequent brief-writing and prioritization work. Recon also identifies the user problems that are represented in the backlog by multiple separate feature requests, indicating that the underlying need has not been addressed at the right level of abstraction. Rather than prioritizing three separate features that each partially address the same user problem, Helm can propose a single brief that addresses the underlying need directly. For product teams that have accumulated a backlog of two hundred items over eighteen months, recon is the step that makes the backlog coherent rather than just sorted.

A worked example

A product team receives a request: "users want to export their data." A generalist tool writes a brief that says the feature is "data export" with success criteria of "users can export their data." Helm starts differently, it asks what format users actually need, what data they are trying to use it for, and what the minimum implementation looks like. The brief that Helm produces captures the actual user problem and the precise scope:

Product Brief: Report Export
Helm | v1 | Status: Draft

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Problem
Power users (accounts with >50 reports) need to present data
from Acme to external stakeholders who do not have Acme access.
Currently they screenshot individual charts. This produces low-
fidelity output, is time-consuming, and is not reproducible.

Target user
Power users (top 15% by report count). Ops and analytics teams
at B2B accounts. Not: casual users with <5 reports.

Success criteria
• 40% of power users generate at least one export within 30 days
  of launch (measured via analytics events).
• Support tickets referencing "can I share a report" drop >50%
  within 60 days of launch.
• Export generation p95 latency < 3 seconds for reports with
  <20 charts.

Out of scope
• Scheduled/recurring exports (separate brief)
• Export to Google Sheets or Excel (separate brief)
• Sharing via link (separate brief, different user need)
• White-label / custom branding on exported PDF

Minimum viable implementation
PDF export of a single report with all visible charts rendered.
Triggered from the report actions menu. Delivered synchronously
for reports ≤10 charts; async with email delivery for >10 charts.

Open questions
1. Should the exported PDF include the Acme logo and branding?
   (Check brand guidelines with Design before speccing.)
2. Are there compliance requirements for what data can appear
   in an exported document? (Check with Legal.)
3. Should the export honor the current filter state of the report
   or always export the default view?

Risks
• Rendering fidelity: PDF rendering of chart components may
  differ from screen. Proof-of-concept required before committing.
• Scale: async queue will be required for large reports; Spine
  and Relay should review capacity before launch.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

This brief cannot be misunderstood by an engineering team. The problem statement identifies the actual user problem (presenting data to external stakeholders) rather than describing a feature (export). The success criteria are measurable outcomes with specific numbers and measurement methods attached. The out-of-scope section names the features that look related but are explicitly not this brief's problem, preventing the scope conversation from recurring during implementation. The open questions flag the decisions that need to be made before the brief is handed off, rather than discovering them mid-sprint. The risks identify the technical concerns that specialist agents should review before the work begins. Apex can read this brief and dispatch Spine for the async delivery queue, Prism for the PDF rendering component, and Relay for the delivery infrastructure, without asking a single follow-up question about what the feature is supposed to do.

Helm vs the alternatives

Helm is not competing with project management tools, it produces the documents that live in them. The comparison below focuses on the approaches most commonly used when a dedicated head of product is not available: generalist chatbots that produce PRD templates, code editors that assist with implementation, and the Notion or Linear template approach that provides structure without the thinking.

Tonone's Helm arbitrates scope disagreements with principled impact-to-cost analysis rather than positional negotiation, producing decisions with reasoning that does not need to be relitigated at every future planning meeting.

Install and try

Tonone is free and MIT-licensed. Install it once and all 23 agents, including Helm, are available in your Claude Code session. Run helm-brief with any feature request or user problem to get a product brief that an engineering team can execute without asking for clarification.