Two techniques to explain your Product Vision

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases in an agile project.

A problem that is well understood leads to a better solution. Applying design thinking techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product’s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona’s context.

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution – inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skillsplay a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet – around which problems and solutions are discussed.

Chalking out personas visually, require doodling skills – sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona’s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona’s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona’s goals and emotions in context of the tasks.

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation

What do you think?

Leave a Reply

What to read next