The difficulty with assumptions is realizing when you’re making one.

Assumptions are especially dangerous in software consulting and when creating a digital product strategy because they can create unnecessary gaps in understanding between us and our clients. These gaps can range from user assumptions (features aren’t as helpful as we assumed, UI not as intuitive as we assumed) to technical assumptions (scope and product strategy around error handling, load testing). Such gaps can lead to misalignment, miscommunication, in a worst-case scenario – a digital product that doesn’t meet expectations.

So, how do we avoid these errors in our work? A recent project highlighted both the implications of making assumptions and the importance of staying curious.

Differentiating Priorities Set the Stage For Confusion

One of our digital product teams was building a software solution that would automate back-of-house activities at the client’s workplace. Our client was of the self-proclaimed “cowboy coding” sort and prioritized getting the product out the door above all else. On the other hand, our dev team wanted to create test-driven software with minimal lines of code to gain efficiencies as the product scales. Test-driven development necessitated the “go slow now to go faster later” mentality. Thus leaving both our team and the client struggling to reach the appropriate happy medium.

It was clear that our client was comfortable with assuming more risk than the delivery team was. Identifying why the client was placing this bet would help our team be better strategic partners and advocates.

A mental model to consider to draw out underlying motivations is to play out the worst-case scenario. In the case of software development, it’s likely that the digital product goes down. Often, technology teams will do this deliberately under the guise of chaos engineering. Working backward from the impact of the outage is a great way to understand the level of risk a business is willing to take on with each product release and elevate tech debt to be prioritized. In this case, I played out the worst-case scenario in a 1:1 convo with their head of strategy

The exchange went something like this:

• On your busiest week, how much product do you produce?
  • Our busiest time is in November and during that time, we produce 5000 units of product in a week. 
• I assume it’s pretty significant then if the staff were to lose productivity for an hour or a couple of hours during the day?
  • Absolutely. Why are you asking?
• With releasing any software (even when tested) it’s in an evitable scenario that the software we roll out would have an issue at some point. I’m trying to quantify the impact of that.
  • Our back of house runs entirely on paper right now. If we have an issue, it’s a matter of staff realizing there’s an issue, then context switching and picking up the process on paper. 
  • The most frustrating thing would be resolving discrepancies between the paper process & automated process on our dashboard once everything is up and running. 
  • At this stage, it’s very low risk if the software goes down. We expect it to, especially as we roll it out and learn.

Armed with the additional context behind the strategy, the delivery team identified where best to roll back the testing approach to match. 

The next time you find yourself stuck between a solution that you believe is best, and the solution another poses is best, consider the following actions.

Curiosity, Empathy, and The Willingness to Adapt

Stay curious and question everything. 

Assumptions find their home in the minds of busy, talented people. Use your previous experiences to help others on the team by asking what might feel like the obvious questions, especially when it might feel uncomfortable to do so.

Always roll efforts back up to business impact. 

An exercise we commonly use to prioritize which risks to tackle first is the risk vs. impact matrix. This might feel like a no-brainer, but treating this as a collaborative exercise is effective because it’s visual and opens the floor for easier banter around the relative and perceived probability of an event occurring. It’s not enough to identify a risk but to truly understand and, where possible, quantify the impact of it. This is a matrix we do our best to build into all our digital product strategy models.

Meet folks where they are, not where you think they should be.
While you might believe your solution is superior to the alternatives posed by others, you might be lacking context. Ask more questions to truly understand what’s driving others’ ideas. Deeply understanding what’s at stake for your client will help you better identify the best path forward. 

Keeping Perspective As a Path to Success—For Your Client and Yourself

At the end of the day, bringing empathy and thoughtfulness to each interaction will lead to the best outcomes possible. It’s also a vital cornerstone to great client services and collaboration.