What's your secret to prioritizing product features?

And remember, that prioritisation is a tactic, from week to week or month to month the key metrics you use to set and manage prioritisation can themselves change according to a strategy. In startup land and major new product launches, you may bias your priorities to support configurability and a full end to end flow so you can deliver first value to trials and not fall over if a little piece of your solution needs adjusting. But, as you grow first customers to commercial adoption you have to prioritise quality, basic security and user feedback. Over time you adjust delivery team workloads to performance and scale targets, to ensure security is strong and be certain your event logs and unit costs are on track to ensure profitability.

Prioritizing product features involves considering several key factors. Firstly, it's important to listen to your users and prioritize features that address their biggest pain points. Secondly, aligning features with your business goals can ensure that your product contributes to the success of your organization. Thirdly, prioritizing features that have the biggest impact with the least amount of effort can make efficient use of resources. Fourthly, competitive analysis can identify features that give your product a competitive edge or keep up with industry standards. Fifthly, technical feasibility ensures that features can be implemented within your product's existing infrastructure. Finally, prioritizing features with the highest ROI.

One thing I have found helpful in tech products is defining a healthy balance between technical features which ensure security, scalability, availability of the product and product-roadmap features which meet business goals by discussing it with the relevant stakeholders. It will vary based on the stage of the product. During early stages, the need for technical features will be much more and gradually it will move to a "keep the lights on" or maintenance state.

One thing that is helpful is to set a well-defined goal and the Identify the KPIs or metrics to measure the goals. Then identify the controllable actions that will work as input to topline goals and accordingly prioritize and track the activities.

The product goals are almost a byproduct of the product strategy and entire GTM strategy of the company. Are you a successful freemium player that aims to go upmarket? Are you crystal clear about your ICP and has that changed? Do you have a churn issue? All these things should create focus across the organization, product included.

It is important to understand that no matter how deep the preparation work like interviews, personas, jobs to be done was performed, it still remains just a hypothesis in searching the product-market fit. This is still a starting point, you can't avoid that and must not underestimate what needs to be done here, since if the original hypothesis is completely wrong, then it will cost a lot when pivoted later on - resources, time to market, and team morale are at stakes. So choose wisely, but remember that the proper validation must follow swiftly.

Imagine you're baking cookies for your friends. You can't just make any cookies; you need to know what kind they like. That's like user research in product development – we ask people what they want in a product. Methods like surveys or user testing are like asking your friends directly or letting them taste different cookie types. Once we know what people like, we decide which features (or cookie ingredients) are most important to include. That's feature prioritization. Just as your cookies would be a hit at the party, a product developed with user research meets users' needs and is more likely to succeed!

What I see too often is hyper-focus on current customers and users pre-launch, and very little if any retrospective or revisiting actual results. Adoption rates, stickiness matrix, changes in time in app, churn rates, increased revenue sometimes—all those could really tell you whether you actually solved that pain you were going after. And remember, not all product development efforts translate into UI/UX. If you’re going after enterprise customers for example, prepare to spend a significant amount of time on work that no one will see, but are still crucial for passing any RFP.

Start by listing your users or personas and grouping them into cohorts based on their needs & pain points. Then concentrate on the right cohort and their requirements without tipping off the balance in which your Product operates. NPS surveys could be a great way of capturing user insights and pain points. I have found it easier form cohorts from the respondents of the survey and use their feedback to drive my backlog.

I believe it should be market facing and it can be done at a lower cost using MVP. This helps the speed of action and of course the MVP should be based on the rules.

A product manager is a person with many talents and experiences. Having a team and building a team based on the instinct to act and understand, as well as the courage and endurance of a hard life, is one of the things that a product manager is responsible for. So whenever life becomes difficult for you, know that you are doing the right thing. Of course, as a product manager

Features should not be so complex that they become the product. They should be functional components of the product. Regardless of the method used to evaluate features, each feature or feature block (related features that can function alone, but have a common relationship that provides congruity), should provide a solution. From a value assessment perspective impact should always exceed effort. If the overall effort is greater than the impact then either the feature is not clear, feature should be split or merged with another, or it does not have value. Feature assessments ought to be part of a regular review cadence.

Impact/effort or cost/benefit analysis is the best prioritization technique that you may use. Evaluating every feature low or high on both parameters will split your features into 4 groups: 1. Low effort, high benefit - implement these features first. You will see high ROI and KPI growth. 2. Low effort, low benefit - these are usually small features that should be done. Ideal for filling gaps in the production process 3. High effort, low benefit - delete these features. You do not want to waste your effort with minimal impact 4. High effort, high benefit - these are usually mid-term projects that have the potential to significantly boost your business but require major investment

This is where Customer Advisory Boards (or CABs) and alpha or beta testing can come in very handy. If you’re running these programs remember that knowing who to invite to participate is key to get the most value out of them.

Thinking up everything in ones head and planning around it, then building and pushing is a sure way to end up with irrelevant products. What do the customers think? How do you know it's something they need and will use? You need to get answers from real customers, directly and indirectly.

The most successful launches I’ve seen are ones where the KPIs touched different parts of the organization. Number of Customer Support tickets around a specific area or even mentions or audience size on social are excellent examples. Launches are a team sport and it should be reflected in how you measure success too. If you get that part right you’re more likely to get your internal counterparts invested in the entire process.

Communication and open collaboration is a key to success for any product management team. Keep your xfn partners early engaged in feature requirements elicitation. Keep stakeholders updated on the progress of feature development on a bi-weekly bases. Also identify early beta test ideas and user base. Take stakeholder feedback to make sure the scope of test is wide enough and covers all risks etc. Such early collaboration will help get prioritization from all xfn teams and result in timely deployment of features. Also be adaptable to change. if there are some requirements which impact feature development, keep the xfn teams informed in a timely manner

launcher: This was one of the most beautiful expressions I heard for a product manager. I think by taking out launcher tasks, we can get a nice task list from product manager. Regarding KPIs, there is a need for a high level of intelligence because putting the wrong KPIs only causes destruction

Navigating product prioritization can pose intricate challenges, especially in the landscape of B2B enterprises. Here, the intricacies of feature prioritization are profoundly shaped by client dynamics. It's often the case that the client contributing the highest Monthly Recurring Revenue (MRR) wields considerable influence over the product's roadmap and priority setting. In this nuanced environment, balancing the needs and demands of key clients while aligning them with the overarching product strategy is a delicate art. Effective communication and a strategic approach are paramount to ensure that client-driven priorities harmonize with the long-term vision for the product.

Here's the real secret. Prioritize it together with the leaders across functions. Prioritization is a x-functional decision made together. And together you will generate criteria what will be prioritized and deprioritized. PS. PMs doesn't have the liberty to prioritize on their own.

My experience at B2B startup, feature prioritization relies on various factors: - Vision, Initiatives, Strategy, Roadmap align with company goals - KPIs - Value to users and reach - Impact - Feasibility For instance, product launch for a B2B SaaS data platform, if a machine learning feature needs to be prioritized. Ensure alignment with vision for decision making, bigbet vs short-term wins, and fits to product strategy. Plan launch in X weeks and KPIs, value to users, value proposition, and is technically feasible. Take into consideration Customer feedback and market research (user needs and industry trends). This approach helps to deliver features that align with company's goals and provide significant value to users.

Review logical, technical, and business specific dependencies. If feature Y makes sense only when feature X is available, build X first. If feature Y can be implemented only after feature X is done, build X first. If feature Y brings value only in connection with feature X - you got it. Same is true about cross domain dependencies in complex enterprise solutions. Each new feature should bring value to your customers. Your feature Y may depend on feature X in the upstream domain, while feature Z in the downstream domain depends on your Y. Communication is key so that your customer ultimately benefits from XYZ.

I tell to managers in these cases: even twin babies are not born at the same time. Everything has a priority. But eventually both are born :))