Humans use language, tools, and methodologies in which they are trained as means to augment their intellect and cooperative work. The source of intelligence is the better organization of more complex processes. Our software is the artifact that aims to enable better processes and their usage.

The team has different skillsets and different tasks; designers, developers, and business managers need to collaborate, but if we don't create a common language of concepts, processes, and goals, it's hard to communicate. We end up with violent discussions and low effectiveness. Better ideas, better documents, and methods will make our work more effective and less violent.

The way developers work — their pace, languages, and rhythm — is quite different from that of interaction designers or business managers who are talking to users. It is challenging to articulate a development issue in design or business terms, and vice versa.

The Idea of the Story Map is to bridge this chasm. by mapping we can retain the narrative structure, during the implementation and testing with users. Maintaining intact and enabling the argumentation if our the implementation is correct, the best one and overall, to test our hypothesis. The Process is fundamental to have a correct iteration loop and achieve our desperately desired product market fit.

Suppose someone lacks the ability to understand concepts, write documents, structure processes, and engage in argumentation. In that case, we must let them go, because this is the core of our cooperative work and the tool we are building to assist it. Or we can train them until to learn the methodology.

What are our problems, and what do we need?

Building a shared understanding. Most of the time, each team member has a different idea of every feature, concept, definition, user, and user goal we are building. We need to develop a common understanding quickly.

Communication problem. We need better conversations.

We are not focused on users and their experience. We need a better product.

Our development process is ineffective and slow. We need to deliver fast and iteratively.

Principles

In this Company, we read and comprehend structured documents and arguments from the rest of the team.

In this Company, we engage in argumentation and writing structured and living documents.

In this Company, we structure methodologies and processes.

In this Company, we create and work with concepts.

In this Company, we treat everybody with respect.

Jeff Patton creator of the concept of story mapping

Development

Design

Project: one to three weeks.

Building Share Understanding with Seed

Shared Understanding is when we both understand what the other person is imagining and why.

In Seed, we don't have the proper argumentation to build shared understanding. We need to have conversations around the right concepts and processes. We need to have them first!

The original ideas of stories was focus away from shared documents and toward shared understanding.

Concepts and Processes

Story Maps

Story Maps are for breaking down big stories as you tell them

Shared Understanding

It is when we both understand what the other person is imagining and why.

Output

Everything between the idea and the delivery.

Outcome

We measure what people actually do differently to reach their goals as a consequence of what you've built, and most importantly, whether you've made their lives better. You've changed the world.

What have you put in the world that has changed the way people can reach their goals, and when they use it, the world is different for them?

Stories

A tool to tell stories through collaboration with words and pictures as a mechanism that builds shared understanding. Stories are the discussions about solving problems to people that lead to agreements on what to build.

Story Conversations

When you have conversations about a feature, you will talk about the following points

Who it's for.

What they do now.

How things will change for them later.

Good conversations are about who and why, not just what.

Pains and Problems

Ideas

Ideas for New Products

Features to add to an existing product

Enhancements to products that you've built

This Ideas once they are delivered they should make the people who were initially unhappy, mad, frustrated, or confused will become happy when the software lands.

The tool to build the Shared Understanding

What if, through our discussion experience and structured documents, we can provide the same experience as being in the same room, writing down sticky notes, and rearranging to build shared understanding?

This is the process of building Shared Understanding in the User Story Mapping Methodology:

The talking goes better if we can externalize our thinking by drawing pictures or organizing our ideas using index cards or sticky notes. If we give each other time to explain our thoughts with words and images, we build shared understanding.

It's not that one person is right or wrong, but that we all see different and important aspects. Through combining and refining our different ideas, we end up with a common understanding that includes all our best ideas. That's is why externalizing our ideas is so important. We can redraw sketches or move sticky notes around, and the cool thing is that we're really moving ideas around. What we're really doing is evolving our shared understanding. That's super-hard with just words alone.

Structuring Documents evolves forever

From the User Story Mapping

There are a great number of people who believe that there's some ideal way to document—that, when people read documents and come away with different understandings, it's either the reader's fault or

I have been watching these problems for two years, and I am not waiting any longer. We are fixing this now.

Story mapping keeps us focused on users and their experience, and the result is a better conversation and ultimately a better product.

Build less

There's always more to build than we have time or resources to build—always. Minimize output, and maximize outcome and impact. The trick is paying close attention to the people whose problems you're trying to solve.

Our job isn't to build software faster: it's to maximize the outcome and impact you get from what you choose to build.

Our job is to change the world, not work on the output!

Process

Personas

Site

Ethosfera