Most website backlogs are full of good ideas. The problem is that every idea is pretending to be equally urgent.

A development backlog can grow faster than a team can deliver it.

Customer requests sit beside internal preferences. Bugs sit beside experiments. An app vendor suggests one improvement, an agency suggests another and the loudest stakeholder arrives with something that apparently needed to be live yesterday.

Almost every item may be reasonable. That does not make every item equally valuable—or equally ready to build.

Without a shared way to compare them, priority becomes a mixture of seniority, recency and persistence. The team moves quickly from ticket to ticket while the most useful opportunity can remain untouched because it never became the loudest one.

Starting quickly and moving quickly are not the same thing.

A rushed task often pauses halfway through because the customer problem was never defined, the evidence is weak, a dependency appears late or the apparently small change crosses more of the store than expected.

The visible development time may be short. The hidden time is spent reopening decisions, waiting for approvals, revising scope, repairing side effects and explaining why the result did not create the improvement everybody assumed it would.

I.C.E. introduces a deliberate pause before that expensive part. It asks three plain questions: how much useful Impact could this create, how strong is our Confidence in that belief, and how Easy is it to deliver well with the store and resources we actually have?

I.C.E. turns observations into work you can choose, deliver and learn from.

1. Audit the store and the evidence I review customer journeys, performance, themes, apps, analytics, support themes, search behaviour and team workarounds to find where value or time is being lost.
2. Define each opportunity clearly A vague idea becomes a specific customer or operational problem, a proposed response and an outcome we would expect to observe.
3. Score Impact We estimate the scale and importance of the improvement: who it affects, how often, where it sits in the journey and what useful change it could create.
4. Score Confidence Evidence, precedent and the quality of our diagnosis determine whether the expected impact is well supported or still mostly an assumption.
5. Score Ease Development effort, content, approvals, dependencies, risk and testing are considered so a deceptively simple idea does not receive an unrealistic score.
6. Execute, measure and repeat The strongest opportunities move into properly scoped delivery. What happens after release improves the evidence and scoring of the next round.

The person scoring the opportunity should understand what it takes to build it.

I’m Luke Michael, a UK eCommerce Consultant & Developer with over twenty years spent in-house, agency-side and freelance across commercial thinking, customer experience and delivery.

That combination matters. Impact cannot be judged from code alone, while Ease cannot be judged accurately by somebody who never has to implement the recommendation inside a real theme, app stack or integration.

I work across Shopify, Shopify Plus, BigCommerce and WooCommerce. I can run the audit and scoring exercise independently, work through it with your existing team, or continue into the development so the original reasoning survives delivery.

You may be wondering…

The wrong task costs more than its estimate.

It consumes development capacity, attention, testing and release risk. It delays the opportunity that should have gone first. If the result is inconclusive, it also leaves the team with less confidence in the next improvement.

Prioritisation does not remove uncertainty. It makes the uncertainty explicit enough to spend in proportion to it.

You do not need a polished brief. Send me the useful version of the problem, the store URL and anything the team has already tried.

I will look at the website before we speak and tell you plainly whether I am the right person to help.