A practical FEVAL framework for turning analytics, feedback and journey problems into a CRO backlog that is worth testing.
Quick answer
Build a CRO backlog by recording observed friction, the evidence behind it, the customer value of removing it, the business value of the affected outcome and the cost of learning. Prioritise items with strong evidence and meaningful value, then choose whether each needs a direct fix, usability check, measurement repair or controlled experiment.
Most CRO backlogs are easier to add to than to trust. Ideas arrive from dashboards, stakeholders, competitors and screenshots, but their evidence and expected value are rarely comparable.
FEVAL—friction, evidence, visitor value, organisational value and learning cost—creates a common decision record without pretending prioritisation can be perfectly objective.
Describe observed friction, not the proposed feature
Write the problem as a visitor state that can be investigated.
‘Make the button sticky’ is a treatment. ‘Mobile readers reach product proof but rarely find the next relevant action’ is a diagnosis candidate. The second statement leaves room for navigation, copy, hierarchy or timing to be the cause.
Include the journey, device, audience and affected task. Broad items such as ‘improve homepage conversion’ belong in a programme goal, not a test-ready backlog.
Grade the evidence and the two kinds of value
Confidence should come from observed behaviour and corroborating signals, not stakeholder seniority.
Grade evidence from a single anecdote through repeated qualitative observations to stable quantitative patterns. Record contradictions and data-quality limits.
Visitor value asks whether the change helps someone make progress or avoid harm. Organisational value asks whether that progress connects to an important outcome. High business value with weak visitor value is often pressure disguised as optimisation.
Estimate the cost of learning
Use the cheapest method that can resolve the uncertainty responsibly.
A broken control needs a fix and regression check. Confusing language may need interviews or usability testing. A disputed causal effect may need a controlled experiment. Instrumentation gaps need repair before optimisation claims.
Include design, engineering, QA, sample requirements, operational risk and analysis effort. A small treatment is not automatically cheap if the decision needs months of traffic.
Review the backlog as a portfolio
Balance quick repairs with larger questions that improve the whole journey.
Limit work in progress and reserve capacity for measurement and accessibility defects. Re-score items when new evidence arrives rather than preserving an old ranking for convenience.
Archive rejected ideas with the reason. This prevents the same unsupported suggestion returning every quarter and keeps the backlog a learning system rather than an inbox.
- Friction is specific
- Evidence is graded
- Visitor and business value are separate
- Learning cost matches the method
Further reading
Sources
- Set up events in Google Analytics — Google for Developers
- Test with confidence with the Experiments page — Google Ads Help
- Web Content Accessibility Guidelines 2.2 — W3C
