Prioritise what to build

Put the evidence behind the decision.

When several problems compete for the same team, make the case for each one visible. Compare what you know, investigate what you don’t, and agree which work deserves attention next.

Three problems. Different evidence.

Give each case
the same scrutiny.

Illustrative team review. The comparison is a discussion aid, not an automated priority score.

01 / Case

Checkout clarity

What supports it?
Completion fell from 64% to 52% [1]. A customer describes seeing the total late in the flow [2].
What’s missing?
Whether price visibility explains the decline, how widespread the problem is, and what else changed.
A possible next move
Investigate the checkout experience.
Inspect sample sources

[1] Illustrative PostHog funnel: 320/500 sessions completed last week; 260/500 this week, using the same definition. [2] Illustrative Intercom excerpt: “I got to the payment step before I could see the full price.” One customer account does not establish causation.

02 / Case

Dashboard customisation

What supports it?
A customer asks to rearrange widgets to put their daily work first [3].
What’s missing?
The underlying task, how many customers share it, and whether a simpler change would help.
A possible next move
Gather context before scoping a feature.
Inspect sample sources

[3] Illustrative support excerpt: “Can I move the widgets I use every morning to the top?” This request alone does not establish reach, urgency, or the best solution.

03 / Case

Payment reliability

What supports it?
A PaymentTimeout issue reports eight affected users [4].
What’s missing?
The failure mode, customer outcome, and whether it relates to the checkout decline.
A possible next move
Ask engineering to assess the failure.
Inspect sample sources

[4] Illustrative Sentry issue: PaymentTimeout in the checkout service, eight users affected. The issue count is not a count of all abandoned checkouts, and these sources have not been linked to the same sessions.

Bring judgment to the evidence

A stronger signal
is part of the decision.

Evidence helps you examine the problem. Your team still weighs strategic fit, urgency, effort, and capacity before committing to a solution.

A single-source issue can deserve immediate attention. More mentions do not automatically make a request more important.

Check the consequence.

What is the customer unable to do? How serious is the problem, and what do the records actually establish about its reach?

Examine the explanation.

Does the evidence support a cause, or only suggest where to look? Use a focused investigation when the next decision depends on that answer.

Make constraints explicit.

Bring the current objective, available capacity, and engineering assessment into the discussion. Agree what would change the priority.

Record the reasoning

Choose a next move.
Keep the decision reviewable.

Illustrative team decision · Not a generated ranking

Assess payment reliability first.

The team asks engineering to assess the timeout because payment outcomes may be unclear for affected customers [4]. It also keeps a focused checkout investigation open [1, 2]. Dashboard discovery continues before feature scope is agreed [3].

Assumptions to verify
The timeout may affect successful payment or customer confidence. Its impact and relationship to the wider checkout decline still need verification.
What could change the order?
Engineering finds a low-impact failure, stronger evidence points to another cause, or a strategic commitment changes the team’s constraints.
What happens next?
Review the technical assessment and customer evidence, then prepare a scoped proposal. Agree implementation only when the team has enough context.
Return to the sample sources

Give the team a case to challenge.

A cited brief brings the problem, proposed change, and open questions together. Use it to refine the scope and explain the evidence behind the work.

Explore briefs and handoff

The product behind the workflow

From scattered signals
to a shared case.

Make your next priority
easier to explain.

Start with the evidence behind a problem your team is considering.

Investigate a product change Turn feedback into a delivery brief