Death To Assumptions
Definition of an Assumption: a thing that is accepted as true or certain to happen, without proof.
Assumptions are one of the greatest hindrances that all organizations encounter. The larger the problem or the more people involved increase the chance of assumptions sneaking in and destroying the momentum of creating great solutions. Unfortunately, some people must juggle assumptions in their everyday life and I want to discuss the value of avoiding problematic assumptions, especially when communicating with someone or in general human interactions.
For example: In a meeting, I could ask four others how old is my dog? It’s easy to say “7 human years” or “57 dog years?” In reality, I don’t have a dog and the answer should be “I don’t know?”. Due to the lack of context in the question, two assumptions can be made here. Coop’s playing a game and wants us to guess versus Coop’s trying to make a point. Additionally, people are assuming I have a dog based on my lie in order to prove a point.
The opposite action of assuming is digging for the source of truth. I once observed a brilliant business person hunt for true information while purchasing a property. In Hong Kong, it’s a benefit to have an apartment with a parking space, and you can buy them both or separate. He asked once, “does the apartment come with a parking spot?” The owner said, “no, we don’t have a parking slot.” The potential buyer continues the conversation then askes a few minutes later, the same exact question. This time the owner said, “no, we don’t have an available parking spot”. Again, the conversation continues and with persistence, the same question is asked for the third time. The owner cracks and says, “Yes, fine, we do and it cost 1.5M HKD and must be purchased with the flat.” I was astonished by both the friendliness of the conversation and how the source of truth came to the potential buyer.
Now that we are on the same page about the types of assumptions that exist and the difficulties that may exist in getting the true source of information, applying it to engineering products is difficult. When it comes to building products, I’ve found that there is only so much a person can really know before deciding to start working on a solution to a specific problem. If you’re trying to build teams that portray true ownership and do not need to be micromanaged, it’s important to know when to work with an assumption, versus investing hours, days, weeks, or months into finding the source of truth.
The above shows a timeline of someone who does not assume by hunting down the source of truth and someone who works with assumptions. The blue boxes express actual work being done, and the red boxes express time waiting for stakeholders to report back sources of truth. I wish I was exaggerating, but it may take many days to get the source of truth in some organizations, so you can imagine the x-axis of time being days or weeks depending on the complexity of the problem.
The problem with assumptions and the source of truth in product development is that after you ship your feature, the customer or stakeholders get to see the end output and it is almost impossible for there not to be feedback. Investing as much time into an idea to make it great usually does not come out great on the first iteration. Once you play with it, physically or interactively, your idea usually evolves or you realize, well, it’s was just a bad idea! And that’s alright folks! In the diagram’s case, after shipping it for the first time, there’s a period of time for feedback in red, then some work, and the final form gets shipped again, hopefully, great this time. This process can iterate indefinitely.
Unfortunately, when shipping products, finding the source of truth by the end-user is usually impossible. They usually don’t have a stake involved or are customers and getting feedback or data can be costly and time-intensive. So it’s important to ship as soon as possible and to do that, the person implementing the solution must make some assumptions along the way.
These assumptions in my personal belief are good. Not only does the product development get shipped faster to the end-user which gives you real information and feedback to work off of, but this gives a chance for the person implementing the solution to innovate. Some of the best inventions come from assumptions and honestly when a person needs to assume and innovate to get the job done, usually, that part is the most fun. That solution is a piece of them, their say, their power, and it increases the retention of them wanting to be a part of the organization because they are not simply listening and executing orders. With that said, I would categorize this as not an assumption, but pure innovation and since it is not dealing with humans or communication, it’s safe to assume or make a best guess to get critical feedback faster.
When dealing with people and processes that are critical, time-intensive, and coupled with money, I sincerely ask the world to please bring death to all assumptions. Once multiple teams are involved and assuming the rules between such teams, it becomes a mess. Expectations of the client become disappointments, frustration between peers rise with the confusion of “why did X say that? They don’t even know!” and many more conundrums may occur in the infinite complexities that organizations deal with.
There are a few simple rules that I try my best to follow so I may avoid this trap that invokes negative energy amongst my peers:
If you don’t know, say it! Go ahead, practice right now. “I DON’T KNOW!” Well, maybe not yell it. But saying it out loud for once will show you how often or not you use those words.
If you don’t know but you know who does know, guide the person asking to the source of truth. Better yet, if you ensure to include all stakeholders that have 1st hand information within a meeting, you’re going to be blessed with blissful efficiency!
If someone says “I think, I believe” or any other phrase that sounds like an assumption, deny it and hunt for 1st hand information. Nicely re-ask the question and express the importance of knowing the source of truth.
Take note of time. People get lost in the weeks and months of life. “It will get done in two weeks”. But there was a 1-month delay prior to starting the work, so in reality, it took 6 weeks to get done! Don’t get frustrated and understand the costs, money, and complexity involved in someone’s original commitment so you may shift and recalculate when needed.
Before starting to work on a solution, cap a period of time to hunt for as much 1st hand information from various stakeholders as to prepare for your best attempt to solving the problem. It could be a simple bulleted list and know that everyone is human and have their biases, but work with it. Then go into your cave, build, innovate and showcase your results for feedback.
Hopefully the above helps create a movement to the death of assumptions and empowers people to innovate and take ownership in what they do. As always, open for feedback in the comments below!