Every month companies in the United States spend billions of dollars on market research, competitive analysis, customer segmentation studies, and the like. The goal is essentially to answer a single question: “What should we build and how should we market it to be successful?” They spend days analyzing their spreadsheets filled with the data from these studies, dictate a list of features to be built, and hope they are successful. What is the result?

About 95% of new products fail.

The sad thing is, you do not have to guess. In Part 1 we talked about Jobs To Be Done and how understanding what Jobs a customer is looking to hire a product to do, the drivers that influence the job, the current approaches they take to accomplish that job, pain points that exist, and what competition is out there can help you understand the circumstances around the Job and ensure you’re solving the right problem.

Today we’re going to discuss an often-heard but not-so-often understood principle: Shared Understanding.

What “Shared Understanding” Really Means…and Why It’s Vital

The term “Shared Understanding” is used so often in Product and UX Design circles that it’s become one of the most common buzz words in the industry. Yet 95% of products are STILL failing. Why is that? It’s pretty simple actually:

In their book, “Lean UX: Designing Great Products with Agile Teams”, Jeff Gothelf and Josh Seiden explain what Shared Understanding really is (emphasis added):

Shared Understanding is the collective knowledge that builds up over time as the team works TOGETHER. It’s a rich understanding of the space, the product, and the customers…The more a team collectively understands what they’re doing AND WHY, the less they need to debate what happened and can quickly move to HOW to solve for new learning.

In addition it REDUCES THE TEAM’S DEPENDENCIES on second-hand reports and detailed documents to continue its work.

In a nutshell Shared Understanding basically means that a cross-functional team is focused on solving the same problem at the same time and all members of the team are involved in the key moments of decision. It is especially vital that all members are present for all brainstorming activities and participate in user research sessions.

The Benefits of Shared Understanding

Historically, product team members — and developers in particular — have been evaluated based on the output of what they can achieve in a given sprint. The prevailing mentality that causes is that every minute not spent coding is a minute wasted. That assumption is based on unsound logic. If the goal is to help our customers accomplish their Jobs To Be Done more effectively (so that our product will increase loyalty and sales among customers), then Shared Understanding is the fastest way to achieve that goal. It provides three main benefits.


In a typical project it is not uncommon for entire days to be wasted getting team members up to speed. Traditionally the product manager (and ux designer if you’re lucky) are involved in discovery and work ahead of the dev team. Even if they try to involve a dev lead, his/her time is generally limited and the bulk of their focus is on implementing the previous design. Then when developers are ready to start implementing the new design all sorts of questions are raised, the product manager has to explain the business reasoning, the designer has to summarize all the research that led to the design decisions, and often some technical objections are raised. It’s all waste. Wasted time, wasted stress, wasted work. Now the design team has to go back to the drawing board and often the implementation gets put off for another 2 weeks.

Instead, give the entire cross functional team a problem to solve together. Hold a brainstorming session before the sprint starts and outline the vision for what problem needs to be solved and list out assumptions together. Create a plan for validating those assumptions. Depending on the stage of the project that might be validating your target users, their Jobs To Be Done, or even sketching out a couple plausible solution and then validating THAT with the client. Then go to work. Something that I like to do is to create “Learning Stories”. This can work for validating technical assumptions as well as business/user needs. Then divide the learning stories up among the team. The format I use for learning stories is:

I try to assign at least 2 team members per learning story (the more the better). When not possible to involve everyone, rotate who is involved and definitely make sure those involved have different specialty areas. For example, it was determined by the team on a project I was overseeing recently that we needed to ride along with some of our clients’ tow truck drivers to validate some of our assumptions. There’s only so much room on a tow truck so we visited 4 clients and each visit consisted of someone from the UX team and a developer or customer advisor (product manager was out of town at the time). No developer or CA went on more than one visit, but they all got a sense of the environment and needs we were trying to solve. This enabled them to provide meaningful contribution both in ideation as well as development.

After all visits were complete, we met together to discuss how we were going to solve the problems we observed relating to our business KPI (which had been identified previously). We spent about an hour whiteboarding a couple solutions together, and had the end of the session we all had a general direction and workflow to work towards. Design went to flush out the more complex interactions. A couple developers started putting together a UI prototype we could use to usability test the effectiveness of our idea, the rest started determining what architecture changes would be needed on the backend, and PM started putting in additional learning stories for what we wanted to validate in the next stage.

The next day we met to discuss our progress and update each other. After a week or so we had enough of a prototype to user test and the whole process started over again. Within about 3 weeks of this, we had a fully-functional UI prototype that we were able to demo at a conference to get more feedback and test out market interest which went over very well. At that point we KNEW our product would be successful. While the back end was being built out we continued making refinements based on learning — moving even farther down the path from doubt to certainty. This was possible because we all were working towards the same goal at the same time.


The amazing thing that started to happen in the case study above is that developers started bringing up design ideas, and PM started making technology recommendations, and design identified some new areas for learning stories. We all had a shared understanding of not only the user’s Jobs To Be Done but also of the business, industry, and because we all had participated in the process. Because more people were able to come up with learning-informed ideas, the product ended up better and was released quicker than it would have been otherwise. We spent our time ideating instead of deliberating. If we had multiple, conflicting ideas, we just validated them.

One other key was that we were releasing in small batch sizes, and since those small batch size solutions were based on data the risk was minimal and so business leaders (mostly) stayed out of our way after defining the problem we needed to solve and KPIs we were accountable for. This is essential to moving fast.


One other added benefit of Shared Understanding is that it helps the entire team feel invested in and accountable for the quality and outcomes of the project. It promotes the ‘Founder’s Mentality’.

Credit: https://www.foundersmentality.com/

Founder’s Mentality is basically the idea that an employee can be invested in helping the company succeed just as much as if they were its founder. Above are some of the characteristics of the Founder’s Mentality as defined by Chris Zook and James Allen. A focus on Shared Understanding instills these attributes into a team. When you are sitting in a tow truck on the side of a freeway with cars racing by and a driver is trying to get your “stupid app” to work and it takes 10 minutes for the thing to sync to the database, you become pretty invested in the project. I could (and probably will in the future) write an entire article on how this happens for each of the attributes above, but suffice it to say that I have observed developers in this kind of a situation want to pull out their laptops and fix a problem a customer is having right then and there! If that isn’t ‘customer advocacy’ I don’t know what is.

How You Achieve Shared Understanding

Every company, politics, and culture is different so this will vary from company to company. Here are some tips and tricks I’ve learned that are essential to promoting an environment of Shared Understanding.

  1. Small, cross-functional teams. It’s impractical (dare I say impossible) to achieve shared understanding if you have a cross-functional team of 25 people. My ideal team size is no more than 8 people (maybe 10 for a bigger project). You start getting bigger than that and it’s hard to focus on the same problem at the same time. It’s vital that the team is cross-functional and has everyone needed to design, build, and release software. This typically includes Product Management, UX Design, Development, QA, and possibly UX Researcher.
  2. Deliver problems to solve to the team. The team needs to be delivered a problem to solve not a solution to implement. Management should be responsible for determining priorities, defining the problem, and setting the success criteria/KPIs. After that let the team run with it. I like to use the example of a toothbrush project. It’s the difference between telling a team to “make a softer toothbrush” and “how might we improve the teeth-cleaning experience”. If you use ‘how might we…’ statements that are problem-focused the team is free to innovate. If you tell them to make a softer toothbrush, their brains all turn off and they become mindless sheep that aren’t helping the customer at all.
  3. Dedicate the entire cross-functional team to solving 1 problem at a time. The team must all be focused on the same problem for shared understanding to work its best. Imagine if the military gave a single squad 2 missions at the same time in different directions. What would the result be? Both would likely be wiped out and neither mission accomplished. Software development is no different. If you have 2 missions that need to be done at the same time, form 2 teams.
  4. Involve the entire team in Brainstorming and User Research. If there is one thing you take away from this article, I hope it’s this. If you can do nothing else, involve whole team in brainstorming and research. It will do wonders. I implemented this when I first got to Omadi and it has completely transformed our effectiveness almost overnight. Do this while you’re working on putting the others in place. Don’t even ask permission, just invite developers or PMs along and watch how your product steadily improves.
  5. Be a teacher, not an expert. For shared understanding to really stick, the entire team needs to get passionate about user research. Like anything though, many people (especially devs) are nervous being in front of customers if they feel like they don’t know what to do. Involve them in research planning. Teach note taking and moderation skills. Give them opportunities to present and then offer feedback. If they feel prepared, the majority won’t hate it and they’ll be willing to come more often.

Like what you read? Have something to add? Connect with me on LinkedIn to join the conversation or check out my portfolio to learn more about my work.


Deliver Products People Love…Without Guessing, Part 2: Shared Understanding was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

Original Sources