Kith Spark
Sign in

Template

Feature Request Template

A structured form for capturing a single feature request with enough context to triage it.

In short

A reusable feature request template that captures the requester, the problem, the proposed change, affected users, and business impact. Use it to standardize intake so product managers can triage, deduplicate, and prioritize requests without chasing people for missing context across email, calls, and support tickets.

Most feature requests arrive as one vague sentence in a support ticket or a hallway comment. That forces a product manager to reconstruct the problem before any real work can start. A consistent feature request template fixes the intake side so every request carries the context needed to score it.

This template works whether a request comes from a community member, an account manager, or an internal stakeholder. Capture it once, keep the requester attached, and the lineage stays intact through merges and delivery.

Template

FEATURE REQUEST

Title: ____ (short, plain-language summary)
Submitted by: ____ (name / role / account)
Date: ____

PROBLEM
What are you trying to do, and what gets in the way today?
____

CURRENT WORKAROUND
How do you handle this now? What does the workaround cost in time or money?
____

PROPOSED CHANGE
What would the ideal solution do? Describe the behavior, not the implementation.
____

WHO IS AFFECTED
- User type / role: ____
- Rough number of people or accounts: ____
- Frequency (daily / weekly / occasional): ____

BUSINESS IMPACT
- Linked deal value or account tier: ____
- Risk if unsolved (churn, blocked deal, support load): ____

EVIDENCE
Links to tickets, recordings, threads, or related requests:
- ____
- ____

PRIORITY HINT (requester view): low / medium / high
Notes for triage: ____

How to use it

  1. 1Paste the template into your intake form, support macro, or community submission flow.
  2. 2Require the Problem and Who Is Affected fields. Treat the rest as optional but encouraged.
  3. 3Keep the original requester attached so they get lifecycle notifications when status changes.
  4. 4During triage, search for near-duplicates before opening a new record, and merge if one exists.
  5. 5Move the completed record into your prioritization queue with the business impact field filled.

Frequently asked questions

Who should fill out the problem versus the proposed change?

The requester always describes the problem. The proposed change is a hint, not a spec. Product managers refine or replace it once they understand the underlying need, while keeping the original requester credited.

How is this different from a bug report?

A bug report says something broke against its intended behavior. A feature request asks for new or changed behavior. Route them differently so your roadmap reflects demand and your defect queue reflects quality.

Related

Run this live in Kithspark

Templates get you started. Kithspark runs the whole loop, from the first request to the shipped release, with every contributor kept in the loop.

Sign in