Brainstorm to backlog: setting a product vision
This is the first in a series of posts all about Agile discovery: the process of taking a digital product or service from an idea to a backlog of items on which a software development team can start working. In this first post we’ll take a look at developing a shared understanding among your team of what it is you’re setting out to build – a product vision.
Why do we need a product vision?
In most of the posts I’ve written on Agile so far I’ve taken it for granted that there already exists a backlog of features that need to be built. But how do we start to generate that backlog of features in the first place? And how do we decide which of the items in the backlog need to be built first?
At first glance you might think that the answers are simple. After all, we’re building this new product because we’ve identified an opportunity to create value for our organisation. Therefore we create a backlog of items which generate value and we build the features which generate the most value first.
Which is fine. If you’re working alone. But most of the time we’re working with various business stakeholders and a whole team of developers, UX designers and business analysts all of whom will have their own opinion of how best to meet user needs and generate value. And all those different opinions translate into different features and different priorities. Before we can proceed, we need a shared understanding of how we generate value.
Building shared understanding through Agile discovery
In his book User Story Mapping Jeff Patton stresses the importance of building a common understanding among a team of what they’re setting out to build. While it’s possible for each person to write down what they see as the ideal solution there’s no guarantee that when another person reads it that they’ll envision the same thing. And not necessarily because the first person has written down their vision badly but because we all carry around a ton of unspoken assumptions, preferences, experiences and attitudes of our own which colour our interpretations.
The only way to get us all on the same page is to come together and talk about it. That way we can combine the best ideas and insights from everybody into our solution. And that’s what the Agile discovery process is about: sharing our collective insights to find a solution which generates the most possible value for our organisation.
“When we leave this conversation, we may still name the same features or enhancement, it’s just that now we actually mean the same thing. We feel aligned and confident that we’re moving forward together.” – Jeff Patton
In the book, which I highly recommend, Patton introduces us to a variety of techniques and tools for fostering conversations which building shared understanding. But for setting a product vision I’d like to look at a technique from a different Agile author, Roman Pichler.
The product vision board
The idea behind setting a vision for a product is to translate business strategy into product strategy. We want to define our solution at a high level before we take a deeper dive into features, user journeys and technical solutions – we need a first ‘best guess’ on which to iterate.
The product vision board facilitates a lean approach by framing a conversation to extract what we know right now. By bringing together all the people with a stake in the product, by tapping what they know about users and the business, we can develop a shared understanding of our solution and then go ahead and test it.
Here’s what the product vision board looks like:
As you can see it’s a simple tool, the real objective of which is to provide the framework for a conversation. The idea is to bring together all those with insight to contribute about the users and their needs, or whose buy-in you need to develop the product, and then work together to fill it in. Address the four columns one at a time and then collaboratively compose a vision statement of one or two sentences.
This vision statement should be a crisp, clear summary of what you’re setting out to build which the whole team can buy into. It should be displayed in a prominent position where the team are working (or, if the team are split up geographically, in each location where they’re working).
Testing assumptions with a product vision
As Pichler explains, once we have this shared vision of what we’re setting out to build we can start to interrogate the assumptions on which it’s founded and start validating those assumptions:
“I find it helpful to identify the greatest risk or biggest uncertainty on the board. This creates focus, and it enforces a fail-fast: figuring out quickly what works and what doesn’t, which assumptions hold true, and which don’t.” – Roman Pichler
For example, if you think that your assumptions about user needs are shaky then you can now develop tests for those assumptions – surveys, interviews, prototypes or even quickly sketched wireframes – to work out whether, in fact, they will lead to value creation.
This is a very Lean-Agile approach. Traditionally a product strategy would be developed after a load of upfront market research and business analysis. While this approach aimed at reducing risk by producing a bulletproof strategy it’s not really suitable for a world which changes as quickly as ours. We don’t want to sink a load of cost into developing a product built on assumptions which, while they were valid at the time the research took place, no longer hold water.