Single Blog

The Product Tree

The Product Tree is a collaborative product prioritization framework developed by Bruce Hollman. It is designed to help teams refine their product roadmap by ensuring that valuable ideas are not overlooked while focusing on customer needs. This method allows teams to visualize which features need improvement, which should be prioritized, and which can be postponed for later releases.

This framework is structured like a tree, where different parts represent different stages of product development. The process follows these steps:

1. Creating the Tree: A large tree is drawn on a whiteboard or paper, serving as a visual map for product development.
2. Understanding the Tree’s Structure:
   • The trunk represents the core features already present in the product.
   • The outermost branches indicate the features planned for the next release.
   • The other branches represent future features that have not yet been developed.
3. Adding Feature Leaves: Participants, typically customers, write potential feature ideas on sticky notes, which act as the leaves of the tree.
4. Placing the Leaves: Customers then place their feature ideas on specific branches. This step helps identify which areas need more attention, which features are high-priority, and which can be set aside for future development.

By analyzing where the leaves are clustered, teams can determine the most important areas to focus on for the next development cycle.

PROS of Product Tree

• Provides a clear visual overview of how well-balanced the product’s features are.
• Encourages collaboration, as it allows customers to be directly involved in shaping the product instead of relying on structured surveys.

CONS of Product Tree

• Lacks numerical ranking, making it difficult to objectively compare the importance of different features.
• It can be time-consuming, as features are not grouped into predefined categories, making analysis more complex. 

 Cost of Delay

The Cost of Delay is a prioritization method introduced by Joshua Arnold, designed to help teams measure the financial impact of delaying a feature. It shifts the focus from just development costs to understanding how much value a feature can bring if delivered sooner and how much loss the company would face if it is delayed.

This method works by assigning a monetary value to each feature based on the time and effort required to develop it and the financial impact of delaying its release. To determine priority, teams answer three key questions:

• What would be the value of this feature if it was available right now?
• How much more beneficial would it be if this feature were developed sooner?
• What would be the financial loss if this feature was delayed?

The cost of delay is calculated by estimating how much revenue or savings a feature could generate per week and comparing it with how long it would take to develop.

For example, if a feature causes a loss of $30,000 per week in delays and takes three months to build, it would be prioritized over a feature that causes a $10,000 per week loss but takes the same amount of time. This approach ensures that the most financially impactful features are developed first.

PROS of the Cost of Delay

• Helps quantify the backlog by assigning a financial value to features, making prioritization more objective.
• Enables better decision-making by focusing on the features that will generate the most value for the company.
• Encourages teams to prioritize speed and value instead of just looking at cost and efficiency.

CONS of the Cost of Delay

• Estimates are based on assumptions, making it difficult to assign an exact monetary value to features.
• Can lead to disagreements among stakeholders who may have different views on the financial impact of certain features.

Buy a Feature

Buy a Feature is a collaborative prioritization method that helps product teams understand which features matter most to customers and stakeholders. By assigning monetary value to different features and allowing participants to “purchase” the ones they find most valuable, teams can make data-driven decisions about what to prioritize in development. The working can be explained:

1. List Features and Assign Prices
   Begin by selecting a list of potential features, updates, or ideas that could be added to the product. Each feature is given a price based on the resources required to develop it, such as time, money, and effort. The pricing should not be random—it should reflect real costs to ensure that participants make thoughtful decisions.
2. Distribute a Fixed Budget to Participants
   Gather a small group of participants, typically up to 8 customers or internal stakeholders, and provide them with a set amount of virtual money. This money represents their purchasing power for selecting the features they value the most.
3. Feature Purchasing and Justification
   Participants use their allocated budget to “buy” the features they prefer. Some may invest all their money in a single feature they strongly believe in, while others may distribute their funds across multiple features they find valuable. As part of the process, participants are encouraged to explain their choices, providing valuable insights into why they see certain features as more important.
4. Reordering the Features Based on Value
   After the purchasing phase, the features are ranked based on how much money participants were willing to spend on them. This creates a clear priority list that reflects the most desired updates or improvements. To add another layer of engagement, some features can be priced high enough that no single participant can afford them alone. This forces customers to negotiate and collaborate to decide which features are worth pooling their money on.

Pros of Buy a Feature

• Unlike traditional surveys, this method makes the prioritization process more dynamic and enjoyable for participants.

• Customers are directly involved in the decision-making process, ensuring that the selected features align with real user needs.

Cons of Buy a Feature

• This approach only works with features that the team has already considered, meaning it doesn’t introduce completely new ideas.
• For best results, this method relies on assembling a group of customers or stakeholders at the same time, which can be difficult to coordinate.

Conclusion

Product prioritization is both an art and a science. While data and frameworks help bring structure and clarity, they are ultimately tools to support sound judgment, team alignment, and product intuition. Each framework — whether it’s the precision of RICE, the visual simplicity of Value vs Effort, or the user-centric empathy of KANO — brings a unique advantage to the table. But no single approach fits every situation.

The real power lies in the ability to contextualize your decision-making: understanding your users, your team’s bandwidth, your company’s goals, and the stage your product is in. Sometimes, it’s about ruthless focus; other times, it’s about creative exploration. The best product managers and teams are those who can seamlessly switch between models, adapt their thinking, and justify their roadmap not just with numbers, but with narrative.

In the end, prioritization isn’t just about what features make it to the next sprint — it’s about strategic storytelling: aligning stakeholders, delighting users, and steadily marching toward a bigger vision. So whether you’re mapping user stories, scoring opportunities, or simulating “buy a feature” sessions, remember — you’re not just ranking ideas. You’re shaping the future of your product. Make it count.