Get Started
digital products

Building Digital Products Requires Building a Muscle of Shared Understanding

Building great digital products require developing methods for Shared Understanding. Below I'll share some insight about Shared Understanding.

Share this:

Related to:

Business Leaders Technology Leaders

Published 18 Mar, 2020 4 minutes of reading

I wish that someone would have forced me to read Jeff Patton’s book, User Story Mapping, 5 years ago. It would have been helpful, both internally with how our teams interact, and externally with clients when defining what digital products to build, why we should build them, and how we’re going to drill down into the details to make the right things happen together.

Let me get to the punchline of Shared Understanding as it pertains to building digital products: 

“Talk, communicate, draw, interact with people, to develop a shared understanding of what software makes sense to build and why. Learn to listen, and participate so you can digest as a team - ideas, problems, and possible solutions for target customers. Get out and interact intelligently together.”

man handling a balloon shaped as an idea bulb to a woman

In 3 different books for different purposes the concept of “Shared Understanding” is referenced and explained. The books I’ll reference are 1. User Story Mapping, 2. Product Roadmaps Relaunched, and 3. LeanUX

To let Jeff Patton explain the concept of Shared Understanding better than I could:

“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 pictures, we build shared understanding.

Through combining and refining our different ideas, we end up with a common understanding that includes all our best ideas. That’s 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.

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 the document writer’s. In reality, it’s neither. The answer is just to stop it. Stop trying to write the perfect document. Go ahead and write something, anything. Then use productive conversations with words and pictures to build shared understanding.”

Patton, J. , Economy, P. (2014). User Story Mapping,

If we drill down deeper into shared understanding—keeping the big picture in mind of where we’re going with our digital products—we’re going to generate and capture plenty of ideas. Hopefully we’ll be organizing those ideas in different ways, but rather than think about the finality of purpose, it’s important to think about the journey itself and the people with us—are we building a shared understanding in the artifacts we choose to create together, a shared understanding that will help us build better digital products?

a team thinking in the best way to use 2 wheels

As a team it’s critical that business and technology people come together to assess the problems and opportunities that make sense to tackle. Prioritizing what to do first—that is, what will generate the biggest impact for target customers—requires that target customers, product managers, product designers, and software engineers can communicate effectively, together, to get their minds generating the actionable ideas that will make a difference. Actionable ideas may take the form of a product roadmap (using techniques in Jeff Patton’s User Story Mapping) starting with an MVP to quickly validate initial ideas.

It’s probably helpful to repeatedly ask ourselves the following question: “Have the key people and target customers meaningfully contributed to our product roadmap?” In Product Roadmaps Relaunched the authors nourish our central theme of shared understanding:

“Product roadmaps can take many forms, and aren’t necessarily a single artifact or document. In fact, it’s really not about creating artifacts at all - it’s about creating a shared understanding of where you’re going and why.”

Lombardo, C. T, McCarthy B. (2018). Product Roadmaps Relaunched,

If we move on to the book LeanUX and we drill down into the purpose of “Discovery”, where we’re engaging clients to extract and process information, the authors reference the concept of a “Service Definition Workshop” used by UX Agencies. The purpose being to interact, extract and organize together with clients the vision, goals, target customers, customer journeys and features to build. All done with the purpose of yes… Shared Understanding

“The Service Definition Workshop sets the scope of the work and expectations for how the team will address the work. It allows the newly formed client/agency team to create the following:

  • A Shared understanding of the vision and goal of the project
  • A prioritized list of business goals
  • A clear sense of who the first users of the system will be
  • A proposed customer journey for those users
  • An initial set of desired features that the team feels are important”

Gothelf, J. , Seiden,  J. (2016, October 25) Lean UX,

The bottom line is you should feel free to challenge anyone that hands you a requirements document or any other form of pre-written document that pertains to a digital product if it did not go through a process of “Shared Understanding”. A group of people (perhaps 3-5 people) taking the time to interact, discuss and capture problems to be solved, ideas to solve these problems and the tasks or customer journeys from “As Is” to “To Be”.

The purpose being to build the right digital products for the right customers and purpose. As Jeff goes on to explain.

“If you get nothing else from this book, remember these things:

  • Stories aren’t a written form of requirements, telling stories through collaboration with words and pictures is a mechanism that builds shared understanding. 
  • Stories aren’t the requirements; they’re discussions about solving problems for our organization, our customers, and our users that lead to agreements on what to build.
  • Your job isn’t to build more software faster: it’s to maximize the outcome and impact you get from what you choose to build.”

Patton, J. , Economy, P. (2014). User Story Mapping,

Building a shared understanding through the right team activities and interactions will help you select the problems worth solving for target customers maximizing higher value business outcomes.

Other posts

For you to explore, read, and learn.