How do you balance building, enhancing, and fixing features?

While vision and strategy create meaning and purpose, I'm not convinced they are enough to prioritize the backlog. This comes from baselining your current product metrics and identifying hotspots (bottlenecks or constraints) that stand to drive the biggest impact (traction) in the business model. Then align your team and stakeholders around a time-boxed goal and constraint to break. I'm an advocate for using 90 days which is long enough to drive measurable impact yet short enough for rapid iteration.

Your Product Strategy explains what big buckets/pillars you’re going to be working on to be the best in your market. More than anything, it should give you an indisputable idea of what things you’re going to say “No” to and what are you going to obsess over. All product companies should have a solid product strategy to align the whole team behind. This really makes a big difference to prioritise against what’s important and to focus and empow the teams to work on what can make an impact.

Talk to the end-user, what do they wish they had? What challenges are they experiencing, and how can "the team" design to provide solutions?

In my experience, defining what you will not do as part of your product vision and strategy is just as important as what you will do. A great product vision must help teams on the ground make daily decisions quickly. While the product vision won't, or shouldn't, change too often, the product strategy is what will affect the balance between building, enhancing, or fixing features. What will get you the fastest closer to your product vision in the next 2-3 years?

Product Strategy is not static. Regardless of the maturity of your product and company, you have to consistently re-evaluate your strategy for it to serve as an effective foundation. It does no good to have a strategy does not applycable to the current market demand and constraints.

The important thing when prioritising is to focus on what you're trying to achieve. Look at the important metrics to move and what's in the product strategy as the important pillars. It's also good to have a high-level Roadmap before jumping straight to the backlog items. This highlights the activities to go through to achieve the Strategy. Vision -> Strategy -> Roadmap -> backlog.

We need to analyze the backlog items together with risk management. Cause you need to know what could be the impact if you don't fix an issue or don't enhance some feature. In the same way, technical debits could be the fourth item on this list and the one that causes the most significant problems if you don't work on it. If you know the impact of each item will be more efficient prioritization and will help the stakeholders in their decisions.

An Action Priority matrix is a quick, visual mechanism to illustrate effort vs impact. Sometimes it takes some digging to understand who or what is impacted by the backlog item. Your stakeholder may be outside your organization or in a different system altogether.

The life cycle stage of the product is an important factor to consider here. Different stages require different amounts of effort and focus on building, enhancing and fixing defects. For 0-1 products, the main activity is building and the main goal is finding the product-market fit, which demands rapid prototyping. For 1-N products, the focus shifts to adding new features and fixing bugs to retain customers and improve user experience for a target market. For products nearing discontinuation, the support level might be reduced to maintenance only, with little to no enhancements and only bug fixing.

The 70-20-10 principle is great, but what the buckets include and how to prioritise depends on the stage of the company and the maturity of the product. For 0-1 product most of the resources are put towards building new things. 70 new features; 20 improvements; 10 infrastructure. For mature products, you'll spend less time on new features. You cannot afford to have many big bets which disrupt the product and current customer base. You have to focus a lot on retention and improving their experience. Here, the buckets would be: 70 on quality of life improvements; 20 on big new bets; 10 on infrastructure. What I find important is to have a structure within which the team can work and prioritise based on principles.

Repairs and technical debt are like cleaning the house. Every day, every week you must make some effort. The longer you delay, the bigger they get. I understand that there is no fixed rule. It is important to align with those involved in the teams and define the objectives for the moment.

A big part of the PMs role which is over missed is the ability to facilitate discussions and get people working together. This is both within the product team and also with external stakeholders. It takes time to build this skill and one gets better at it with time.

"Vision -> Strategy -> Roadmap -> backlog" is a great representation, Matthew Zammit. Product teams can use agile tools like Jira, Aha!, Rally and others to capture that and and create linkages that make it clear for all stakeholders how any backlog item is helping advance the strategy and vision. I've found that being disciplined about this greatly helps the organization stay aligned, and makes it much easier for the PM to communicate the team's progress toward larger goals.

It can not be stressed enough how important it is for a Product Manager to have good communication and collaboration skills. To make informed decisions, you need information/data. Often this means working with people across the organization.

You also need the discipline to cross things off your backlog if they never get prioritized and end up "backlogging" (pun intended) your backlog. Every PM knows the hopeless feeling of managing a 400+ line backlog. It's a beast but nobody wants to kill anything because it was someone's pet idea and we shouldn't upset them. Apply some Marie Kondo principles of "if it hasn't been done in a quarter, we'll move it to the "deadlog". You can keep a deadlog list going - there's always the possibility you'll want to resurrect something from it. But the productivity benefit and the relief of lightening your backlog to a manageable 50-70 item list will be immense.

PMM team can help enhance product planning a lot ?? Sharing new feature ideas into the backlog can come from: 1. User feedback, PMM surveys, social listening, usability data. 2. Competitor intelligence, competitors' reviews & market studies. 3. Deep insights through customer interviews, product or marketing data, sales & CS insights. All these ?? come as a day-to-day job of PMM teams and can greatly help product planning. So don't ignore your awesome PMM teams :)

To effectively prioritize and focus on the right features, it's crucial to measure the value and impact of each item in your product backlog. Implementing a data-driven approach can provide insights into the real value delivered to customers and the business. Utilize relevant key performance indicators (KPIs) such as customer satisfaction, user engagement, retention rates, revenue growth, and conversion rates. Regularly gather feedback from users through surveys, interviews, and usage analytics to gauge the actual impact of implemented features. This data-driven evaluation will empower you to make informed decisions, ensuring that your efforts are aligned with customer needs and strategic objectives.

I don't have much to add to what John had already said about the importance of KPI's. Just as a checklist, I would like to point to the ones I find useful: ? Cost Performance Index (CPI) ? Schedule Performance Index (SPI) ? Stakeholder Satisfaction ? Return on Investment (ROI) ? Quality Metrics ? Risk Exposure ? Program Progress ? Resource Utilization ? Customer Retention Rate Cheers and stay engaged!

PMM team can help enhance product planning a lot ?? Sharing new feature ideas into the backlog can come from: 1. User feedback, PMM surveys, social listening, usability data. 2. Competitor intelligence, competitors' reviews & market studies. 3. Deep insights through customer interviews, product or marketing data, sales & CS insights. All these ?? come as day-to-day of PMM teams and can greatly help product planning. So don't ignore your awesome PMM teams :)