AIWorkDex
Product Practice

Review the problem and response behind a feature request

Choose a build, defer, decline, or research response tied to the existing evidence and product boundary.

Preparation
A short evidence and product-boundary review.
Difficulty
Moderate
Task
Decide how to answer a feature request
Back to the Task: Decide how to answer a feature request

Before you start

Get what you need before you start

  • Bring the original request, its source and commercial context, existing research, current product boundary, and decision owner.
  • Separate any contractual commitment from the evidence that the core product should change.

Steps

Work through the method

Use the listed inputs and tools. Check the evidence when you need to verify a step.

  1. Record the request without promoting it

    Create or update the product idea. Preserve the requester’s proposed implementation, source, date, context, and any existing workflow evidence as separate fields.

    Why it matters: The team needs the original request and its interpretation to remain distinguishable.

    Input
    The request, source context, and existing evidence.
    Output
    A product idea with a source-linked request and separate interpretation.
    Tools in this stepJira Product Discovery

    Evidence for this step

  2. Clarify the evidenced workflow problem

    Review existing evidence for the failed workflow, affected user, consequence, frequency, and current workaround. Mark missing evidence for Customer Research rather than filling the gap with assumptions.

    Why it matters: A product response should address an evidenced problem rather than inherit the requested implementation.

    Input
    The linked request and approved research evidence.
    Output
    A problem statement with evidence, gaps, and product relevance.
    Tools in this stepJira Product Discovery

    Evidence for this step

  3. Choose the product response

    Compare the requested implementation with a smaller response, existing capability, operational response, defer, decline, or research path. Record the decision, trade-off, requester impact, and owner.

    Why it matters: The decision must show why the product will change or stay as it is.

    Input
    The problem statement, product boundary, commercial context, and response options.
    Output
    A build, defer, decline, or research decision with consequences.
    Tools in this stepJira Product Discovery

    Evidence for this step

Success checks

Check the result before you finish

  • The request and workflow evidence are separate.
  • The response fits the current product boundary or reopens it explicitly.
  • Missing evidence becomes a research action rather than an invented conclusion.

Failure modes

Watch for these problems

  • Escalate contractual promises to the accountable commercial owner.
  • Do not treat one request as representative demand.
  • Send fresh interviews and observation to Customer Research.

Tools

Choose the tools you need

Sources

Read the sources behind this practice

Check what each source supports and where the advice has limits.