Ridiculously Opinionated Guide on How to Prioritize Features after the MVP is Done

While building the MVP we always leave some 2-year backlog that we wanna start implementing after the MVP is done.

When we were building Scrimmage we had about 8 MVP features and then there were 20 post-MVP features that were waiting

You can’t just build them in random order. Originally we were prioritizing them solely based on our opinion and dependencies between features but with time we have made a much more structured approach toward it – Impact / Complexity Coordinates.

Impact / Complexity Coordinates

The idea is to put 2 variables in the graph with Y being Impact and X being Complexity. Right above the chart, you have to specify how you measure the impact. This will depend on your primary KPI. It can be “Make product sellable”, “Make customers feel like we are moving fast”, “Make product stable and prepare for growth”, “Experiment with new product angles to discover potential business models” etc.

No alt text provided for this image

The complexity is how much time and effort would it take to implement this. Don’t try to precisely estimate the feature, rather follow your gut on how hard will it be for your team to make it.

The brainstorming section is a collection of points that are yet to be put inside of coordinates. Of course, putting something on coordinates requires collaboration and negotiation between the business and the dev team. Before that, we just collect all our points in the brainstorming section.

No alt text provided for this image

Monthly Evaluation Meeting

The evaluation process takes place once every one / two months for us. Usually, it is 2 hours long meeting where the whole dev team and business team come together and collaborate on building the roadmap for the next 1 month. Most of the time some additional requirements or features are getting discovered in the middle of the roadmap, so a planned 1 month can become 2 months, which is ok, just count on that.

While evaluating the capacity of the roadmap think over who will be responsible for features. Don’t let the situation happen where all tasks are mostly backend-oriented and frontend developers have nothing to do this month.

The meeting starts with us evaluating brainstorming points and putting them on coordinates. It goes very slowly, one by one. Sometimes we are diving deep into the implementation of specific features and details over how they would work. It is the longest part of a meeting which usually takes 1.5 hours.

After evaluation, it becomes very clear which features are going to be implemented next and the rest 30 minutes is usually enough to finalize the roadmap. The best features are ones from the top right corner because they have high impact and low complexity. So every feature there is a no-brainer. Everything else requires discussions.

The first mental exercise is to give executives from every team select 1 feature which they feel most strongly about. The chart is not always telling a complete story and as a dev leader, I may predict that some features or some refactoring that have a low business impact may help us to make the product much better and improve performance. The same can be with the business team, which talked to a lot of customers and features which may sound too complex to be selected actually the most requested feature and they will select it.

If your team got stuck or has chosen too many features as for the 1-month sprint, start selecting 3-5 features and asking “Out of these N features, which one do you think we should build first?”. If you are getting different opinions don’t just ask for a vote, make opposite sides debate, and then based on the debate they will come to a consensus, and if no, everyone else will have enough context to vote for a better product move.

Mark selected features with a distinctive color, one more time read them over, thank everyone for such a lovely meeting, and start the planning phase.

No alt text provided for this image

Monthly Planning Meeting

During the planning phase, you have to give more precise estimates, and assign and put selected features inside sprints. It is usually organized with a dev team and that is where you can start building dependencies between features. First, build features that can impact other features. Any kind of refactoring or redesign has to go first. Big features which could potentially change the whole product direction have to go second. Then goes rest.

While doing estimation some tasks may sound too big and complex to even give an estimate. In this case, try to break them down into smaller sub-tasks. If you have a junior in your team, immediately think over the implementation of tasks and add even more sub-tasks that will guide them with the implementation pathway and technologies.

When sprints are formed, tasks are described and estimates are finalized, make a screenshot of your board and prepare a message that summarizes the goals of the next 1 month for the whole team and for every person separately.


During the execution, come back to the coordinates and mark completed features with a distinctive color so that the business team has a quick reference over what is done and what is in progress. Also, during the execution, come back to the brainstorming section and add new points once they arise.

Make the execution phase as long as you need it, but before organizing the next planning don’t forget to write a standup over what was achieved during the past execution phase.

A day before the next monthly planning ask all team members to revisit the coordinates and finalize the features they wanna evaluate.

What to do if I have no features to build

Do competitor research

Find out your competitors and share links to them near the coordinates. Now every member of a team can go there and select tasks that they think are the best to build next.

Hire a product manager

If there are not enough features in the backlog it just means that no one thinks about the product. You need a person who will evaluate the product every day and come up with different new solutions and experiments.

Ask your customers

If you don’t have plans for your product, your customers have it. Just launch a questionary and talk to your customers directly about what they want you to build next.

Ask your team

If you succeeded in generating trust in your team, they will happily share their ideas with you. if they are too shy about presenting those ideas publicly – organize one on one meetings where they will pass their vision to you.

User Avatar

Yev Rachkovan

I have been coding for the last 5 years, which might be described as "a proven track record" or "delivering consistent results" on LinkedIn. I am currently on a mission to enslave humanity with the power of gambling. My skills include writing, re-writing, tweeting, startup founding, mixing cocktails, full-stack engineering, and watching the same isekai over and over again. Proficiency ranges from excellent to absolutely awful.

Leave a Comment