Prioritising with impact × effort × confidence

0:00 Prioritising: impact × effort × confidence

Every stakeholder has a favourite issue. The founder wants the site faster. The developer wants to refactor the filter component. The marketing manager wants rich results back. Without a shared model, prioritisation becomes whoever argues loudest. In this lecture you'll score Kiran Home's root causes with a transparent impact, effort and confidence model, stress-test the ranking, sequence the work into sprints, and learn how to communicate expected outcomes without promising traffic numbers.

0:31 The model

The model scores each root cause from one to five on three dimensions. Impact: how much organic performance or business value is at stake, considering revenue templates, severity and markets. Effort, scored inverted, so five means trivial and one means a major project. And confidence: how sure you are that fixing it produces the benefit. High when evidence is direct, like a wrong Google-selected canonical. Lower when it's inferred. The priority score is impact times inverted effort times confidence, with a maximum of a hundred and twenty-five.

1:09 The scale

Here's how the scale reads. A five for impact blocks indexing of key revenue templates. A three affects discovery or rich results on important templates. A one is cosmetic. A five for inverted effort is a configuration change under a day; a three is a sprint of work; a one is a multi-sprint rebuild. A five for confidence is direct evidence plus documented Google behaviour; a three is strong but indirect evidence; a one is speculative.

1:42 Kiran Home scores (illustrative)

Scoring Kiran Home, illustratively. RC one, cross-market canonicals: impact five, effort four, confidence five, score one hundred. It's one template change that directly explains the non-UK losses. RC eight, the CDN bot rules: three, five, four, sixty, because it's one rule change. RC three, redirects: sixty-four. RC two, facets: forty-eight. RC seven, release checks: forty-eight. RC four, pagination, and RC six, structured data: thirty-six each. And RC five, performance: eighteen, because it's a third-party widget replacement with an uncertain ranking effect.

2:17 The model supports decisions

Notice RC five. It scores lowest on SEO grounds, but performance often affects conversion rate, so the business may still schedule it early. Say that explicitly and let the business weigh it. The model is a decision aid, not a decision machine. Its job is to make trade-offs visible, so that if someone later asks why something wasn't done first, the reasoning is written down.

2:45 Hands-on: score + stress-test

Hands-on. The lesson text has a pandas script that scores and ranks the root causes, then stress-tests the result. For every root cause and every dimension, it nudges the score up or down by one point and checks whether the top three changes. If a one-point change flips the top of the list, you say so in the report. It's a simple way to show that your ranking is robust, or to be honest that it's a close call.

3:19 Sequence, don't just rank

Scores give an order. Dependencies and risk shape the plan. Quick wins with high impact go first: RC one, RC eight and the top slice of RC three, meaning legacy URLs with backlinks or historic traffic. Sequence dependent changes: for facets, stop linking and add robots rules only after confirming none are URLs you want indexed, and if some are indexed and should go, noindex first, then block. Bundle work by component: RC four and RC two both touch the category and filter component, so ship them together. And fix process early with RC seven.

4:00 Communicate outcomes

Communicating uncertainty. Don't forecast precise traffic gains. Frame expected outcomes as observable leading indicators. For RC one: non-UK product URLs move from alternate page with proper canonical tag to indexed, with Google-selected canonicals matching yours. For RC two: the share of Googlebot requests on facet URLs falls in the logs. For RC three: legacy four-oh-fours with links drop to near zero. For RC eight: Bingbot and AI search bots get two hundreds on product URLs. Leading indicators are what you can commit to.

4:36 Example 2: Dubai SaaS (illustrative)

Worked example one: that's Kiran Home. Worked example two, a different client, illustrative. A Dubai SaaS company has three root causes: a slow, client-rendered pricing page, orphaned integration pages, and missing Organization markup. Scoring puts the orphaned pages first, a quick win with direct evidence of lost impressions. But the team schedules the pricing page in parallel, because it also affects paid-traffic conversion. The model made the trade-off explicit rather than hiding it.

5:08 Common mistakes

Common mistakes. Prioritising by crawler severity labels instead of business impact. Ignoring effort, so the roadmap starts with a six-month rebuild. Promising specific traffic recovery numbers. And treating the score as the final decision instead of a starting point for discussion.

5:26 Watch me do it: the prioritisation session

Watch me do it. I'll run the prioritisation session with Kiran Home's team. Step one: before the meeting, I pre-score each root cause and write one sentence of evidence per score. Step two: in the meeting, I share the table and ask the senior developer to challenge the effort scores only. He says RC four, pagination, is bigger than I thought, because the category component is shared with search. We drop its inverted effort from three to two. Step three: I ask the founder to challenge impact. She points out that UK revenue is growing, so RC one matters slightly less for the UK, but it's still the biggest issue for the UAE and Pakistan. The score stays. Step four: I run the stress-test script with the updated numbers. The top three, RC one, RC three and RC eight, don't change with any one-point nudge. I say that out loud; it builds confidence. Step five: we discuss RC five. It scores low on SEO, but the founder cares about conversion, so she chooses to start the reviews-widget replacement in sprint three anyway. I record that as a business decision. Step six: we drag causes into three sprints and agree one leading indicator per cause.

6:55 A roadmap gone wrong

Let me show you what a roadmap looks like when prioritisation goes wrong, so you can spot it. A draft plan starts with sprint one: rebuild the category component and replace the reviews widget. Both are big, both are important, and neither delivers anything for six weeks. Meanwhile, the one-day canonical fix waits in sprint three. The model catches this immediately: the canonical fix scores one hundred, the rebuild scores in the thirties. Resequence it. Canonicals, the CDN bot rule and the top redirect tier go first, because they're fast, high-confidence and high-impact. The big component work follows, bundled. Quick visible wins also buy you the trust you'll need for the bigger asks later.

7:45 Scoring confidence honestly

How do you score confidence honestly? Ask what kind of evidence you have. Direct evidence plus documented behaviour, like URL Inspection showing Google chose the UK canonical, plus Google's documentation on canonicals, earns a five. Strong but indirect evidence, like logs showing uncrawled deep products plus a missing pagination path, earns a three or four. Speculation, like we think faster pages will rank better, earns a one or two. Being honest here protects your credibility. When you tell a founder a fix is high-confidence, it should be, and when it isn't, you should say so before they ask.

8:28 Recap and try this now

Recap. Score impact, inverted effort and confidence from one to five, multiply, rank, and stress-test. Then sequence by dependencies and components, fix process early, and communicate leading indicators instead of traffic promises. Try this now. Score your own top five root causes with the model, run the stress test, and draft a three-sprint roadmap with one leading indicator per item.