Do you know what’s obvious to your customers?

This week we are building on last week’s blog post: Software requirements can’t be gathered. If you haven’t read that post, I recommend reading it prior to this week’s post - it will give you some needed background for why this week’s topic is both relevant and not obvious…see what I did there.

The notion of something being “obvious” is deceptive. As humans we see with our eyes and our brain makes an interpretation about what we are “seeing” - really, we are making an observation about our environment using the language we have available. What makes an interpretation “obvious” is our history - everything in our background that we have experienced has us make the interpretation about what we are “seeing”. This is where things get deceptive.

The image above is what Merriam-Webster offers us: “Easily discovered, seen, or understood”. For many things, there is nothing “easy” about the discovery. And even the notion that something can be discovered when building software is just not how our brains work. This is precisely why software requirements can’t be gathered. (If you skipped over my nudge to read last week’s post, then I’ll point to it again here.)

Also taking a look at what Oxford Languages offers to us regarding what is “Obvious” we still don’t have a great deal of help: “Easily perceived or understood; clear, self-evident, or apparent”.  Ideas or artifacts can’t be “self-evident”. It is our background that has us make an interpretation about what something is…not the artifact. It is also our background that has us think the idea up - if it were “self-evident” there could be no new ideas or inventions - because it would be obvious to everyone.

Well, if our backgrounds aren't "obvious" what are some of the situations that help us produce our background?

Here is a small list of how to think about where your background was produced:

• Your education - not only where you studied, but what you studied and who your teachers were

• Your family - how you were raised - your values

• The jobs you’ve held

• The religion you practice

• The culture you were raised in, live in, and create for others

• All of the experiences / situations you find yourself in and create for yourself and others

• Your hobbies

This is a small list and if you think about it, it is easier to see that an engineer and a poet would observe the world with different backgrounds and therefore have different notions about what is obvious to them. To be sure, we have large areas of shared background - most people in the United States and other places around the world will see an apple and know immediately what it is - because it is obvious to them.

I was born and raised in Massachusetts and have lived for the last 14 years in Georgia. Humidity (what it feels like) is obvious to me. However, I was just speaking with someone yesterday and she brought forth that her children hadn’t experienced humid weather and had no idea what was wrong (they felt uncomfortable) when they were in a humid climate for the first time in their lives…but it was obvious to their mother. The climate was objectively the same for both, but the interpretations weren’t the same because one of the parties had no language or experience with humidity.

Why does this matter when building software tools?

Software requirements that are obvious to the business, won’t be obvious to the technology team - because their backgrounds are usually very different and neither party is aware of their cognitive blindness to this situation - because what they “see” is obvious to them and therefore is obvious to everyone - because that is what we have been taught. Where this shows up in software development is business teams and technology teams “talking passed” each other - using the same words, but meaning different things.

When software teams talk passed each other (and it happens almost daily) and it isn’t noticed by an expert, software gets built that doesn’t satisfy the business. Then rework happens to fix the flawed software - which creates additional cost. This cost shows up in these categories: time to rework the software, money to pay the teams fixing the software, energy focused on rework instead of new requirements, and missed opportunities to be advancing your product and taking new territory with customers.

I was recently told by a customer that the way we deploy off-shore software teams works better than he has ever seen - our quality is higher and we are faster. One of the reasons for this is our ability to recognize what isn’t obvious and question into it to learn from our customers what is obvious to them. We build our background so we can align with what is obvious to them and go faster in the process.

Follow us on Linked In (8PennyLabs) to be the first to learn when a new blog post drops.