Five must-have visualisation tools for every product manager
“I don’t follow, can you explain it again?”
It happens to all of us. You thought you were clearly explaining a problem, but others in the room have slowly started tuning out — checking their emails or using their phones in silent protest. You understand the problem well, but can’t find the right way to communicate it.
Having a set of visualisation tools and techniques to call on can be the difference between a product manager who struggles to get buy in and an influential product manager.
Below are five visualisation techniques along with examples that reinforce the old adage “a picture is worth a thousand words”.
1. Venn diagrams
When to use them: To help visualise the relationships between two or more data sets.
Example
We have two teams advertising their features on a dashboard. There is overlap between the target users but we’re not sure how big it is. We also know team one will get priority over team two if a user is eligible for both adverts.
Let’s look at the numbers.
- Eligible for team one’s advert = 135,784
- Eligible for team two’s advert = 36,835
- Eligible for both = 29,111
It’s a bit hard to understand based on the raw numbers, but what if we use a Venn diagram?
Suddenly it’s much easier to make the decision on whether we should invest time to advertise team two’s feature to customers.
We can also take this diagram to team one and quickly show them the opportunity we are sharing and have a data informed negotiation.
2. Rainbow roadmaps
When to use them: To show the build order of a feature to your team or stakeholders.
Example
Shipping a feature then iterating on it with continual releases gives you the ability to learn from customer feedback and respond quickly.
The first release often feels embarrassing and internal stakeholders may wonder why it is so bare bones. To help communicate your team’s vision and ensure stakeholders know this is a journey and not small features delivered in isolation, try creating a rainbow roadmap to show the prioritised build order.
In addition, the final frame is a handy print out for the whole team that can be displayed on the wall or on desks to keep everyone on track.
3. Funnels
When to use them: To analyse a series of steps in a user journey.
Example
Funnels allow us to visualise the steps required in pursuit of a goal and measure the completion rate along with the drop off between steps. You might think you know where your biggest drops are in your user journey, but funnels don’t lie and are often sobering reading.
In addition, funnels are a great way to compare performance of an experiment versus your original flow, provided the steps are comparable. Let’s have a look at a funnel that shows the performance of a four step flow with an experiment running.
Funnels like this serve as a wonderful talking point for your team. Use them to spark a conversation, you will get many shared insights.
Here are a few items of interest.
- If we improve conversion at step 1, we should retain most users through to the goal
- We should understand why step 1 and 2 performed better in the experiment
- The original still outperforms the experiment despite being behind until the last step
One of the best things about a funnel is it strips away the sparkle of the user experience that you may be so fond of. It can feel clinical to see your apps user journey broken down like this, but it brings objectivity to the discussion.
Pro tip: funnels are easy to draw on a whiteboard, so whip them out when the time is ripe.
4. Matrix charts
When to use them: Where you have multi-dimensional options to visualise.
Example
When adding a new user to an enterprise SaaS product, let’s imagine there are the following options to choose from:
We can…
- Set the password for the user OR
- Allow the user to set their password
And…
- Notify the user they have an account OR
- Not notify the user at all
However, one of the four combinations is not supported. Argh, this sounds complicated.
Let’s draw it up as a matrix chart and see how it looks.
What looks complicated in raw text is now easier to understand and reason about. When drawn up on a whiteboard, you can simply point to each cell and discuss with your team.
Matrix charts are great for representing dense information with many combinations.
5. Customer value/Technical complexity graph
When to use them: To help with feature prioritisation.
Example
A rainbow roadmap illustrates the prioritised build order of your feature, but how do you decide on the priority in the first place?
A customer value/technical complexity graph neatly ranks your features based on how much value they bring to the customer versus their complexity to build. The higher the value and lower the technical complexity, the higher the priority.
As there is not necessarily a value you can ascribe to each item, this diagram requires discussion with your team. They should be thinking about each items value and complexity relative to the others. Be sure to seek feedback from colleagues in customer facing roles, too.
The customer value/technical complexity graph below breaks down each component of a new feature called User Profiles.
It becomes immediately obvious which sub-features should be prioritised over others. The y = x line also helps illustrate that the Permissions, Notifications and Groups features all have the same bang for buck. It’s true groups brings more customer value, but it’s harder to build.
Pro tip: There are almost always other factors you should consider when prioritising features, so use the customer value/technical complexity graph as an input, not the answer.
There you have it, five powerful visualisation tools you can use during your next team meeting to cut through confusion.
Use them wisely.
