How to Prioritize Features: A Framework from Feature Demand Generation to Feature Prioritization
Prioritization is the most critical part of building a company towards product-market fit and beyond. Your limited time won’t allow you to make mistakes that take 3–4 months away from your runway by building a feature that nobody wants. Wrong product decisions might cost a company its life.
Your job as CPO, VP of product, head of product or product manager is to narrow down feature requests to a focused fraction that is hyper examined from multiple angles to make your decision more robust.
Quality decisions for the next feature start with the appropriate quantity of feature requests in the pipeline. Without rich data of feature requests & demand, you are fishing in the dark. Your prioritization work starts with building a healthy request pipeline.
Start to Establish a Product Feature Pipeline
Three essential blocks need to be established in your workflow to create and to increase a product feature pipeline health (PFPH) — a term you might not heart off yet. PFPH indicates the future demand for your product and potential product growth — an angle investors also should use to judge your product potential.
In the following article, I will walk you through how to set up the workflow from feature request generation to prioritizing them down. A feature prioritization framework will help to establish a standardized angle of how requests are evaluated and prioritized.
If you have issues with roadmap clarity, evaluating requests and its communication of those priorities, this framework will help you guide and articulate your product prioritization.
Turn your Company into a Feature Request Engine
The more you can increase a culture of feature ideation and simultaneously reduce the friction of submitting ideas, the higher is the chance to create a healthy feature request pipeline and build out a product that people want.
We at Passbase opened the door to everyone from external to internal stakeholders to submit product ideas, features and feedback. This helped us to generate a healthy product feature pipeline and also increased the bond between our customers and Passbase. Transparency on the future feature outlook even helped to convert customers.
How to Develop a Healthy Product Feature Pipeline
Sales talks about a client health pipeline to showcase the future revenue potential, and this is what you have to do from a product perspective for future features as well.
Feature requests should come from multiple channels to generate a broad facette and diverse snapshot of feature demands. Those should be separated into External Requests and Internal Requests. Let’s break those down to give you new tools and ideas for your organization:
Sales: Sales conversations are the major channel to gather feedback and voice from current clients and potential clients. Train your sales team to use the final minutes of a sales conversation to trigger feedback and open requests like:
1. What would be the magical button in the product that you would like to have? 2. What feature is still missing to convert you to a higher plan?
Product Council: Establish a Product Council that will foster relationships with current power users and potential clients to a have a sounding board for strategic requests. The purpose of the Product Council is to set the strategic direction of the product plus incorporating multiple market angles from a short term and long term angle.
Feature Request Board: Start to provide a public feature request board, that tracks submitted feature requests, gathers upvotes and comments. We at Passbase use hellonext.co as our public feature request board, that is publicly available for everyone. We even publish own ideas and requests to validate the need and demand for internal ideas.
Weekly Customer Retroperspectives: Product people can not always attend sales conversation. Therefore, a forum needs to be established between the sales team and product team to highlight open requests, feedback and questions. It gives the product team an excerpt of customer reactions on a weekly basis. At Passbase, we separate this meeting into three question blocks:
1. What were the most asked questions in live chats or customer calls?
2. What are the reasons why a customer turned us down / we lost a deal?
3. What feature is missing to win the next big client?
Analytics / Usage: The power of analyzing user behavior is fundamental. If you haven’t already, start to implement product analytics like Mixpanel, Hotjar or Crazyegg. Try to track down the 20% most critical user behaviors of your product, spot user flow weaknesses that lead to a bounce or simple track down errors with Datadog or Sentry.
Rich Data Will define the Quality of Your Decision
If you implement the first part of this framework into your organization, there is a good chance to establish and increase your PFPH. But of course, also the quality for those feature requests matter.
Therefore, gather as much information as possible around those requests and start to track the following data points: Internal/External Requestor, Company Name, Customer Email, Date Requested, Deal Volume, Customer Plan, Potential Revenue, Important Side Notes. Additionally, force to gather further details around the feature request:
1. What problem are we solving? What is the purpose?
2. Describe the feature in detail
3. Describe the reach of the feature
4. Describe the confidence
A full template can be found here: Feature Request Template.
5-Pillar-Prioritization-Framework
All steps described beforehand need to happen before you can start to actually make quality decisions. If you fail to establish a strong request pipeline with quality data, you are probably going to fail to make the right feature decision for your company. All data points gathered are needed to run the framework described below. It consists of five pillars that I will describe in the following:
Reach
The first pillar describes the amount of customers that will be impacted from this feature.
1 = A specific customer will profit from this output
10 = All customers will profit from this output
If you build features for a just single customer, which does not reach other customers, you end up in a hard and linear growth path. Scalability of your engineering efforts is king. Find features that have an overlap for multiple customers and customer needs and you’ll see the increase contribution to the value of our product. Think about this pillar like as the compound effect for product features.
Customer Impact
Especially in your early days as a pre-product-market-fit company, focus plays an essential role. You have to break down your product under the jobs-to-be-done framework to have the right understanding of the value that your customers seek. In your early days as product person, you have to wake up and sleep in with this in your mind to nail the right perspective of your product, market, need. This second pillar customer impact is essential to find features, that have a massive impact on adding value for the customer. It covers the impact on the most important functionality / jobs to be done task and describes the cadence of the impact.
1 = One time impact, non recurring
10 = Customers are impacted heavily in their recurring workflow routine
Business Impact
This pillar describes multiple angles of impact towards your business. On a meta level is represents the alignment to your company strategy and more precisely the alignment on your OKRs. It represents the implications of your revenue, compliance risk and even implications of shadow costs if you are not going to deliver this feature request. As the business impact differs from company to company, you have to define it by yourself.
1 = No impact on OKRs, no impact on revenue
10 = Direct impact on OKRs, impacts also revenue, compliance risk if feature wont be tackled
Validation
Validation is one of the dynamic pillars, that needs a recurring assessment as the demand for a feature might change over time. Make sure, your team keep tracking customers, who request the same feature.
As already mentioned, a powerful but simple way for this pillar is to establish a publish feature request board, where customers can submit but also upvote other feature requests. Try to validate feature requests and internal ideas as soon and as much as possible. Ramp up early MVPs, click dummies to validate the direction of features. This saves you tremendous cost and time taken up by unvalidated requests that enter the development cycle.
1 = None of the customers requested the feature, no evidence of demand
10 = Top-requested feature internally and externally, the 2 customers signed a deal to get this feature
Ease
The last pillar represents the effort it takes to build this feature. Evaluate with your engineering leads the complexity of this feature. Rough Development time, stakeholder involvements and overall complexity are usually under-estimated, so take your time to make a due diligence to gather the right requirements and overseen tasks to not over-promise. It summarizes the estimate of how much effort it will take to build this feature from an engineering, design, business and product perspective. This pillar includes also a check against the feasibility overall of this request with the current resources you have in the team. Keep in mind, that a complex feature request doesn’t mean, it needs to be de-prioritized.
1 = Legal, design, backend, front-end, third party vendor are involved, multi sprint
10 = Only one 1 front-end engineer is involved, low complexity, 1 day development time
Weigh Your Pillars
Every startup is different and has different short term and long terms goals. This framework is not robust enough throughout all phases of a startup. Therefore, you can adjust the pillars based on the phase you are in by adding weights to each pillar. This allows you to fine tune strategic alignments and a better fit to your current problem set.
If you execute this framework well, you’ll have a chance to implement a workflow from feature demand generation towards feature prioritization that will trigger compound effects for customers, your organization and potential growth. Extending this framework with weights will make it even more robust and adjustable to each phase of your startup.
Nonetheless, take this framework as an indicator and not as a bullet proof solution. As subjective views are in the loop, you do not always find the golden nuggets. The best product people out there do not excel by building equations in excel but excel by putting the results in context, influenced by their past experience and intuition. That’s why the product person makes the final decision on feature selection and not the sales department.
It’s your turn to execute — and build products that people want.
Other Articles from the Author
