The impact effort matrix: prioritize feature requests in four boxes

An impact effort matrix is a 2×2 grid that sorts ideas by two questions: how much will this help, and how much work is it? Ideas with high impact for little effort land in quick wins, the box you start with. The same grid goes by effort impact matrix, impact effort grid and value effort matrix.

This guide covers the four quadrants, how to score both axes so a team agrees on them, ten feature requests from one app sorted into the grid, and a template that sorts your own list. Plant Diary is a made-up app for the examples, the same one as in the MoSCoW, RICE and Kano guides.

The short answer

Score every idea for impact and effort on scales the whole team shares, draw one line across each axis, and you get four boxes. Do the quick wins (high impact, low effort) first, plan the big bets (high impact, high effort), fit the fill-ins (low impact, low effort) in when there is time, and drop the money pits (low impact, high effort).

The four quadrants

Quick wins: high impact, low effort

The reason the matrix exists. These ideas help many people and cost little, so they go first. If this box is crowded, check the effort estimates before you celebrate. Crowded quick wins are the most common sign of an estimate problem, covered further down.

Big bets: high impact, high effort

Also called major projects. Worth doing, but they need a plan, a slot on the roadmap and usually a smaller first version. Most of what makes a product better over a year lives in this box.

Fill-ins: low impact, low effort

Small things that help a few people. They suit a quiet afternoon or a new teammate's first week. They become a problem when they fill a whole release because each one felt cheap.

Money pits: low impact, high effort

Also called thankless tasks. They take a lot and change little. Say no, or keep them on a list until something makes them cheaper or more important.

Lean Six Sigma teams use the same grid under the name PICK chart, after its four boxes: Implement for the easy, high payoff ideas, Challenge for the hard ones, Possible for easy ideas with little payoff, and Kill for the rest. Same quadrants, blunter names.

Where the impact effort matrix comes from

The matrix has no single inventor. Two-by-two grids for decisions are old. In an article on prioritization matrices, Nielsen Norman Group notes that "many time-management matrices are based on the Eisenhower Method", which sorts tasks by urgent and important. Quality teams adopted the impact and effort version to choose between improvement ideas, and product teams to choose between feature requests. The axes change names, value or benefit instead of impact, ease or cost instead of effort, but the grid stays the same.

How to score impact and effort the same way

A matrix is only as good as its two numbers. When everyone scores with their own idea of "high", the grid shows opinions rather than ideas. Five rules keep it honest:

1. Give impact a unit. A number anyone can look up beats a feeling. Plant Diary uses votes from the last quarter on its feedback board. Without votes, use a 1 to 5 scale with one written example for each step.
2. Count effort in days for the whole team. Design, code, review, testing and release, not just the coding. A feature that takes two days to code and three to test is a five-day feature.
3. Draw the lines before you place anything. Plant Diary's lines sit at 30 votes and one working week. Lines drawn afterwards tend to land where they flatter someone's favorite idea.
4. Score alone, then compare. Everyone writes down their numbers before the discussion starts. Gaps of two times or more are where the conversation is worth having.
5. Compare effort with something you shipped. "About as big as last month's export feature" is easier to agree on than a number out of thin air.

Nielsen Norman Group recommends the same silent first round for its prioritization workshops:

"This step will not only speed up the process and provide structure for plotting, but it will also prevent the loudest person in the room from dominating the outcome of the exercise."

A worked example: ten feature requests

Plant Diary's board has ten open requests with votes from the last quarter, and the developer estimated each one in days of work. The lines sit at 30 votes and five days.

• Quick wins: the home screen widget, fertilizer reminders and dark mode. Ten days of work for three of the five most-voted requests. They ship first.
• Big bets: watering intervals, sync across devices and plant ID by photo. Watering intervals misses quick wins by a single day, and splitting it fixes that: a first version for the ten most common houseplants takes three days, custom intervals come later.
• Fill-ins: the plant photo diary, CSV export and German translation. Few votes, little work. Batch them into a release that is quiet anyway.
• Money pit: the Apple Watch app. Fifteen days for 22 votes. It stays on the board so people can keep voting, but it doesn't get built this quarter.

Two things the grid can't show. Sync is a big bet here, but in the MoSCoW example it is a Must, because it was promised for version 2.0. And the bug that sent reminders twice is not on the grid at all. A broken basic doesn't compete with requests for a slot, it gets fixed. The Kano model explains why.

Impact effort matrix template

Type your own requests into the table, with impact and effort in whatever units your team agreed on, and set the two lines. The four boxes update as you type, each sorted by impact per unit of effort. Nothing you enter leaves your browser.

Where the impact effort matrix misleads

The most common failure has a name. People underestimate how long their own work will take, and they keep doing it even when they know their past estimates were too low. Psychologists call it the planning fallacy. In a 1994 study, students estimated how long their senior thesis would take:

"When asked for their best estimate, respondents predicted, on average, that they would finish in 33.9 days, but they actually took 55.5 days"

Even the estimates they made assuming everything would go as badly as possible came in short on average. On an impact effort matrix the effect is predictable: effort estimates drift low, and the quick wins box fills up with ideas that turn out not to be quick.

• Effort drifts low. Compare each estimate with how long similar work took last time, not with how long it should take. If quick wins keep missing their dates, raise every estimate by the same factor.
• Impact drifts high. Everyone believes in their own idea. A number from outside the room, like votes, keeps that in check.
• The lines are arbitrary. An idea one day over a line is no different from one a day under it. Look at the position, not just the box.
• Quick wins crowd out big bets. Ten small wins can fill a quarter while the one feature that matters waits. Reserve part of every release for a big bet.
• Promises and dependencies are invisible. The grid doesn't know that plant ID needs a camera screen first, or that sync was announced. Check commitments with MoSCoW prioritization before you settle the order.

Votes give the impact axis a number

Impact is where most matrices go wrong, because it is usually a guess made in a meeting. Votes are counted the same way for every request, they come from the people who would use the feature, and nobody can argue them up by talking louder. They measure how many people want something rather than how much it helps each of them, so add RICE prioritization or a Kano survey when that difference matters. The guide to feature prioritization puts all five frameworks side by side.

A feature request board collects the votes as a side effect: users post ideas and vote on each other's. WishKit does that for websites and SaaS products, and inside iOS apps with a native SDK.

Frequently asked questions