Visual Communication templates for Product Managers

People are generally bad listeners. When you have an important story to tell or a complex problem to share, many folks in your audience who are meant to be listening will instead start to dwell on more important things like what to have for dinner or whether they fed the dog on time. Holding people’s attention is difficult. But adding visuals into the mix will help.

As product managers, much of what we do on a day to day basis involves telling stories, giving updates on initiatives and explaining to engineers what the goals of the business are. Visuals help make this process easier. So here’s a selection of some of the ways you can visualise many of the most important stories you need to tell as a product person.

Dependencies

When you’re stuck in the deep depths of complex pieces of work, you’ll often stumble upon areas that are dependent on each other. Articulating the challenges of dependencies is difficult and the addition of a diagram will help to make this easier.

Start by picking the aspects of your work that are dependent on each other and then draw a distinct line between them. This way, stakeholders know that they are interlinked and that one piece of the work cannot be released without the other.

Technical dependencies

If a new feature is completely dependent on another part of the application being completed or a part of the application being improved in some way, technical dependency diagrams are useful to help explain this.

Team based dependencies

Similarly, team-based dependencies are common and arise when the work in progress can’t be completed until another team has completed theirs. Using colours, differentiate between the two teams to explain how the two items are interconnected.

Strategic decisions

What are we building and why are we building it? These are the two questions product managers should be able to answer at any given time.

Reframing decisions as bets with unknown outcomes is a powerful way to explain the risk involved in making decisions.

The benefits of framing strategic decisions as bets

Some of the benefits of approaching strategic decisions this way include:

How the betting table works

In a forum of key decision makers such as product council members, discussions are had about what the goals of the business are and which bets are on the table and which ones are off. Bets are strategic decisions that will need some time to play out.

What’s especially important here is deciding not just what’s on the table but what’s off the table. The things that are on your not to do list are just as important as the things on your to do list. The betting table allows you to clearly visualise and articulate this decision. Of course, in an agile environment, if something fundamentally shifts in the market and you need to change course you can revisit the table and make fresh bets but the beauty of the betting table is in deciding what you will – and won’t – be focusing on.

Analysing the success of bets

Each bet needs time to be played. Some bets need longer than others. At Netflix for example, they gave big bets such as open APIs and social viewing, a number of years before concluding their success or failure.

Using the betting table diagrams, mark each bet with shades of green, amber or red to denote the relative success or failure of each bet. Armed with your results, you’ll then decide what to focus on next. You may decide to revisit a failed bet at a later date or move onto a new bet entirely.

Org structures

Org structure visuals can be helpful in 2 important contexts:

• Explaining the wider org structure to your product team
• Creating the org structure

Explaining the org structure

Who is Sally in marketing? Why does Dave need a CRM exactly? When working with your product team, context is helpful. It may seem like an odd thing to do, and that there’s never really a right time to do it, but explaining your org structures to your team can be a helpful exercise.

There’s sometimes an underlying assumption by product managers that because you deal with stakeholders on a daily basis, your team members are also familiar with the same stakeholders. That’s nearly always not the case, and yes, whilst it might be a little boring to go through an org structure diagram, it’s helpful when the initiative or feature you’re working on involves people from other parts of the business. Understanding the people involved makes the wider context of what you’re building clearer.

Creating the org structure

Product leaders will be involved in the creation of org structures and whilst there are many ways to create an org structure, a powerful way to do it, at least from a product perspective, is to orient and structure your product teams around strategic goals and bets.

Team A is focusing on bet A, team B is focusing on bet B and so on. This is not without own issues (too narrow a focus can lead to parochial attitudes) but it does help to focus everyone’s attention on the most critical objectives of the business – and who is involved in meeting those objectives through the products built.

Product vision

Now there’s always a niggling feeling whenever you’re sat in a meeting coming up with a vision statement. The niggling feeling is usually along the lines of ‘is this really a good use of everyone’s time?’. And there is some truth in that; as we’ve previously argued, companies which spend most of their time perfecting vision statements in the absence of any valuable outputs are doing themselves no favours.

Yes, it feels like a fluffy exercise, but a vision statement is important. It acts as a guiding, overarching principle which can be used in times where you’re struggling to make a decision. It helps to create a sense of camaraderie and focus for your team. It works to create a sense of belonging to something bigger than a Jira board.

Visually communicating your vision statement doesn’t need to be anything more fancy than a single document with your statement on it.

Here’s a sample of visions from market leading companies which you can use as inspiration:

The anatomy of an inspiring vision statement

If we look at all of those vision statements, there’s a common thread which ties them altogether. The thread is the emphasis on ‘people’, ‘humans’, ‘everyone’. A winning vision statement combines some of the following attributes:

1. Links to the value proposition – Amazon’s ‘buying online’, Microsoft’s ‘empowering people through software’, IKEA’s ‘creating a better every day life’. These are all linked explicitly to the central value propositions of these companies but broad enough to leave scope for interpretation through strategic decisions.
2. Inclusive – appealing to ‘people’, ‘everyone’ and ‘humans’ leaves little to dispute about the inclusivity of these statements. We’re all humans.
3. Bold and ambitious – Amazon’s reference to ‘earth’ in its statement demonstrates global ambitions which inspires growth.
4. Highlights strategic advantages and differentiation – a strong vision statement will bring to life the unique differences and strengths of your business. IKEA’s nod to ‘every day life’ shows that it helps customers by offering appealing furniture at valuable pricing. IKEA’s ability to do this at scale is a unique advantage brought to life.

When crafting your own vision statement think about how to tailor these attributes to your business.

Product roadmap

Finally, last but not least, we have the infamous product roadmap. We’ve delved deeply into a variety of product roadmap templates previously and you can check out those templates here. But the reason we view roadmaps as a little controversial is that upon delivering a roadmap in any particular format, many product folks will look aghast at the format you’ve chosen.

Include dates? That’s blasphemous. Don’t include dates? How are people meant to know when things will get delivered?

Our view is that you can’t please everyone all the time and only you know which type of roadmap works best for you, your team and your stakeholders. Including no dates on a roadmap whatsoever is just wishful thinking and – dare we say it – a little arrogant; as much as we’d love all the time in the world to create the perfect product, time is money. Your marketing team might need to organise communications around upcoming releases. Sales teams need to prepare. Competitors are building and shipping competitive products. The market dynamics are changing. The world is changing. Yes, it’s nigh on impossible to provide accurate dates on a roadmap and you really don’t want a culture which emphasizes churning out features to set dates, but giving your stakeholders a sense of whether something’s a small, medium or large in size as a rough indication of deliverable timeframes is helpful – and more polite – than flat out refusing any indication of delivery dates.

The knowledge graph as a tool for communicating uncertainty

Make it clear to stakeholders throughout the process that there are always unknown unknowns and as you delve further into the details you’ll be more confident. A useful exercise to compliment your roadmap is to include a knowledge graph which shows stakeholders which areas of your product your team has most knowledge / experience in. High knowledge areas can potentially be used as proxies for estimation accuracy. Low knowledge areas are the riskiest where timeframes are the least certain.

Caveats and flexibility on scope are your friends when it comes to roadmapping. Use them wisely to keep stakeholders on board.