How should Product and Engineering validate a product problem before committing to a Feature?

A requested Feature can arrive with a persuasive business case while the underlying user difficulty remains untested. Committing the team too early spends scarce Engineering capacity and makes alternative responses harder to consider. Product and Engineering need enough evidence for the next decision, rather than certainty about every detail.

Frame the problem and its consequence

Product should identify the affected people, the task they are trying to complete, the observed friction and the intended outcome. A stakeholder request is useful context, but is still a hypothesis about a user need. Engineering can identify system constraints, dependencies and telemetry gaps early. The team should state which parts are observed and which are inferred. GOV.UK guidance on user needs recommends research with actual or likely users and treating unsupported suggestions as assumptions.

Use existing evidence and direct research

Start with support contacts, journey data, previous research and operational records. Each source has limits: an analytics drop-off shows where people leave, but not necessarily why. Observe or interview relevant users, including people who struggle with the current journey. Compare accounts across user groups and look for counterexamples. Product leads the interpretation of customer value; Engineering checks whether technical behaviour could explain the signal. Existing evidence may already be sufficient to reject a proposed Feature.

Test the assumption that matters most

List the assumptions on which the proposed investment depends. For example: users experience the problem frequently, a changed workflow would help, and the current system can support it responsibly. Prioritise those that are both consequential and weakly supported. A prototype or small service change can test behaviour; a conversation may clarify motivation. Choose a method that answers the specific question, as GOV.UK research planning guidance recommends. Do not treat positive reactions to a prototype as proof of sustained use.

Decide what the evidence permits

Agree in advance what result would support, revise or stop the Feature. Record who was studied, the evidence, limitations and unresolved technical constraints. Product decides whether the problem merits investment; Engineering advises on feasibility, risk and the cost of learning. A small experiment can be the right next step when evidence is promising but thin. AI may organise source-linked notes, yet its summaries must be checked against original observations and must not invent demand.

Example

Hypothetically, a subscription team receives a request for a new cancellation screen. Product reviews support contacts and observes customers trying to pause subscriptions. Engineering checks the current state transitions and finds that pause requests are handled manually. The team tests a simple pause route before committing to the proposed cancellation Feature, and records which user need each option addresses.

FAQs

• How much evidence is enough?

  Enough to make the next investment decision proportionate to its cost and reversibility; high consequence work needs stronger evidence.

• Can customer requests count as validation?

  They are evidence of a stated need, but the team should examine the underlying task, frequency and alternative explanations.

• What if research contradicts analytics?

  Check population, timing and instrumentation, then investigate the discrepancy before claiming a conclusion.