What the Hell Is Shared Understanding Anyway?

The term ‘Shared Understanding’ has likely become irrevocably enshrined into the lexicon of software and product development. As product designers, owners, engineers, and delivery teams, we can often use the term with reckless abandon, daily. Collectively, as product builders, we most likely all agree that we now desire to create some sort of shared understanding amongst our teams before we commit to any action.

The idea is that in doing so, we all agree as a team as to what the correct ‘thing’ to build is, and more importantly, precisely why we’re spending our limited time on this earth building it in the first place.

Building Shared understanding then, we hope, can provide a mechanism through which abstract and ambiguous problems become understood mechanisms through which we can create value for our customers. It is intended to create a context within which the solution that directly addresses the desired outcome is discovered. Unfortunately, something that we know all to well however, from our efforts to create it, is that it is not always a simple endeavour.

Creating shared understanding is not as easy as spending an hour reading documentation, regurgitating our customer requirement from a dusty post-it note (jotted before the first coffee of the day after an early morning phone call), apathetically punching acceptance criteria into a project management tool, and drawing fanciful implementation diagrams on the wall to wall white space that we insist on being provided with as product teams, but cannot be bothered to learn how to use effectively.

This is a depressing, process oriented, ‘tick-box’ manifestation of product development, and it can place too much emphasis on building the wrong product because it can be laden with both risky assumptions and, worse still, a chronic lack of empathy. Furthermore, it also places the team and it’s processes before the customer and their need; that is, the problem that we are [hopefully] being paid to solve. This process is simply a of a room full of people who have taken in turns to say, ‘yes, I understand’. The reality is that if you asked each to repeat their understanding, you would be left with a series of wildly different interpretations.

So, what the hell is Shared Understanding?

Jeff Patton’s wonderful illustration of the problem (above) is well known, but without context or explanation, it doesn’t help us understand exactly what the shapes represent. Are they features, backlog items, design artefacts, outcomes; all of these? The problem is that the curious, remarkable and wonderful way in which as humans we are diverse and unique, makes defining shared understanding almost impossible. Semantic uncertainty leads us, as individuals, down different paths. For example, let me give you two definitions of ‘understanding’, according to Google;

noun;

1. ‘the ability to understand something; comprehension’

and

2. ‘ sympathetic awareness or tolerance’

So, there is a definition which would have us optimise towards comprehension, and another towards compassion. Optimising to one could disadvantage the other, and so because our understanding of ‘understanding’ will invariably differ from individual to individual, shouldn’t we agree, as teams, which definition it is that we are working towards, if we choose to work towards it at all?

Try asking your teams what they think shared understanding really means, and see how varied the responses that you receive are. Your engineer may say something like ‘Knowing what we are going to build next’, but your designer may say something more like ‘Knowing how our user will interact with our product’; and these two responses clearly fixate on different aspects of the products development. The answer is, it’s both of these things, and more.

Shared Understanding as a Process

Pointing to user stories, user Personas, and writing acceptance criteria does not ostensibly create shared understanding. It may be part of the ‘DOR’ contract in your team that there must be ‘shared understanding’ of a story before it moves into development, but shared understanding isn’t a one-and-done process. We don’t gain understanding, move on, forget about it, and start again on the next ‘ticket’.

Without coherent and well communicated visions, strategy, and problems, shared understanding is as rare as a a vowel in Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch.

These need to be as much a part of the process as the more tactical work around specific features ideas— and yes — the whole team should know about them!

It’s not simply enough to say, ‘the user wants to see recommended content’. The process needs to start before that, and after it, and also include everything in between. Why do they want to see recommended content, how will doing that help achieve our business goals, how might we deliver it, how will we measure it? Why does the user even use our software, pay our wages — and through shared understanding — is there an even better way to solve the user’s problem than the solution requirement we’ve likely been mercilessly handed?

So we need to keep these things front and centre, communicate and socialise them, and bake refining and referencing them into our decision making and daily conversations. Then when it comes to doing the ‘work’, we’re already coming from the same starting point and the ‘tick box’ exercise is no longer that, because we have a much more enriched understanding of the context.

Shared Understanding as Empathy

So, in order to avoid some kind of pointless back patting at having delivered a thing, that we all agreed was what we set out to deliver, we also need to have [at least a little] empathy.

It’s not enough to have consensus in the team, work and deliver to a really tight deadline [a world first, I imagine…], and have the user hate the thing you did. We’ve all done it, and it sucks. In fact, without empathy, we do it more often than we don’t. We need to solve the problem, we need to address the need, and we can only do that by deeply understanding the ambitions of our users. Much has been written, by people significantly more capable at both product and writing than me, about ‘Jobs to be done’ and outcomes, but empathy extends beyond that, too.

Inter-team empathy is critical. Surely we need to understand each other in order to assess whether we actually have a shared understanding about something else? How often have you returned from a day off or rejoined a team only to discover to your horror that the absolute clarity with which you definitely set out your views seems to have vanished? How often have you released a thing that didn’t work, or surprised a stakeholder by showing them something that’s completely misaligned to their expectations. The only logical conclusion is that you must have been ignored, such was the strength of the teams collective understanding of the work to be done? Or is it possible that perhaps it never existed in the first place…?

There are apparently 500 shades of grey (contrary to popular, well publicised counterclaims…), and the more we can assess understanding and empathise within our team, the easier it is to know which shade we all meant in the first place. The knock on effect of this is that many of the conversation overheads described above disappear, and hopefully that empathy will spill over into understanding our users.

Build Products that People Love

Shared understanding is about more than knowing what we are going to build, how, and by when. It is about more than knowing what we will be working on for the next quarter, or how we’re going to deliver the thing that [we’ve depressingly likely] been asked to build.

As Product Delivery Teams we need to create a contract which agrees what shared understanding is, and how we can bake it into our daily lives. It shouldn’t be a simple process, and it shouldn’t be something that we give lip service to in order to overcome an internal obstacle.

Shared understanding is deep knowledge about why users come to us, and how we hope to keep that continuing. It starts with why, and it ends with how.

Shared understanding is not a process, consensus, or agreement. Shared understanding is a culture.