Start with a page you own
Choose an existing evaluation page: a product explanation, integration guide, migration page or technical FAQ. Define the evaluator, the supported product facts and the question the page should help someone answer.
Product / proposed workflow
One page. One brief.
One learning loop.
The workflow we’re building connects authorized evaluation questions to a clearer product explanation, with a person choosing the change and recording what happens next.
From input to outcome
Six steps, with a person in control.
Bring questions you have permission to use
The proposed first source is an import of redacted first-party text. Record collection authority, dates and original references. Remove personal information before import. Keep the source context attached so a question can be understood, not just counted.
Inspect the recurring uncertainty
Group related evaluation questions while separating duplicates and routine bug reports. Inspect the supporting excerpts, their dates and the reason a question is relevant. A thin evidence base should produce an insufficient-evidence state.
Choose one improvement
Review up to three candidate improvements, then one full weekly brief. The brief should connect a question to evidence, supported product facts, a proposed page change, an owner and a measurable learning goal.
Approve, then publish yourself
A person accepts or declines the brief. The page owner makes the change through their existing publishing process. The page stays in your existing publishing process, with the final decision in your hands.
Record what happened
Enter aggregate results with a numerator, denominator, date window and known confounders. Keep a completion reference and compare with the baseline. Unknown, negative and inconclusive are valid outcomes.
The weekly deliverable
A brief you can interrogate.
PROPOSED BRIEF STRUCTURE
A decision, with its working attached
Why this question?
Recurring uncertainty, linked excerpts, source dates and relevance to your product. Include what the evidence cannot tell you.
What should change?
An existing page, verified product facts, the proposed explanation and a bounded scope.
Who will do it?
An accountable owner, effort estimate, approval decision and completion reference.
What will we learn?
A baseline, success metric, observation window and room for a negative or inconclusive result.
A fully worked example
A Jira migration question becomes a page brief.
SYNTHETIC WORKED BRIEF · NOT CUSTOMER DATA OR A BEACON OUTPUT
Explain what a Jira Cloud move to Orbit preserves
This completed illustration uses fictional question records and real published guide facts, checked 3 November 2026. Beacon is in development. No customer research, product execution or measured improvement is represented.
1. Buyer question and authorized evidence
“Can we bring Jira comments and attachments, and will our workflows come with them?” The example team owns its product page and has permission to use redacted first-party evaluation notes. These three records were written for this illustration; they are not conversations with real buyers:
- F-01 · fictional evaluation note · 20 October 2026: “Will comments keep their dates?”
- F-02 · fictional demo note · 23 October 2026: “Does the import copy our workflow?”
- F-03 · fictional follow-up · 27 October 2026: “Do attachment files arrive with the JSON?”
In an actual brief, each excerpt must link to a permission-checked source reference, with names, emails and sensitive project details removed before import. Here F-01–F-03 are the entire fictional evidence set. They suggest a clarity question, not independent demand, purchase intent or market size.
2. Verified facts and their boundaries
- Orbit Jira import guide: matching and exclusions: comments and work logs carry Jira timestamps; statuses, types and people are matched. Workflows, screens, schemes, boards and filters are excluded. Imported history is activity, not Orbit report or JQL history.
- Orbit Jira import guide: attachments: files are uploaded after the work-item import, with upload checks and limits.
- Published exporter README:
--attachments DIRdownloads files; a separate uploader sends them to Orbit after import. The source account must be able to browse the Jira project; an Orbit project administrator starts the import.
The guide and README describe private preview and final testing. They do not establish compatibility with every Jira configuration or a publicly available trial.
3. Concrete change on an owned page
Target: the example team’s Orbit product page, /products/orbit/, beside its migration description. The team owns this page; this brief does not edit it.
Before (illustrative copy)
“Bring your Jira data.”
After (proposed copy)
“Move Jira Cloud work items with comments, work logs and imported activity. Existing statuses and people are matched; workflows, screens, schemes, boards and filters are not copied. Attachment files upload separately. The import remains in final testing during private preview. Review the Jira-to-Orbit guide before planning a move.”
Link “Jira-to-Orbit guide” directly to the verified guide above. Keep the preview caveat beside the claim, including in any search description. No claim of complete migration fidelity or availability.
4. Priority, uncertainty, owner and effort
Priority: medium, because the current short explanation can hide an exclusion that affects a migration decision. Confidence: high in the cited documented boundaries, low in demand and impact: three fictional notes cannot measure either. Proposed owner: the example PMM, with the migration engineer verifying the wording. Rough effort: half a working day for copy, review and a manual page edit; this is a planning estimate, not completed work.
5. Human decision and manual execution
Decision: awaiting human approval. The page owner must recheck the guide, approve the exact wording and decide whether to publish. A person edits the page and records its commit or URL and actual publication date. There is no automatic publishing and no completion reference yet. If the facts change or permission is withdrawn, revise or withhold the brief.
6. Aggregate measurement plan and honest outcome
Baseline: not collected. After approval, record 28 complete days before the actual publication date: aggregate eligible product-page visits and visits following its migration-guide link. Primary metric: guide-link visits divided by eligible product-page visits, using the same aggregate counting method for both windows. Observe the next 28 complete days after publication; record counts as well as the rate. These static sites currently run no analytics; this is a proposed customer-entered aggregate measure, not installed tracking or permission to collect visitor data.
Confounders: campaigns, traffic/source mix, other page edits, seasonality, duplicate visits, measurement changes and small samples. Agree a minimum useful sample and decision threshold with the owner before publishing; no numeric baseline or uplift is invented here. A higher click rate alone would not establish causation or more successful migrations.
Outcome: unmeasured. Nothing has been approved or published from this example, so there is no positive result to report. Missing aggregates, inadequate sample, changed counting or overlapping edits should yield “inconclusive,” with the reason preserved.
The boundary
No automatic publishing.
The owner remains responsible for the final claim and the page change.
A useful brief should fit the way your team already works: an owner who can review it, an existing page they can edit, and a clear learning goal. Beacon is designed to support that decision without taking over publication.
See what is being built →