The Impact/Effort Matrix, Built from Votes and Revenue

The impact/effort matrix is a two-by-two grid. Impact goes up one side, effort along the bottom, and every request lands in one of four boxes. It takes ten minutes, it works on a whiteboard, and everyone in the room understands it. That simplicity is also its weakness: if "impact" is whatever the most senior person says it is, the grid just draws their opinion in four colours.

This guide shows how to build the impact axis from two numbers you can measure, votes and the revenue behind each request, using Trailmate, a fictional hiking app. It is one of several approaches covered in the overview of prioritisation frameworks.

The short version

• Four boxes: quick wins, big bets, fill-ins and money pits.
• Score impact from votes (how many people) and MRR (how much of the business), each on a 1 to 5 scale, then average them.
• Get effort from the people who will build it, in weeks.
• Spend most of the discussion on the requests that sit near a line. They are where the matrix earns its keep.

The four boxes

You will see other names for the same boxes: major projects, thankless tasks, time sinks. The names matter less than agreeing where the lines are before you start placing requests.

Building the impact axis

Impact has two parts that are easy to measure and one that is not. The measurable parts are reach, meaning how many users want it, and value, meaning how much of your revenue sits behind those users. The hard part is how much the feature changes their experience, and that is where judgement comes back in, later.

Score each measurable part from 1 to 5 using bands you set once and keep:

The impact score is the average of the two. Anything at 2.5 or above counts as high impact. Trailmate's engineers estimate effort in weeks, and anything over six weeks counts as high effort.

Trailmate on the grid

Read it top to bottom and the plan writes itself: build the difficulty filter now, put the elevation profile next to it, give offline maps a proper project, slot sharing a hike in when there is a gap, and leave trail notes alone. That matches what a full RICE score says about the same requests, in a fraction of the time.

Where judgement comes in

Requests on the line

The elevation profile sits exactly on 2.5. This is where the team should spend its time. Votes and revenue say "maybe". Now add what the numbers cannot see. The trail data already includes elevation, so the build is low risk. Its voters pay more than average, about $22 a month each against an average of $17.70 across the list. It goes in quick wins. If the data had been missing, the effort would double and it would become a big bet.

The weighting question

Averaging votes and revenue equally is a choice. Trailmate's already-built Dark map style is a useful test: 212 votes (score 5) and $480 of MRR (score 1), so an impact of 3.0 with a one-week build. Equal weights call it a quick win. Weight revenue at two thirds and votes at one third, and it falls to 2.3, a fill-in.

Neither is wrong. Equal weights suit a team that is still growing its user base and wants free users to become fans. Revenue-heavy weights suit a team whose priority is keeping paying customers. Decide which team you are before you plot anything, and write the weights on the whiteboard.

Big bets need scope, not a yes

Offline maps is the highest-impact request on the board, and it is in the box that sinks small teams. Do not approve it as one item. Break it down: offline maps for saved trails, then whole regions, then scheduled downloads. Each slice gets its own place on the grid. The MoSCoW guide shows how to decide which slice goes into a release.

Running it in a meeting

1. Bring the list with votes and MRR already scored. Do not score in the room.
2. Ask engineering for effort in weeks, with a range if they are unsure. Use the top of the range.
3. Place everything. Agree the lines before you argue about any one request.
4. Discuss the requests near a line, and nothing else.
5. Record the outcome as a status on each request, so users and teammates can see it.

Common mistakes

• Everything is a quick win. If more than a third of your list lands there, your effort estimates are too optimistic.
• Moving the lines. Redrawing the grid so a favourite request becomes a quick win defeats the exercise.
• Ignoring money pits forever. Revisit them each quarter. A cheaper approach or a jump in votes can move them.
• Treating effort as fixed. Effort is the one axis you can change, by changing the scope.

How FeedbackKit fits in

The impact axis above needs a vote count and an MRR figure for every request, and FeedbackKit records both. Users vote and comment on requests inside your app through the Swift SDK, and a new request starts with its submitter's vote. On every plan, your app passes each user's MRR through the SDK, and the native admin apps for iPhone, iPad and Mac can sort requests by the total MRR of the users behind them. Merge duplicates and each voter is counted once, so your vote bands stay honest.

Once a request has a box, its status says what happens next: Approved for a quick win, In Progress while you build it, TestFlight when a beta is ready, Completed when it is out. Voting stops at Completed and Rejected. On Pro and up, an approved request can go straight to an issue tracker such as GitHub or Linear (see integrations and pricing).

Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:

A grid built on numbers your users gave you is much harder to argue with than one built on opinion. To get those numbers for your own app, start free.