Updated: January 9, 2023 - 18 min read
Product prioritization is the art of choosing the right features to develop, in the correct order at the opportune time. It balances the importance of features alongside their complexity and the end value they will deliver. The main idea of prioritization in Product Management is to maximize business results with the available resources. Product prioritization is not limited to only CPO roles. It could be also covered by Product Marketing, Product Design, or engineering teams.While working as the Head of Marketing at a high-growth no-code startup, I led Product Marketing and oversaw Product Management functions. Both of the functions were highly connected with testing product hypotheses for our website, users’ and developers’ onboarding, and the product itself. In total, we tested more than 50 product ideas and increased funnel conversion almost 6x times across all stages of the customer journey. Ruthless prioritization was the key to my team’s success.
Prioritization as a startup superpower
There are hundreds of features a startup might want to build. As well as hundreds of UI improvements to tweak, millions of marketing ideas to test, and dozens of growth tactics to try. Which of those ideas would move the needle for your startup? And which would take a lot of time and bring mediocre traction?High-growth startups operate in the ocean of chaos and uncertainty. So well-thought-out prioritization of every activity is the only way to drive growth for startups with a limited time, attention, and budget. While this guide is purely focused on product prioritization, you can use the same frameworks for marketing, growth, and design hypothesis.As Lenny Rachitsky from Airbnb once wrote, “bad prioritization is an excellent way to kill your startup”. Don’t let it happen.
Feature prioritization at startups — Why it’s so hard
Successful companies start with the products people love. However, choosing the right features to develop is difficult for so many reasons, especially for startups. I’ve been working within startups for the last 10 years and Product Development has never been easy. So let’s talk about typical problems startups have when trying to decide what to build: limited resources, high probability to be biased, not enough data, lack of alignment and absence of Product Strategy.
Limited resources
Startup founders don’t have the luxury of calmly building lots of small features, hoping that some of them will improve the product. Neither do they have a chance to bet on one huge feature and risk one year of development. Startups should focus on the “pain-killer” features which will bring the “AHA moment” closer and increase usage metrics. If this doesn’t happen, the startup will run out of money while the product will be useless. The less funding a startup has, the fewer mistakes (iterations) it can afford to make when building an MVP or figuring out Product-Market Fit.
High probability of bias
If you read The Mom Test book, you probably know that people will lie about their experience with your product to make you feel comfortable. Startup founders tend to be very biased towards features they believe in, especially when “high-potential” users shower the product with compliments. This means that product prioritization can be influenced by biased opinions, having “nice-to-have” features at the top of the list. Most startup founders have their own vision and “Product Intuition”, sometimes it works but not always.
Not enough data
Startups might not have enough data to prioritize one feature over another, both from the impact or difficulty to build perspective. Sometimes having someone who can gather and interpret data is a challenge for startups. Even in the PM & PMM world, having a strong data-driven team is more often a dream rather than a current reality.
Lack of alignment
When a startup tries to move at the speed of light, that movement could be in all manner of directions. Different teams will have varying opinions as to what is “important”. Product prioritization becomes a fight between what brings Product-Led Growth, more leads, higher Net Promoter Score, better User Experience, higher retention, or lower churn. Lack of alignment is not the last issue startups face when prioritizing features.
Absence of Product Strategy
Sometimes startups get too obsessed with building what competitors have rather than what their users need. In other cases, a Product Strategy with a clear roadmap does not exist at all, so features will fill urgent needs rather than help achieve strategic goals.
Feature prioritization frameworks
Despite all difficulties with feature prioritization, you can get it right using one of the popular frameworks. Consider them a way to structure your thinking process, keep focus and stay on course. The job of the Product Owner leading this process is to pick the proper framework for the startup’s needs.Thanks to my experience with these frameworks, I will be able to share some practical and interesting use cases from my time at WeLoveNoCode, both from Product and Marketing perspectives. Obviously, we didn’t use all of them at the same time but tested how those prioritization frameworks will suit us:1. RICE Method
2. Impact–Effort Matrix3. Feasibility, Desirability, and Viability Scorecard4. Weighted Scoring Prioritization5. MoSCoW Analysis6. Cost of Delay
RICE Method
Let’s start our deep dive into prioritization with a framework developed by the Intercom team. It rates every feature, hypothesis, or idea based on four factors — Reach, Impact, Confidence, and Effort. As a Product Owner in a startup, you would think about each factor from a very pragmatic perspective:
Reach
You should think about how many users the feature could impact in a specific timeframe. For example, the number of new engaged b2b customers you can gain if you release this feature. Or the amount of new no-code developers who can start working via our marketplace, if we implement a new developers’ onboarding. It’s normal to put estimates here.
Impact
How important will this feature be for users? Even if the feature has a small reach but helps solve the big problem of the high-LTV clients, then its Impact would be high. Your team should be able
with the customers’ pains to correctly evaluate impact.
Confidence
Can this product idea bring significant reach and impact? The Confidence factor comes from 0 to 100% where 100% is a total confidence, and 0% is a complete lack of confidence. Product Owners in startups are evaluating probabilities. So when my team works on a new hypothesis, we leave ourselves space to be wrong and it’s totally fine.
Effort
When your resources are very limited, the time it takes to develop features is critical. Eventually, it comes down to the complexity of the feature and size of your tech team. So the Effort factor is scored as “the required number of people per month” value. The lower, the better.
Usually, the Product Owner will score all features in the spreadsheet like this based on the Reach, Impact, Confidence, and Effort. Then discuss scoring with the team. All scores go into the formula. The first three elements are multiplied together and then this total is divided by “Effort” to give a final score for each feature. Product ideas with the biggest score go into the development backlog.
When we used RICE for WeLoveNoCode developers’ onboarding, we had a hypothesis that if we decrease steps in developers’ onboarding from 4 to 2 it will increase the number of developers’ registrations.Let’s say that the Reach for us was around 3,000 new devs/per month. The Impact was massive, with a score of 3. Our sign-up form abandonment rate was 66%! The Confidence was 90%, as we had data on how similar changes influenced customers’ onboarding, on top of feedback from developers.The Effort was low, as we had a strong Bubble developer to build it. At the end of prioritizing all product hypotheses, this one had the highest score and went into development first. The RICE framework is suitable for some cases but also has some downsides:
Pros of using this framework
Its spreadsheet format and data-base approach are awesome for data-focused teams. This method also filters out guesswork and the “loudest voice” factor because of the confidence metric. Typically, we tested 10-15 product hypotheses per week at WeLoveNoCode, so having a spreadsheet format is actually very good.
Cons of using this framework
The RICE format might be hard to digest if your startup team consists mainly of visual thinkers. When you move fast, it’s essential to use a format that everyone will find comfortable. Sometimes it’s a prioritization for 30+ possible features for complex products, let’s say a new animation editor. So it becomes a long spreadsheet to digest.
Impact–Effort Matrix
If your team is full of visual thinkers, the impact–effort matrix will suit you. This 2-D matrix plots the “value” (impact) of a feature to the user vs the complexity of development, otherwise known as the “effort”. When using the impact–effort matrix, the Product Owner firstly adds all features, or product hypotheses. Then the team who executes on these product hypotheses votes on where to place the features on the impact and effort dimensions. So every everything goes into one of 4 quadrants:
Quick wins
Low effort and high impact are features or ideas that will bring growth. For WeLoveNoCode, quick wins were
optimization of landing pages’ design/content for Google Ads campaigns. This significantly boosted ad performance, brought us more leads and made the experience better for those pages. While it was a hypothesis in between paid and Product Marketing, it worked very well and required just minor changes on our Tilda websites.
Big bets
High effort but high impact. These have the potential to make a big difference but must be well planned. If your hypothesis fails here, you just waste a lot of development time. As one more real-life example, our big bet was redesigning clients’ dashboard and creating a funnel to lead users to buy trials without calls with sales managers. Think of it as designing a self-serve model for a sales-led product. As a result, during the first week we implemented it, we achieved 4 trials (with the potential of a $4000 monthly subscription) per week without sales touches.
Fill-ins
Low value but also low effort. Fill-ins might not take much time but can only be justified if other more important tasks are complete. It’s not “fast wins” but rather backlog items that you might want to build. As fill-ins, we redesigned the animation on our landing page header. It didn’t have a high impact and didn’t take time, as we made animations very simple and right in Tilda. At the same time, it looked more consistent with the rest of the landing page design.
Money pit
Low value and high effort. These are the features that can kill a startup if time is wasted on them. In 2015 I was working on my startup called
. Back then we spent 12 months building a fully-functional MVP with three plugins, a web version, and a website. Too many features, not enough research, and no prioritization resulted in the failure of the first version. Eventually, we built features which users wanted, getting 17,000+ designers & developers from big companies to use our products. Later on Flawless App was acquired by Abstract, so my startup story had a happy ending.
Impact–effort matrix can live inside your team’s Miro or Mural board. This approach is ideal when you have many contributors and need to choose between a few key features/product ideas. Like any other framework, the impact–effort matrix has its pros and cons:
Pros of using impact–effort matrix
It allows quick prioritization and works well when the number of features is small. It is very visual, ideal for design-led companies. Also, it can be shared across the whole startup team, as it’s easy to understand from the first look.
Cons of using impact–effort matrix
It doesn’t work well when you have a lot of features, ideas, and items to discuss. It’s hard to visually prioritize many ideas with a high level of accuracy. For example, if two product hypotheses are “quick wins”, which should go first? Also, sometimes “fill-ins” take much more time and resources than expected and create loss of focus, which is very dangerous for startups.
Feasibility, Desirability, and Viability scorecard
Developed by IDEO in the early 2000s, this scorecard takes three core criteria — feasibility, desirability, and viability. It scores each criterion for every feature and takes a total to decide on the priority. Scoring work from 1 to 10. Based on my experience, it’s a good framework for evaluating high-level features for future products (but it’s not purely for PM). We used it during discussion at my startup Flawless App. Here are what every dimension means:
Feasibility
Can we build this feature with skills and resources available? Is it possible to make this particular product hypothesis fast and without hiring extra people? Do you have an available tech stack/tools/cloud storage to do it?
Desirability
Does this solve the pain for the customers? Do they really want this feature? Will they be ready to pay for it?
Viability
Will users actually pay for it and how much? Is it worth investing in it (ROI)? Is there any unit economy behind this feature?
Using this framework, your team creates a spreadsheet with product features and puts a score for each parameter. Another way to use this framework is to evaluate MVP ideas for feasibility, desirability, and viability via a team discussion. Ideas that have the most support from the team on those parameters can go right into the design sprint. Use the relevant people to help the evaluating, for example, developers to look at feasibility or Product Marketing Managers to discuss desirability. This scorecard is pretty straightforward with clear pros and cons:
Pros of using a feasibility, desirability, and viability scorecard
It is flexible and can be customized to work for the specific requirements of the startup. For example, feasibility, desirability, and viability scorecards can be used for evaluating marketing initiatives, hypotheses for customer success teams, or MVP concepts. As some startups don’t work well with rigid frameworks, this model can be a good option.
Cons of using a feasibility, desirability, and viability scorecard
This approach relies a lot on knowledge of what the customer wants and how complex new features are. That is not always data that a startup has. Also, it’s more suitable for a workshop, or discussion on the executive level. For Product Marketing or Product Management teams, it’s not a day-to-day tool (I may be biased, so feel free to share your opinions here).
Weighted Scoring Prioritization
This method follows a similar pattern to other frameworks on this list but with the significant addition of weighting how much of each category counts towards the final total.
The process starts by selecting the criteria/categories you’ll be using to rate the features. For example, you might select “user experience”, “sales value”, “strategic impact”, “user adoption” or any of the Acquisition, Activation, Retention, Referral, Revenue (AARRR) metrics if you want to focus on user behavior.
Next, you need to decide what importance you give to each category, adding a percentage value to each criterion (up to 100%). For example, during the early stages, you might focus on user experience to make an MVP usable, or if you have a product with a Product-Market Fit you might need to think more about retention. Each feature will have a score on those categories, from 1 (min impact) – 100 (max impact). Then you can now calculate the final score for each feature.
This method has the potential to be very useful in the startup where you can customize the weighting to fit the changing priorities of the business:
Pros of using weighted scoring prioritization
The framework is customizable, whereas many others in this list are more rigid in their implementation. This allows you to utilize the framework over a longer period of time by changing the emphasis to fit where you are in your journey.
Cons of using weighted scoring prioritization
Sometimes the weighting percentages can be hard to put. If you’re a founder who can understand how each feature will influence user adoption across the whole product ecosystem, then it might work. However, PMMs & PMs might not always have such a “bird-eye” view in a startup.
MoSCoW analysis
This is a popular framework within the agile world that speaks the simple language of how you would describe the feature to a friend. According to MoSCoW, all the features go into one of four categories:
Must Have
These are the features that will make or break the product. Without them, the user will not be able to get value from the product or won’t be able to use it. The “must-have” features are the reasons why users will pay for your product. For collaboration-based products those are the ability to invite team-members to the workspace/project and work together.
Should Have
Those are important features but not vital to have right away. Think of them as your “second priorities”. It could be enhanced options to collaborate better on some typical use-cases. It could be collaboration templates, similar to Miro Templates Library or Airtable Templates.
Could Have
Often seen as nice to have items, not critical but would be welcomed. Something similar to “vitamin” features but not “pain killers”. That can be integrations and extensions, adding your product to the typical users’ workflow.
Will Not Have
Those are features or product hypotheses that are not required and should be dropped. It’s similar to the “money pit” in the impact–effort matrix framework.
The MoSCoW framework can be used in a Miro board, so your team can prioritize features visually there. It can be a good choice at the start when you need to define features to include.
Pros of using this framework
This is ideal when looking for a simplified approach that can involve the less technical members of the company and one that can easily categorize the most important features.
Cons of using this framework
It is difficult to set the right number of must-have features. Your Product Backlog can have too much must-have features which puts pressure on the development team.
Cost of Delay
Unique in this list, as this framework focuses only on the monetary value as the measurement. The framework is designed to calculate the cost to the startup of not producing the feature immediately. It’s relatively straightforward to understand, although the calculation itself does require significant thought from your teams. The calculation is as follows:
Estimated revenue per unit of time, for example, how much could be billed over a month period if the feature existed.
Estimated time it will take to complete the development of the feature.
Divide the estimated revenue by the estimated time to give you the cost of delay.
Let’s talk about one more example. WeLoveNoCode had a sales funnel when the client jumps on the call with the no-code expert before starting the trial. One of the marketing goals was to lead MQLs to the call. By increasing the number of calls, we increase the number of deals. So everything that slows down this process costs us revenue. When we were prioritizing a new set of product hypotheses based on the Cost of Delay framework, we had one clear “winner”. This was a hypothesis about decreasing the amount of friction during booking the call customer journey. One point of friction was a long sales screening questionnaire inside booking a call software (Calendly). We estimated the Cost of Delay in the lost deals opportunities.This is a good framework when a startup is focused on working through a feature list rather than building an initial MVP:
Pros of using this framework
You can directly calculate the value of producing a feature, so it’s a highly effective way of prioritizing feature backlogs. It is also useful in helping team members understand the value of features they might not have appreciated.
Cons of using this framework
For startups without a stable business model, the revenue estimate is very much based on a gut feel and as a result, can often involve internal arguments about the final figure.
Prioritization within a startup is (smart) guesswork
Prioritization in a startup is about laser focus on things that matter the most. You need a framework in place that ensures you are building the right features, choosing the right hypothesis to test, running a promising marketing campaign, and designing important user interfaces.
However, it’s still smart guesswork. The decisions you need to make will have an element of instinct as well. So you need to be agile in your approach. Trust yourself, listen to users, and don’t be afraid to change priorities if needed.
Updated: January 9, 2023