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

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.

Execution

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.

要查看或添加评论,请登录

Yev Rachkovan的更多文章

  • Best 59 Resources for Technical Startup Founders and CTOs

    Best 59 Resources for Technical Startup Founders and CTOs

    Youtube channels for consistent watching Programming: **https://www.youtube.

    7 条评论
  • Freelance is the future of IT in Ukraine

    Freelance is the future of IT in Ukraine

    Becoming an International freelancer is a huge career boost for IT specialists, but also a hard one. In freelance you…

  • How Brands Can Retire Their Customers

    How Brands Can Retire Their Customers

    Imagine a life without purpose. Is it even possible to have such a life? What is the purpose? Do we really need it? I…

  • Why Ukraine has so LESS Startups? Part 3. Language

    Why Ukraine has so LESS Startups? Part 3. Language

    Why Ukraine has so LESS Startups? Part 3. Language About 50% of Ukrainians know English, but 5% know it decent enough…

    2 条评论
  • Ridiculously Opinionated Guide on Choosing Technologies for Startup MVP

    Ridiculously Opinionated Guide on Choosing Technologies for Startup MVP

    I have been responsible for building about 6 serious startup MVPs from scratch and about 5 pet projects. Some of them…

    1 条评论
  • Why Ukraine has so LESS Startups? Part 2. Market

    Why Ukraine has so LESS Startups? Part 2. Market

    Even though Ukraine has the most talented developers in the world we have the same amount of startups as South Korea…

  • 5 lessons I learned from 2 pivots on Scrimmage

    5 lessons I learned from 2 pivots on Scrimmage

    We are building a “Bloomberg for sports bettors” When you are doing an investment, your every money move is measured…

    1 条评论
  • Guide to Bubble League

    Guide to Bubble League

    How to communicate in Bubble League The time to make a turn is very limited so effective communication is the key. The…

    1 条评论
  • Gamers' Guide to Capitalism

    Gamers' Guide to Capitalism

    I had the pleasure of being a gamer in the past and a capitalist in the present. My whole childhood I spent playing…

    1 条评论
  • How did I fail in mentorship

    How did I fail in mentorship

    From the age of 18, I have been a mentor at Code Club Ukraine and my educational approach always has been……

    1 条评论

社区洞察

其他会员也浏览了