Launch new-feature adoption pages for 25 target customers

Start in Productboard and pull the source material for the feature: linked customer requests, feature description, target users, release notes, known limitations, dependencies, screenshots, and internal positioning notes. Use Claude to turn that source material into a short feature truth brief with fixed facts, approved claims, use cases, prerequisites, and claims that need PM review. Separate what the feature definitely does from what the team hopes customers will eventually do with it. Add a QA check with the PM or product owner before any personalized page copy is written.

Create a feature truth brief from these Productboard notes and product materials.

Feature docs:
{{feature_docs}}

Linked customer requests or insights:
{{customer_requests}}

Release notes or launch context:
{{release_context}}

Known limitations or prerequisites:
{{limitations_and_prerequisites}}

Output:
1. Plain-English feature summary
2. Primary users
3. Best-fit use cases
4. Prerequisites or setup needs
5. Approved claims
6. Claims that need PM review
7. Screenshots or assets needed
8. CTA options
9. Risks or boundaries for customer-specific messaging

Do not invent capabilities. Mark uncertain items as review needed.

Build a customer list in Clay or HubSpot with 25 accounts that have a plausible reason to care about the feature. Include company, industry, segment, plan, product usage pattern, CSM owner, renewal date, open opportunities, support themes, linked feature requests, and relevant account notes. Exclude customers with unresolved implementation issues, churn risk that makes the CTA inappropriate, missing ownership, or no clear feature fit. QA check: every selected customer should have at least one evidence-backed reason for inclusion, not just a large ARR number.