It is said that up to 65% of us are visual learners. I personally walk around with my head full of process flows, which, as you may well imagine, makes me a lot of fun at parties. It surprises me when other people don’t visualize everything as complete systems, which again, makes me a lot of fun at parties. Truthfully, the only reason I am fun is that I absolutely never mention process flows at said parties. The point is many of us need to see something to really be able to absorb and understand it.
Sometimes, in the course of doing business, particularly between business teams and development or engineering teams, we make the mistake of either not painting a picture at all or giving an incomplete picture. What do each of these look like and what is the upside of approaching our requirements a little differently?
No Picture at All – Sometimes, we hand developers a list of individual requirements or add tickets to Jira with no context whatsoever. This leaves the door wide open for several issues. One, without an idea of how they fit together and what the final picture should look like, there are a million opportunities to misinterpret requirements. It is like painting blindfolded with no idea what your subject matter is and what you are trying to convey. Two, the opportunity for missing requirements is high. The act of documenting the way a product or process is intended to work highlights gaps, dead ends, and risks. Sharing it with the resources tasked with implementing that product or process adds a second opportunity to identify missing requirements or misunderstandings in the technical architecture.
Incomplete Picture – Often, developers aren’t involved in the meetings where we are evaluating user feedback, analyzing operational metrics, or putting together our grand quarterly plans. Truthfully, many of them don’t want to be – hence the reason they are very happy in development. However, if the business team can help paint a picture for them regarding the current situation and what we are trying to solve for – essentially, giving them the WHY – along with some specific examples, we have the opportunity to leverage the creativity and technical knowledge of the development team to help us come up with better solutions that we may not have considered or were even aware were possibilities.
Ultimately, our goal is to design a solution that meets the needs of the customer in the smartest way possible in our existing infrastructure. The best way to do that is through a shared vision of the customer experience/business objectives and design collaboration between business and technical teams.
What methods have you found to improve the collaborative process?