Should I build a vision canvas with my stakeholders?

Recently, I’ve been hearing some variation of the following statement quite often…

In the time I’ve been here, I have not yet heard a clearly expressed product vision, roadmap or strategy

It doesn’t have to be this way, teams should have clarity on their vision and if no helpful one exists they should draught their own.

Vision = problems + influences + purpose

In my experience of working through this type of problem, I find that the strongest visions are a synthesis of problem space (which problems are root causes, which are symptoms), environmental factors, and purpose. Or put another way, a great vision is a dream of a future where the root problems have been overcome in such a way that we are delivering our purpose and following a plan that navigates the forces that are trying to prevent us getting there.

Organise the activities

There’s a lot to do here, and almost all of it fairly abstract and hard to communicate. You may well get push-back on your plans (“we know that already”; “why would we want to do that?”).

I use a “we do this so we get this” chart. It’s hard to map against dates, I used to put a week down to cover each workshop (counting planning, prep, synthesis etc.) but these days I’m lucky if I get a day. Either way, a chart like this can help explain to reluctant stakeholders why they would want to attend your workshop (it’s actually a little bit like a P.O.S.T. but a little prettier)

The Vision Canvas

I’m a big fan of product teams and their stakeholders working through these things together.

I know the c-suite decides the critical business stuff and in public sector a policy team may want to set some things down before engaging, but things really do work so much better when you consider these issues as a team.

To try and help with this, I created a workshop canvas for teams to build out their vision. It’s called the vision canvas and you can grab the PDF and use it or hack it with your team).

You build the canvas content up over a series of short workshops (YMMV of course based on your team’s problem space etc.)

1. Problems

In most cases you’ll be working with teams who have already spent considerable time looking at user insights and technical and process challenges. This can be a way to unblock or think about issues with a fresh outlook.

For this exercise, you need your group to have a good degree of domain knowledge. Take a couple of hours and write down problems that are close to your heart, group them in clusters and then rank them by causality. Like all service design methods, this doesn’t always work as expected, but the idea is to build a fishbone diagram that shows which problems are root causes (or at least get a common understanding of what issues are driven by).

2. Purpose

Next, you need to ask your team to complete a “purpose butterfly” exercise. Simply put, this is a Venn diagram with in one circle a statement of “what’s wrong” and in the other “why is it up to us to fix it” (This can also be expressed as “what’s unique about us”).

The intersection of the two circles is your organisation’s “elevator pitch”. Write this down and stick it to the canvas. (The purpose butterfly tool isn’t mine. I learned it from Melissa Andrada at Wolff Olins Kitchen)

3. External factors

I often get groans and sighs when I ask people to do a PEST or PESTLE workshop. Sure, it can devolve into a long thing but if you keep people on track, the idea is capture the factors that really matter and if you use illustration to express the issues it can actually be fun:-)

In a short workshop don’t go for an exhaustive list, go for the ones you care about, as a team. Another great output from this session is you can jumble up the letters to read “STEP” and make illustrated cards (“STEP Cards”) for stimulus in future ideation workshops. (lovely example here)

4. Bring it all together

With these three items written down, come together and think about what you need to achieve.

Balance the purpose so it’s not just an idealistic thing but one grounded in your actual team constraints. On the board you capture the purpose and then agree guiding principles.

With this common understanding, deciding what to do next becomes more manageable.

When I first put this tool together my desired outcome was clarity around strategic themes. I wanted us as a group to talk about what ambitious things we could do and rate them by viability, relevance etc. Each strategic theme was a project or programme of work focused on solving one of the problems that we all agreed were part of “The Right Problem to Solve”. You may not need this, but the approach also works to look at possible roadmap stages or simply as a foundation to ideate “what if” scenarios as part of speculative design.

The key is to do it together.

Make it better:-)

Can you imagine this working for your team? Reckon it won’t? Have you downloaded the canvas and got stuck? Made changes? Please do let me know and I’ll publish your changes and updates here:-)