Feature Request Template: Capture the Problem Before the Proposed Solution
By SayCraft Team · 2026-08-24 · 3 min read
A useful feature request template starts with who has the problem, when it occurs, what outcome is blocked, the current workaround, and evidence of frequency or impact. It records the proposed solution separately so the team can compare alternatives. It also names affected users, dependencies, non-goals, decision owner, and what evidence would justify discovery or rejection.
Community signal: Product teams describe requests arriving through support, sales, chat, and email with solutions already attached. A shared intake format exposes the underlying problem without promising that the loudest request enters the roadmap.
Capture the problem before the feature
A useful feature request template starts with who has the problem, when it occurs, what outcome is blocked, the current workaround, and evidence of frequency or impact. It records the proposed solution separately so the team can compare alternatives. It also names affected users, dependencies, non-goals, decision owner, and what evidence would justify discovery or rejection.
Copyable request-intake form
Collect enough context to compare requests without making the form a promise. Keep the requester's proposal visible but separate from the underlying problem and desired outcome.
Review requests in groups by underlying problem, user segment, and workflow point before ranking individual solution ideas. A repeated proposed feature may hide several different needs, while differently worded requests may share one root problem. Preserve that grouping decision and the evidence used so a later roadmap conversation can be audited.
- Requester, user segment, product area, workflow point, and problem statement
- Frequency, affected volume, workaround, cost or risk, and evidence links
- Desired outcome, proposed solution, alternatives, non-goals, and dependencies
- Privacy, permission, accessibility, data, security-review, and migration questions
- Triage state, owner, rationale, duplicate link, next evidence, and response date
Bulk-invitation worked example
A support lead requests bulk invitation management. The form records that workspace owners repeat the same action for 40 people, the current workaround and error risk, the desired completion outcome, affected account tier, evidence links, permission questions, and why a bulk editor is one option rather than the requirement itself.
Separate evidence from urgency
Collect the requester's role, affected segment, workflow step, frequency, current workaround, observable impact, and evidence before asking for a preferred solution. Preserve exact examples or feedback with appropriate privacy controls. A vote count can show interest, but it does not explain severity, strategic fit, effort, or whether several requests describe the same underlying problem.
Triage should explain why the next state follows. High frequency may justify discovery but not a particular solution. One strategic customer may reveal a severe workflow problem but not broad demand. A low-effort idea may still conflict with product direction. Record these dimensions separately instead of compressing them into one arbitrary score.
- Atlassian: product requirements template
- Reddit: feature-request intake questions
Keep solution and scope questions open
Separate problem, outcome, and proposal fields. Let the requester describe an idea, but keep alternative solutions and discovery questions open. Add product area, dependencies, permissions, data, accessibility, security-review, non-goals, and affected existing behavior. Do not promise delivery merely by accepting the form or assigning it a backlog identifier.
Record a transparent triage decision
Record triage as a dated decision: needs evidence, discovery, duplicate, planned, declined, or another existing state already used by the team. Include the owner, rationale, follow-up, and linked evidence. SayCraft can keep the intake discussion near a prototype, while roadmap priority, feasibility, and release commitments stay with responsible product and engineering owners.
Limits of feature-request intake
A preview is not evidence of production security, compliance, or launch readiness.
- The problem can be understood without the proposed feature
- User segment and workflow point are named
- Impact evidence is distinguished from urgency claims
- Triage outcome and rationale are preserved
Sources and discussion
- Atlassian: product requirements template (publisher)
- Reddit: feature-request intake questions (community)
Community posts describe individual experiences and questions; they are not treated as universal proof.
Related resources
Build the next step with SayCraft
Capture the problem and evidence before discussing screens or implementation, then record the triage decision. SayCraft can keep the request conversation and preview aligned; the product owner remains responsible for prioritization.