AccelerateLink

Explore AccelerateLink

CONNECT. ACCELERATE. SCALE.
Product decisions

Turn a feature request into a testable product problem

AI-assisted editorial field note · Educational planning framework

What should I ask before accepting a feature request?

Ask what the person was trying to do, what happened instead and how they currently work around the issue. A feature request is one proposed solution, not a complete explanation of the need. Understanding the context lets you compare simpler changes, documentation or a different workflow before committing to maintenance-heavy product behaviour.

Put it into practice

  1. Capture a recent example

    Ask for the last event that made the request necessary. Record the user's role and task so the request is not detached from its context.

  2. Find the cost of the gap

    Identify rework, waiting, mistakes or an abandoned outcome. Separate actual incidents from hypothetical problems the person has not yet encountered.

  3. List alternative responses

    Consider a small interface change, clearer defaults or an existing capability before adding a new feature. Compare the trade-offs for other users.

  4. Test the smallest response

    Use a sketch, prototype or bounded change. Ask the requester to complete the original task and check whether the underlying problem disappears.

A worked example

Illustrative scenario — not a customer case study

A customer asks for a bulk-edit button. Investigation shows they repeat the same category choice for every new record. A better default may remove the repeated action with less complexity. The team tests the default and watches for cases where it would silently misclassify data.

Make the next decision

Accept the solution that solves the defined problem with acceptable costs and failure behaviour. Record unresolved exceptions rather than describing the change as universally applicable.

A mistake to avoid

A workaround that helps one power user may confuse beginners. Test across the intended roles before applying a global default.

Should every request receive a prototype?

No. First assess relevance, consequence and repetition. A prototype is useful when the problem matters but the proposed response remains uncertain.

Take the next step

Open the related resource →

Check the broader business context with the free six-question assessment. Use your own evidence to choose the next action.

Have a correction? Email admin@acceleratelink.com with this page's URL and the detail.

Continue this workflow