You’re about to launch the MVP of your product—but in the background, there’s a never-ending stream of feature requests from stakeholders who have waited months (if not longer) for their idea to reach the top of the list. Where do you begin to prioritize these requests and foster shared ownership of the outcomes?
I like to use a feature prioritization activity called “Pruning the Product Tree.” This activity is a great framework for getting stakeholders involved, talking about priorities, and building understanding of what it takes to design, develop, test, and launch key features.
The Product Tree Framework
I recommend using the largest whiteboard available to draw your tree. The bigger the tree, the more people can contribute. Your tree should have a few key elements:
- Trunk – to represent the features you’re currently building
- Branches – to represent the categories of features you’ll be building in the future (leave room for more branches to grow in your discussion)
- Roots – to represent the technical requirements or infrastructure needed to make the features you list possible
- Seed Basket – to keep the ideas that don’t make it onto the tree right now
Your tree should look something like this:
You’ll also want some Post-it notes so people can write down specific features and stick them onto the tree. I suggest using green or leaf-shaped Post-its to make it even more realistic.
Framing the Activity
The name of the game is prioritization. Before you get started, explain that features placed closest to the trunk of the tree signify near-term priorities, whereas features placed on the outer ends of the branches signify long-term future plans. You can even draw some dotted boundaries for current, near-term, and future plans if it helps the group prioritize.
Once you’re ready, invite the group to spend a few minutes writing their desired features on Post-its and placing them on the tree. Encourage every participant to contribute to the tree. Seeing what others have posted may help you think of other features or requirements (to be written on the roots).
As groups of features start to emerge, start to cluster them around labeled branches. I prefer to label branches as I go (vs. labeling them ahead of time) so I can avoid making assumptions about the categories. If sub-branches or connections need to be made, draw them in as needed.
A word of caution: It’s easy for this to become an idea generation activity, especially when considering the future of the product. Keep an ear out for this as you facilitate the discussion, and during this activity, focus the group on what is feasible, desirable, and viable.
Discussing as a Group
When the tree is full of leaves, take a few minutes to analyze the results and discuss your observations as a group:
- Are some branches heavier with leaves than others?
- Are any of the categories surprising? Did any of the categories you expected to see fail to get represented on the tree?
- Are there features that require a lot more user understanding? Consider dot-voting those that need to be explored further.
- Do the roots have the infrastructure they need to make these features possible?
Beyond Product or Software Design
At its core, the Pruning the Product Tree activity is a grouping and prioritization method. It works so well with features or ideas because each of those data points is actionable. That’s not to say this design thinking method couldn’t be used in other contexts.
Say you needed to develop a communication strategy across several mediums or you were planning a large event such as a conference and needed to prioritize your efforts. This activity could be a great conversation starter. Work bottom-up from data points to categories or top-down from categories to prioritized data points to determine which aspects of your experience you will focus on and what details you will prioritize first.
This activity is great on its own, but as a follow-up activity, take the outcomes of your tree and turn them into a collaborative document you can share with the team with this Product Roadmap Framework.